Thank you, Nandan. I'll try to see what I can do without using the views. But I am really concerned with what you said that views are not good at modeling trees. 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). 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. Please, correct me if I am wrong.
Thank you, Andrei On Apr 13, 11:48 pm, nunb <[email protected]> wrote: > > When we drill into a "post" item, we'll get presented with post-form-view > > which uses post class as scaffolding: > > This is what the default drilldown does in gridedit. This is ugly > because it draws the gridedit, and below that the post form. > > > (replies :accessor post-replies > > :initarg nil > > :initform nil > > :type post ;;(or some other type) > > :documentation "replies to the post"))) > > How do I add the ability for post-form-view to add/delete the replies? > > The post has a slot for its replies. But it is not necessary for the > post-form to handle the replies (and in fact, it is quite complicated > and the default dataforms are not designed to be *that* flexible, or > to look good doing it (it can be done though, with widget-suffix-fns > and the like)). > > I would suggest overriding dataedit-on-drilldown for the grid, and > creating a new post-widget (not a dataform) -- and in that post widget > you should present a link to "add comment" > > But if you want to continue using the post-form (with the caveats > above), add a widget-suffix-fn. that will render a line for "Add > comment" -- eg: > > :suffix-fn (f_ (do-dialog "Add reply" > (make-instance 'dataform :data (make-instance > 'reply) :on-success (f_ (push (dataform-data _) (post-replies > (dataform-data post-form))))) > > The above is a sketch, of course. Have you forked the project on > github? We could write code there. > > > I tried extending post-form-view to look like > > (defview reply-table-view (:type table :inherit-from '(:scaffold > > post)) > > (defview post-form-view (:type form :inherit-from '(:scaffold post)) > > ...... > > (replies:type mixin :view 'reply-table-view)) > > But this doesn't work giving an error that some function is nil (which > > is really hard to say which function is missing and where from looking > > at the debug output). > > Don't use scaffolding. Weblocks' scaffolding mechanism doesn't know > how to deal with a slot that's supposed to contain a list/array of > elements! > > > Looks like I am missing something in understanding of how views work. > > Please, nudge me in right direction. > > It will be much easier, imho, if you build your own widgets from > scratch, rather than attempt to push gridedit et. al beyond what they > can accomplish. > > > In general, I am looking for a generic method of creating a tree of > > persistent objects using views > > (something like root->obj_level1_1 > > obj_level1_2 > > obj_level1_3->obj_level2_1 > > obj_level2_2 > > ................. > > obj_level2_N > > ................. > > obj_level1_M > > Views are not good (imho) at modelling trees. For instance, if you > have a dataform for a post, that implies that there can be many post > replies... At best a dataform can handle 1-1 relationships between a > parent object and its slot. Even then, I prefer not to use scaffolded > views. > > Here is an example I use: > > (defview person-template-form-view.optional-name-contact (:type > templform :inherit-from '(:scaffold person) :caption > "Anagrafica" :file "person.entry") > (firstname :label #!"First name" :requiredp nil :parse-as person- > name) > (lastname :label #!"Last name" :requiredp nil :parse-as person- > name) > (contact-details :type mixin :view 'contact-template-form- > view.validated-minimum) > (location-details :hidep t)) > > In the example, contact-details is a slot whose initarg is something > like (make-instance 'contact-details-class) -- IOW the relationship > between a person entity and contact-details is 1-1. > > So I use a mixin view and specify it explicitly (instead of using > scaffolding). > > But for 1-Many relationships you'll have to write your own widget > (imho). -- 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.
