broken cardtypes
The single-table inheritance mechanism failed to locate the subclass: 'Project'.... -- Solution, don't use a column named "type" [link][http://railsruby.blogspot.com/2006/01/single-table-inheritance-mechanism.html] --[Mike Buland][Mike_Buland]
I
don't like this solution, because we are actually using type for a STI
mechanism :-) I *think* I know what this bug is-- it requires some
explanation: Cards of different cardtypes actually belong to
different ruby classes-- Card::User, Card::Project, etc. several of
these have custom implementations in the codebase: users, roles, etc.
However when you create a new Cardtype in the interface, there's no
file, so it creates a class on the fly. The mechanism for this
interacts badly with the rails mechanism for reloading classes in
development mode, so on the first request, everything works fine, after
that it's broken. This hasn't been fixed because 1) it's kindof tricky
and 2) it's not an issue for production sites. It could probably be
argued that the problem here is in how we chose to implement cardtypes
;-) the neat part about it is you could start with a stock WagN, then
later if you found you really wanted to customize the behavior of a
particular cardtype, you could add the class to the codebase and it
would automatically pick it up and start using it for those cards. --[Lewis Hoffman][Lewis_Hoffman]
I understand why that wouldn't be the best solution then. However, would it be possible to do automatically what I just did by hand to correct our problem. I just went into the app/models/card directory and copied basic.rb to project.rb and changed it to appear thusly:
module Card
class Project < Base
end
This could be easily done by wagn when a new cardtype is added, it may solve this problem and make a slightly easier starting point for learning to extend the cardtype system. I don't think there are any permission problems when running via WEBrick, apache CGI, or FastCGI. I may be missing something, though. --[Mike Buland][Mike_Buland]