On 10/13/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > Sorry for not responding earlier. I've been away.
no probs :) > > I don't have the hierarchy decided yet - I need to try it out a bit > > and see how it works first and will get back to you all next week with > > a prototype. > > I'll be interested to see this. Is it just for the new 'standard' > Maypole form-handling or will it provide a template/model for others > such as FormBuilder to hook into? Hopefully both - I need to look at FormBuilder to see how it work, but first I need to get it just working ok and usable. > In thinking about overall design, one thing that has pretty much > crystallized for me is that validation is a property of the > data/object/business model, not the presentation/view system. If I call > some model method from elsewhere (e.g. a command-line script), I still > need validation to run, even though the args didn't come from a form. So > validation should be either freestanding or part of the CDBI family, not > part of Maypole or form-generation, IMHO. It is either business logic or data integrity (or possibly both) I'd think that business logic would be set in the controller (and therefore via Maypole) while data integrity logic is the business of the model. > That does throw open the question of what style of form-generation I > should use again :( I'd like to use Maypole::Form in the sense of user input/output - a form is where you write or read information on paper - Form has secondary meaning in HTML/WWW which could make that confusing but I can't think of a better word. The only other word I could thing of is Ribbon, just because maypoles have ribbons and it would describe the 'flow' of information, and connect the M, V and C in the way that different colour ribbons on a maypole are weaved. Naturally it would need some explaining bit I like the idea :) > > make_path method: > > > > I want to add a simple make_path method that reverses the parse_path > > method - the internals can later be re-engineered based on the > > LinkTools plugin. > > I think it's the other way around. LinkTools depends on make_path. ...and fortunately make_path is now in SVN :) > > Sessions: > > > > I want to add a skeleton get_session method, that is called before > > authentication (so that authentication can check session info if > > available), it will just provide an empty session object attribute > > that, like the authenticate method is overloaded by plugins or > > drivers. > > I'm not sure what this achieves? Unless you define the semantics of the > attribute, what does it offer that a plugin like > Maypole::Plugin::Session doesn't? That's just it - it provides a standard hook in the controllor for fetching the session, either through a plugin or user written code. This is how authentication works nicely both with plugins and your own code. Simon Cozens agreed it was a nice way to do it - essentially the default solution would be in the manual rather than the code as it's not a problem you can solve in a general enough case to put in the core and expect to work out of the box. Cheers, A ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
