Now that I am starting to get a hang on modeling data, I happen to run
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?


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
> -- 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 weblo...@googlegroups.com.
To unsubscribe from this group, send email to 
weblocks+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en.

Reply via email to