I have mocked up a small prototype that shows off the general way the new view system could look and committed it to my branch (http:// bitbucket.org/saikat/weblocks-saikat/overview/). The new view/ presentation code is in contrib/saikat , and I've included a short example that uses them in examples/view-refactor-demo . A few notes about what you'll find there:
1) I mostly want to get feedback on the structure of things/generally how everything fits together (and comments on implementation of the big stuff is good too). The general idea is to scale back the responsibility of views to just be maps between models and widgets, and have widgets be responsible for rendering. Views themselves hold fields, where each field is a widget that has a corresponding presentation. So when I actually refactor the code in weblocks, a lot of the view rendering stuff will be put into the rendering for the form widget (as is evident some from my example). 2) I haven't yet fleshed out the syntax for actually defining views (right now, as you'll see, it's just using defclass and is clunky). I think eventually I want something fairly similar to how it used to be (like (defview view ((field-1 :parse-as input :reader (lambda (obj)...)))), and have the things in the defview be defaults that are used per instance (but overwriteable by each instance). Any thoughts on this? 3) One thing I wasn't sure about was whether views should keep state or not. I ultimately went with stateful view fields because I like the idea of having the fields be pure widgets that can be marked dirty (it lets me do things like what I do in the example of just redrawing certain fields without redrawing the whole containing widget). Also, views seem to me to be a layer on top of models the same way models are a layer over the database, so it seems natural to me to interact with them similarly (set values and then persist when ready). 4) Much of this code is not well tested/buggy, and there is a lot of stuff missing that the old views have (that I will add in later - for example, validation just returns true right now, but the stub I have is where validation will go) - I mostly just wanted to show off the diff. 5) I started on something to allow creating presentations on the fly using lambdas, but was foiled because I'm not sure how to tell if a form presentation created in a lambda is a form presentation (this seems necessary in parse-fields-into-view) - any ideas on this? 6) There is also a "view-alternate-version.lisp" which was a (i think foolish) attempt at making a way for views to be mapped on top of multiple models in a way that was different from just using mixed in views. I'm not sure if anyone sees any value to this (there is a better explanation at the top of the file), but I've included it for the curious. The big differences: 1) Views are not singletons 2) Views have state 3) View fields are widgets Any feedback will be much appreciated! -Saikat --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
