There was a typo: ":element-type level2" should be commented out.
On Apr 15, 12:28 pm, Trastabuga <[email protected]> wrote: > The syntax for editing lists should be pretty straightforward: > > (defclass level1 () > ((id) > (name :accessor level1-name :initarg :name :initform "" :type > string) > (level2-list :accessor level1-level2-list :initform nil :type > list :element-type level2))) > > (defclass level2 () > ((id) > (name :accessor level2-name :initarg :name :initform "" :type > string))) > > (defview level1-form-view (:type form :inherit-from '(:scaffold > level1)) > (id :hidep t) > (level2-list :type view :view '(table level2))) ;;This could be a > default drill-in view for any members of type list so you don't have > to explicitly specify it > > So that when we show level1 in a grid (we can add/delete/modify > elements) > (make-instance 'gridedit > :name 'level1-grid > :data-class 'level1 > :view '(table level1) > :item-data-view '(data level1) > :item-form-view 'level1-form-view) > > Now when we click on a row, we display level1-form-view which has a > table view for its level2 elements with add/delete buttons so we can > add/remove/modify level2 elements. > This is just a rough idea how it should work in my mind. > Do you see any challenges in implementing of this approach? I truly > believe that if we implement an easy way to model *any* tree data > structure with views we can really widen the Weblocks community and > make it a really usable framework not only for lisp gurus. > Once we can model any data with simple and easy to understand approach > we can build widgets around it to our heart content. > > On Apr 15, 1:14 am, nunb <[email protected]> wrote: > > > > 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 > > herehttp://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 > > athttp://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 > > forhttp://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.
