> 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. > > The second issue (b) in particular is something presentations can't > easily do, because views are singletons and presentations share state.
When you say data if you mean an individual unit of data that corresponds to a field, then yes, I have similar issues. Can you elaborate on why presentations are not useful to you in this context? In my case, often the presentations (someone else called them decorations) are object or context specific -- so what I usually do is create my views at the point of use with defview-anon; modify the view- suffix/prefix or field-suffix/prefix functions as necessary (that is, they become closures with access to the object on which their behavior depends) and then use them. This way I avoid the singleton problem, at the expense of the GC problem. A wrapper around defview-anon might be better, of course, and it's not exported from weblocks either. In a few other case, of course, the approach breaks down -- consider a telephone number field, where you want to render a checkbox next to it for 'add additional number' -- which would modify the form/view itself with an additional field. For this I use an extra level of indirection with templates. But in general (and by design) views are limited to doing things to their data fields, and often we want a more holistic approach, as in the example above. I was trying to refer to this in an earlier (muddleheaded) post about flexibility of views vs other frameworks. > Anyone having similar thoughts? Another thing is that since views are not inheritable, I just wrote a small post on how best to arrange them. It seems to me this adhoc design pattern-ism is just crying out for a language approach. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
