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.