On 10/28/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > > Yes, also tangram. But doing it in the base model class in Maypole > > would be pretty cool. > > > > I plan on stealing^Wintegrating the relevent parts of C::DBI::Sweet > > into the Maypole CDBI model. > > I was about to ask whether anybody had thought about using Sweet as the > base for the model instead of CDBI itself, because I need some extra > capabilities that it has (e.g. limit the number of records returned from > a query). > > I don't mean to replace the existing Maypole::Model::CDBI, I just mean > to make an additional Maypole::Model::CDBISweet. Is there a reason not > to do that rather than cut and paste code? It seems to me to mean less > maintenance in the future and it also seems a better functionality split > (i.e the Sweet functionality presently works without Maypole, so IMHO it > naturally belongs in the CDBI namespace as part of the model-proper, > rather than in the Maypole-Model namespace which I now look at as > defining Presentation).
I'd like to have a consistent API through the generic model, rather than having the current situation where stuff works significantly differently if you use CDBI and the huge range of odds and ends that come with it. There is no reason not to put most of the Sweet stuff into an underlying module used by the improved Model and CDBI Model, so long as it is integrated nicely. The one advantage Rails has over Maypole is the seamless, polished integration, just importing a shedload of CDBI subclasses, plugins, etc is hardly going to come close to providing that and makes installation harder than it needs to be with hundreds of dependancies with their own release cycles, unpatched bugs, etc. A. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
