I'd say my own system is about 50-50 custom widgets vs. views. I believe that the more you overload the requirements/features of a given mechanism, the more complex, bug-prone and difficult to use you are likely to make it. Views and the associated generic dataseq/ dataform hierarchy is already reasonably hairy for the newcomer; they have quite a few optional function arguments, types, defaults, etc. to customize them for different purposes. I stopped using them for anything other than simple uses (quickforms and trivial table presentations) fairly quickly.
We wrote a new stateful presentation system and some utility functions to make it easy to map form submissions back to a list of presentations. Generally my custom widgets were also driven by the need to have more complex html structure than the default views afford. What would be nice is a way of still manually describing the structure, but simplifying the embedding of slot values of an object or objects and their associated presentations. I tend to think that we want to provide a view framework for a good chunk of the common use cases so it's trivial/fast to do many things and reasonably easy to understand. For more complex applications, we can provide a lightweight toolkit + some examples rather than overloading the view mechanism with support for new use cases. Perhaps there is a middle ground too. A stateful view-widget toolkit could make it easy to define views with state as a first-class object that, when committed, map their values back to one or more objects that back them up. If we don't try too hard to make these view widgets fully configurable, it shouldn't be too hard to add support and perhaps even let these widgets be manipulated by the existing datagrid, etc generic widgets. I'm trying to open source my whole project, so when that's done I can offer up the stand-alone presentation system we wrote for such a purpose if the existing one isn't easily re-useable. Regards, Ian On Feb 23, 2009, at 5:02 PM, Vyacheslav Akhmechet wrote: > > On Mon, Feb 23, 2009 at 10:32 AM, Benjamin Collins > <[email protected]> wrote: >> For those of you who have working apps, how do you work through this? > I usually write the widgets that handle this kind of stuff manually > (hardcode the form, etc.) > > Views turned out to be a double edged sword - they're pretty awesome > when they work, and terrible when they don't. So, when the views don't > work, instead of just writing the thing manually, I get angry at the > views :) It'd be great if someone did the work of giving the views > state so that they could be used in a much wider range of situations, > but I'm not completely sure how to do it. I know others have had some > ideas before. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
