Re: [RT] Woody dynamic widgets design
--- Bruno Dumon <[EMAIL PROTECTED]> wrote: > On Thu, 2003-09-11 at 22:32, Timothy Larson wrote: > > The wd:union "switch" can default to having no child widgets and later > > switch to various sets of child widgets. Constrained only by the list of > > cases in the union, you can dynamically decide which widgets to create > > and when to create them. If you keep choosing to create sets of widgets > > which include union widgets, then you are giving yourself the option grow > > the widget tree as large as you like. > > Aha, now I get it. It's much better than I thought ;-) > > And you're probably going to use this in combination with a repeater to > get a repeating structure which can contain different sets of widgets on > each row? Yes, that's the plan. > > I prefer to direct processes with data instead of code because data is > > is easier to manipulate. > > yep, and that's a good decission. After all, the woody form definition > is a sort of schema language, and by doing things this way everything > remains described in the schema. (this also gives woody form definitions > similar power to xml schemas with their sequence/choice combo) Good, we are on the same page. > To touch some of the other topics in your previous mail: > > * If I understand it right the wd:widgets/wd:include functionality is > quite orthogonal to the wd:union proposal? I.e. the one does not really > have to do with the other? (just to know that I understood it right) Yes, wd:widgets and wd:include are intended for general use. The wd:union just happens to be my first use case that requires their functionality. I hope they will be useful for modularizing forms, and possibly be developed along with their siblings (wt:templates/wt:include and some analog in the binding and flowscripts) to where they can also provide a concept of subforms. So yes, it is pretty much a separate proposal, just presented here because the initial union use case requires it. I could not support specifying true recursive unions without wd:include, unless I was willing to have the widget definition file be infinitely large. In the implementation envisioned, wd:include allows for "lazy evaluation" like functional programming uses. > * On the aggregation: it would be nice if we could keep the current > functionality of storing filename/linumber information on each node in > the configuration DOM-tree, so that error messages can point to the > exact source locations. This would require doing the aggregation on the > DOM-tree rather than in a Cocoon pipeline. I'm willing to help out on > this if needed. Chances are I will need your help on this, thanks. > * on the xpath-addressing: could you give a concrete example of when > it's needed? A first implementation does not need this, so we could postpone the decision for later. Here is a (wet cement) example anyway: Say you have a top-level, non-rendered widget that stores some state. Way down nested somewhere in the widget tree you want to use this state to control the visual representation (template) selected for a widget. How do you refer to the top-level widget when your current context is deeply nested? > BTW, this is all very good stuff you're coming up with here! Thanks. I wish I could get to the Hackathon, but the city does not have any travel money. These things are a lot easier to design and implement when interacting with other programmers in person. --Tim Larson __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [RT] Woody dynamic widgets design
--- Sylvain Wallez <[EMAIL PROTECTED]> wrote: > Quick answer on the union : I very much like it, and actually was about > proposing something similar. We just need to add datatype, label and all > the usual stuff to the widget to allow automatic generation of > switchable panels (like in Woody's flowscript demo). Glad you like it :) We will also have to make sure the recursive applications of play nicely with the switchable panels and other features you have added. --Tim Larson __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [RT] Woody dynamic widgets design
Timothy Larson wrote:
Well, that is the preliminary view. Before the design gets finished and coded,
what do others think of this? Am I on the right track? What could be done better?
Quick answer on the union : I very much like it, and actually was about
proposing something similar. We just need to add datatype, label and all
the usual stuff to the widget to allow automatic generation of
switchable panels (like in Woody's flowscript demo).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Woody dynamic widgets design
On Thu, 2003-09-11 at 22:32, Timothy Larson wrote: > --- Bruno Dumon <[EMAIL PROTECTED]> wrote: > > a first quick reaction (the rest will be for tomorrow, have to leave > > now): what exactly should be understood here with "dynamic"? > > > > AFAIU the wd:union is a sort of switch which allows to programatically > > enable a set of widgets. > > The wd:union "switch" can default to having no child widgets and later > switch to various sets of child widgets. Constrained only by the list of > cases in the union, you can dynamically decide which widgets to create > and when to create them. If you keep choosing to create sets of widgets > which include union widgets, then you are giving yourself the option grow > the widget tree as large as you like. Aha, now I get it. It's much better than I thought ;-) And you're probably going to use this in combination with a repeater to get a repeating structure which can contain different sets of widgets on each row? > > > > However, I thought in earlier mails you were also implying to > > dynamically add new widgets (possibly with dynamically created widget > > definitions) to form instances. Or does the wd:union solve all your > > use-cases? > > I prefer to direct processes with data instead of code because data is > is easier to manipulate. yep, and that's a good decission. After all, the woody form definition is a sort of schema language, and by doing things this way everything remains described in the schema. (this also gives woody form definitions similar power to xml schemas with their sequence/choice combo) > The dynamically created widget definitions > were intended as a shortcut before I came up with this design. BTW, the > idea of reusing groups of widget and template definitions was inspired > by Marc's comments on the xReporter list [1]. I hope I did not mangle > his idea too much. That doesn't matter; I find it great how people sometimes come up with clever ideas by misunderstanding someone else suggestions. (though I don't know if that was the case here) To touch some of the other topics in your previous mail: * If I understand it right the wd:widgets/wd:include functionality is quite orthogonal to the wd:union proposal? I.e. the one does not really have to do with the other? (just to know that I understood it right) * On the aggregation: it would be nice if we could keep the current functionality of storing filename/linumber information on each node in the configuration DOM-tree, so that error messages can point to the exact source locations. This would require doing the aggregation on the DOM-tree rather than in a Cocoon pipeline. I'm willing to help out on this if needed. * on the xpath-addressing: could you give a concrete example of when it's needed? BTW, this is all very good stuff you're coming up with here! -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Woody dynamic widgets design
--- Bruno Dumon <[EMAIL PROTECTED]> wrote: > a first quick reaction (the rest will be for tomorrow, have to leave > now): what exactly should be understood here with "dynamic"? > > AFAIU the wd:union is a sort of switch which allows to programatically > enable a set of widgets. The wd:union "switch" can default to having no child widgets and later switch to various sets of child widgets. Constrained only by the list of cases in the union, you can dynamically decide which widgets to create and when to create them. If you keep choosing to create sets of widgets which include union widgets, then you are giving yourself the option grow the widget tree as large as you like. > > However, I thought in earlier mails you were also implying to > dynamically add new widgets (possibly with dynamically created widget > definitions) to form instances. Or does the wd:union solve all your > use-cases? I prefer to direct processes with data instead of code because data is is easier to manipulate. The dynamically created widget definitions were intended as a shortcut before I came up with this design. BTW, the idea of reusing groups of widget and template definitions was inspired by Marc's comments on the xReporter list [1]. I hope I did not mangle his idea too much. > > (will then comment on the rest later on). Thanks. --Tim Larson [1] http://lists.cocoondev.org/cgi-bin/ezmlm-cgi.py?1:msp:701:200307:olglmgpjpkocdbgobele >growing a more dynamic structure as would be required in this >case will call for some advanced flow-handling IMHO (it should >probably assemble itself out of smaller fixed portions with their >own woody-form) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [RT] Woody dynamic widgets design
On Thu, 2003-09-11 at 21:06, Timothy Larson wrote: > Proposal to allow the declarative specification of dynamic widgets in Woody: > (Use case that is driving dynamic widgets: web-based form and report design gui) > > Bruno, if you have a chance could you comment on this before you are gone for the > week? > > Make the form definition dynamic: > > Rely on aggregation, etc. to ensure all widget definitions are in the same source. > Create a container for reusable widget definitions. > Create to reference the reusable widget containers. > Create a new discriminated "union" widget with methods: > setCase(id) to change the distriminant and corresponding widgets. > getCase() to return the current discriminant id. > a first quick reaction (the rest will be for tomorrow, have to leave now): what exactly should be understood here with "dynamic"? AFAIU the wd:union is a sort of switch which allows to programatically enable a set of widgets. However, I thought in earlier mails you were also implying to dynamically add new widgets (possibly with dynamically created widget definitions) to form instances. Or does the wd:union solve all your use-cases? (will then comment on the rest later on). -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
