On 10/26/05, David Baird <[EMAIL PROTECTED]> wrote: > > I can see arguments that the information belongs in the (non-Maypole) > > model (e.g. that's what you did with CDBI-FB vs M-FB), I can see > > arguments that some info belongs in the presentation (i.e. Maypole model > > or view). I could see arguments for a separate static configuration > > module. But I don't see a good argument that it belongs in the driver - > > I think it's just being used as a catch-all. > > > > We've got a tension between ease of use and flexibility. For most > Maypole apps, the driver is the most accessible place to shove in > extra config data. If you want to run your model outside Maypole, then > the onus is on you to provide that model with config data however you > see fit. You can write your own static config class for the model, and > import that in the driver for your Maypole version of the app. I can > see what you're getting at, but until Maypole has a more advanced > configuration framework, it does seem to make sense to me to use the > driver precisely as the catch-all.
I'd agree with this. Maypole should be simple to use, if you want to provide stuff in your model for use outside of maypole, then that is beyond the scope of this project (for now at least, maybe version 3). 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-users
