So I have some thoughts for maybe how views/presentations/widgets should all interact. This is largely similar to a lot of (mostly Jan's) ideas at http://groups.google.com/group/weblocks/browse_thread/thread/ced04e5c561bcd1f/ce8a9ef76ffcf6b3?q= . It is not entirely fleshed out (and might not be until I actually start coding it), but here are some thoughts:
1) Widgets - Widget architecture will largely not change, other than I think a lot more should be done by widgets. More about this below. 2) Presentations - Presentations will be refactored to be widgets. They will render the correct HTML in their render-widget-body code. They will not be stateless. A presentation will know how to render its current value by first checking if it has been assigned a value, and if that is nil, it will try to get its value from its views associated object (more on that below). Presentations are basically a combination of the current view-fields and presentations, implemented as widgets. 3) Views - I don't think views should be widgets - instead they should be very lightweight facades on top of model classes. Views will essentially be CLOS classes that have a bunch of presentations as its slots and an extra slot to store the object the view is associated with (if any). I want to move things like form processing and all rendering up to the widget level - widgets will always be responsible for rendering (I feel like right now there is too much leeway and hence confusion in deciding who should be rendering what and most people seem to end up just doing their rendering in widgets anyway). Views will only be responsible for maintaining the map between models and the fields you want to present to the user - they will read and write data to the model objects. The idea would be to have widgets render the slots of the view it has however it wants to, and there will no longer be form views and table views on top of form widgets and grid widgets - just form and grid widgets. Widgets should no longer be messing with models themselves (unless you want to) - they will just be setting values on its contained view's presentations' slots and rendering them. I'm not sure "view" is still the correct thing to call them, but who knows. I'm still not sure if widgets should be allowed to contain presentations without going through a view (since presentations are widgets now, custom widgets can just have presentations as slots) - I think they should just to make creating custom widgets easier. So, in summary: Widgets can have a view or a bunch of presentations (my guess is the "essential" widgets in the framework like dataform will use views and custom widgets people come up with to just display some data won't as much). Widgets will render the presentations in its associated view. Presentations are widgets that will render themselves using render- widget-body. Presentations, unless they have an assigned value, will look to their parent view's object to get a value. For persistence, views will have methods that allow them to persist their current associated presentations, and the form widget will be responsible for calling this when it is right. These are my rough ideas - I realize it wouldn't be the most backward compatible thing, and so maybe this is not what we should do, but I think it might still be useful to agree on an ideal architecture we want to work towards. Any thoughts? Also this doesn't necessarily reflect what I want to do in the short term to remove the presentation singleton limitation, though if it seems easy enough (I'm not the best judge of this), I might try to do it. On Mar 30, 7:20 am, Nandan Bagchee <[email protected]> wrote: > > I would greatly appreciate this change because it is a barrier > > Same here. defview-anon is the only way around it for now -- and with > it we can use closures for {reader, writer, field-suffix, field- > prefix} functions, which is useful, I put render-widgets in those. > > Would everyone agree it would be a change for the better? There was > some talk a few months ago of making views into full CLOS objects, > with inheritance semantics etc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
