> There were several discussions on the subject -- please take a look at > the list archives. Here's an additional collection of loose thoughts > that I gathered from some private E-mail exchanges: > > I would suggest thinking about views in weblocks as something similar to > database views -- stateless mappings from your data model to > presentations. > > Presentations should be widgets with an additional API for storing and > retrieving data.
The implementation I have currently has views, view fields, and presentations. Views keep track of the data object the view is mapped to and whether or not the view's data can be persisted. View fields are widgets that have state, and they use presentations (which are stateless) to render themselves. This is a bit different from what Jan is describing, I think (though I think if I substitute what he is calling presentation for what I am calling view fields, it is almost the same), but there is discussion about this design in the thread I pasted earlier. > > IMO views should *NOT* be widgets. We should keep their stateless nature > and not mix in any rendering code. Instead, we should have a form object > that would use a view to a) get a list of necessary presentation > widgets, b) create and manage those presentation widgets, c) tell the > view to update presentations based on data model, d) tell the > view to update the model based on presentations and e) handle the > validation loop (asking the user to correct errors). There is still some validation done at the view level with my current implementation, though no rendering. Though I see Jan mentions that below. Otherwise I agree with all that. > > While we're there, we might as well do some renaming and refactoring -- > I find the current dataform/quickform/datalist/dataseq/datagrid > confusing. But perhaps it's just me. I agree. I started refactoring at least the whole form widget class hierarchy to have an underlying form class that is essentially like a quickform, and building the thing that dataform is supposed to be on top of that (always seemed weird to me to have the larger class - dataform - be the base class for quickform). > > When I tried to list the things views should know or do I came up with > this: > > -- maintain configuration of presentation widgets, parsers and > validators so that the entire form-processing machine may be > constructed, > > -- maintain mappings between the data model (possibly multiple objects > and multiple classes) and presentation widgets (one direction goes > through parsers, the other one I do not know) > > -- perform view-level validation (normally delegate validation to > presentations, it's their job, but you also want to have view-level > validators, see the :satisfies for views in weblocks) > > Also: > > I would say anything that can be called "part of a mapping" and is > stateless belongs in the view. Also, anything you might want to inherit > in your derived view definitions. The widget handles state and > rendering. > > Hope this helps. > > --J. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
