> 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.
