As I'm building apps, I find more and more often that views are inflexible for presenting my data. They do the job for HTML forms, but I've been implementing paginated lists of widgets so often that I abstracted the functionality out in a pageable-list widget, that displays its children together with pagination. Then I noticed that for a given data type, I usually define 1) a data view for displaying in lists, 2) a form view for editing, 3) a widget for rendering.
The problem is that I often have data that needs to a) be presented in a very specific way, meaning I want to implement render-widget-body myself and (more importantly) b) be dynamically modifiable, e.g. have actions rendered, participate in flows, have an "Edit" button for in-place editing, etc. The second issue (b) in particular is something presentations can't easily do, because views are singletons and presentations share state. So, that got me thinking -- why not reimplement views, but not as separate stateless entities, but as widgets, containing other widgets. One can then put form processing and the UI DSL on top of those. That way we could probably get rid of presentations (which would likely become mixins, or simply widget protocols for accessing and storing data types). Views would become widgets that have a mapping to/from data model objects and can process form data. Anyone having similar thoughts? --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 -~----------~----~----~----~------~----~------~--~---
