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.
