Mackram <[email protected]> writes: > So based on Lesile's suggestion the issue of Views & widgets seems to > be one of immediate need so I took a quick (or maybe too quick) look > on the form and code for these two entires and there are a few things > I am not sure I understand. > > Mainly my question resides on why a view is not simply an abstraction > of a set of composite widgets? My understanding is that views are > singletons at the current implementation while if they were simply > made up of widgets then they themselves would no longer be > singeltons. > > So before I embark on this task I would like to know why the choice to > build views separate from widgets? Are there any set of > functionalities that result from the current design decision and are > they needed to be preserved? > > Thanks for the help and looking forward to this.
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. 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). 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. 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 -~----------~----~----~----~------~----~------~--~---
