Drilling into the grid of objects which point to other objects...
Trastabuga
relationship between the objects.
Let's say we have a grid of blog posts which we instantiate with a
grid widget:
(make-instance 'gridedit
:name 'posts-grid
:data-class 'post
..........................
:view 'post-table-view
:item-data-view 'post-data-view
:item-form-view 'post-form-view))
When we drill into a "post" item, we'll get presented with post-form-
view which uses post class as scaffolding:
(defview post-form-view (:type form :inherit-from '(:scaffold
post)) ....)
Now I want to add "replies" to the post so that post class would look
something like
(defclass post ()
((id)
......
......
(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?
I tried extending post-form-view to look like
(defview reply-table-view (:type table :inherit-from '(:scaffold
post))
(id :hidep t))
(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).
Looks like I am missing something in understanding of how views work.
Please, nudge me in right direction.
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
I specified two levels here (like posts->replies) but in general there
could be any number of levels)
Thank you,
Andrei
nunb
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).
Trastabuga
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
nunb
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).
Trastabuga
(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 <nandan.bagc...@gmail.com> 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
Trastabuga
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to webl...@googlegroups.com.
To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Leslie P. Polzer
> 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?
1. view fields aren't part of the widget tree right now, so it's
difficult to have widgets that are part of a view field/
presentation behave.
2. you can't have forms within a form in HTML.
The solution to (1) is obvious (make view fields widgets), but (2) is
harder.
Leslie
Nandan Bagchee
2. you can't have forms within a form in HTML.
The solution to (1) is obvious (make view fields widgets), but (2) is
harder.
Leslie P. Polzer
> > 2. you can't have forms within a form in HTML.
>
> > The solution to (1) is obvious (make view fields widgets), but (2) is
> > harder.
>
> yeah. imho (and crockford's) javascript is *required* to fix html.
be popping up a dialog (need not be modal!) where the user can
edit the list in question.
More thoughts, maybe by the OP?
Leslie
Nandan Bagchee
> > 2. you can't have forms within a form in HTML.I've thought about solutions for (2) but the only sane thing seems to
>
> > The solution to (1) is obvious (make view fields widgets), but (2) is
> > harder.
>
> yeah. imho (and crockford's) javascript is *required* to fix html.
be popping up a dialog (need not be modal!) where the user can
edit the list in question.
Leslie P. Polzer
> > I've thought about solutions for (2) but the only sane thing seems to
> > be popping up a dialog (need not be modal!) where the user can
> > edit the list in question.
> >
> >
> When javascript is disabled, a weblocks-dialog would necessarily be modal? I
> don't know enough about the current dialog mechanism to speak to non-modal
> weblocks-dialogs.
the Weblocks sense.
The main point is just creating a container div outside of the form
and positioning it to appear at a convient spot (i.e. near the form)
with CSS. This may happen via a full request if JS isn't available
or an AJAX request else.
Trastabuga
into an issue of not having enough space on one page when I have a
dataform and a table below it (1->many).
For now I can get away with a dataform and a datagrid and a linked
into a composite widget to express that 1->many relationship.
This dataform+datagrid widget gets displayed when I drill into a table
by overriding dataedit-create-new-item-widget and dataedit-create-
drilldown-widget methods which will create that composite widget.
I plan to have a model which doesn't limit me with a number of levels
that an object can have (for example a post may have a number of
replies, which in turn, may have other replies).
The challenge that I will have is to have a form and a number of
tables open on the same page.
My question is, when I drill down into a table row, may I hide some of
the forms/tables that I already have displayed on the page?
>
> 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).
>
> candidate for inclusion in weblocks).
>
> Regarding views in general, and their scope:
>
> 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).
>
Nandan Bagchee
into an issue of not having enough space on one page when I have a
dataform and a table below it (1->many).
For now I can get away with a dataform and a datagrid and a linked
into a composite widget to express that 1->many relationship.
The challenge that I will have is to have a form and a number of
tables open on the same page.
My question is, when I drill down into a table row, may I hide some of
the forms/tables that I already have displayed on the page?
Trastabuga
data modeling system example (which mimics file tree with drives,
folders and files) so that we have objects with lists of other
objects.
Those interested may find this example here: http://github.com/lispercat/filetree.
Andrei