> Same here. I use views for quick-and-dirty admin interfaces, but as > Stephen rightly pointed out, this is usually not the way to go for > modern apps. So I end up writing widgets _and_ presentations/views for > many things, which is a duplication of effort.
Yes, it's a PITA. There is no easy path to migrate quickly form a view to a some kind of "view-widget" that allows you to do more complex stuff. Once you get beyond the prototype phase and start working on more and more complex stuff, the view/presentaiton framework is not very helpful. I have a few cases where I write custom presentations and have an action created/rendered in the presentation so that the user can affect the value presented directly in place -- the problem then is that you cannot simply repaint the view for the affected value because it's not a "widget", you've got to mark the whole encompassing widget dirty to repaint one small area. If the view could be treated like a widget, it would be a way to iterate and grow the complexity of the app with less hassle. Now, views are singletons, and probably save some computation/ resources on the server, but the trade-offs don't seem to be right when your app begins to mature. I would love the lists and tables to accept some kind of "view-widget" that acts like a view but is really a widget. Each row would be an instance of the view-widget. The number of widgets created would be determined by the page size (and therefore limited), and there would be a protocol in place to feed view-widgets with the row data. When you paginate, the view-widgets get reused and are fed new data for the next page. This would work so much better - you could even do away with the data editor widget entirely on the lists and tables and make each view-widget have an "edit" mode (view?) instead. There's got to be a better way to move from rapid prototyping to iterative real feature development. Yarek --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
