> But I am really concerned with what you said that views are not good at > modeling trees.
I meant specifically trees with many subnodes. This has been an outstanding issue: how best to extend the defview syntax to allow for slots which contain lists (arrays). There is some very good discussion here http://groups.google.com/group/weblocks/msg/5bf85ddf9a4ad37c (where a list-presentation is mooted, if it works, it'd be a great candidate for inclusion in weblocks). Regarding views in general, and their scope: Jan Rychter touches on views at http://groups.google.com/group/weblocks/msg/a3b716dd4e85060e (the whole thread is interesting) In the same thread Leslie outlines how he uses views (which has been similar to my experience: views are great for forms (edit/display) and grids.. but that's it). Ian Eslick chimes in to succintly point out the problem with views: > It seems to be > trying to over-generalize something that has such a large and complex > parameter space (conflating DB access, visual layout, user commands, > presentations, etc) that the API simply become too unwieldy (eg, it would be great if we could have in-place editing of a slot which can have many a list of other CLOS objects, and a separate popup dialog to edit each of those subobjects in turn: but this depends on UI, javascript etc.) > IMHO, lisp is good for modeling trees, than a good framework written > in lisp should be able to model trees with ease (list being the basic > and main building block for any data model). See the code in the thread for http://groups.google.com/group/weblocks/msg/5bf85ddf9a4ad37c -- would you consider this "Easily modelling lists?" View mixins and custom widgets do a decent job as it is, imho. -- list- presentation (link above) is even better. The issue is how complex the modelling is: it involves a database- domain, view domain etc. To achieve a succint syntax for this (aka :parse-as list :present-as list) is quite an achievement. Besides that syntax is extendable... Not sure how other frameworks handle this issue, in general it can be explained by the 1 order --> multiple order line-items example. For example, I think Smart GWT handles this case. > I understood that the main idea behind the data/view framework > provided by Weblocks should (at least) provide you some kind of out-of- > the-box ability to model your DB with basically specifying your data > model and scaffolding the views around the data model. > After you've build some crude UI around your data (using the > scaffolding) you can add some sugar to make the UI beautiful with your > own widgets. Yes in general, scaffolding works decently for simple data models in a particular language (like English). The UI is *very* crude for many reasons. For example, I once tried to see how to model many-many relationships in RoR and ugh, that nauseous feeling still wells up inside me as I think about it. With the person class from my previous post, as the current scaffolding has it, it'll just display the scaffolding for that object in the same form, that is, the fields for person and contact-info will be interleaved. Assuming (say) contact info contains an object location-info, those fields will also be mixed in (the mechanism for this is view mixins). Is there a better way of doing this (that will work even when javascript is disabled)? I don't know.. What improvements would you suggest to this scenario? I can think of object-composition slots having a popup to edit that object only, using scaffolding, but what if that object also has an encapsulated/ composed object? And popups don't work in the absence of javascript, and dialogs cannot be nested .. So at some point you have specify the views yourself and can't depend on scaffolding. Another issue is the instant you add a slot to the datamodel, it'll show up in the scaffolded view. Often, this is not what you want, so you have to add (slot :hidep t) to that view. Anyway, please suggest a syntax you'd like to see for defview (I think list-presentation, popup-editor-presentation, mixin-presentation, collapsible-div-presentation are all good, implementable ideas). -- 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.
