On Mon, Jan 05, 2009 at 07:51:06PM +0100, Jan Rychter wrote:
>
> 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.
I mostly use views for forms (because of the validation stuff)
and grids (because it's a cool way to build a table).
> 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.
I also have these special needs, but mostly in my graphics-intensive
game application.
Hardly any views there...
> The second issue (b) in particular is something presentations can't
> easily do, because views are singletons and presentations share state.
Yes, I hate this.
> 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?
I've given the problem some thought and also the the overlap between
widgets and views. So far I think this might be a good approach.
Requirements for a new model:
1. It should be as compatible as possible with the old one.
2. It should be easy to override a single slot of a view.
3. Inheritance must be working and customizable. We should also try to
offload inheritance stuff to CLOS to get rid of the ugly machinery
currently employed.
This all just off the top of my head...
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
