You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Timothy Larson <ti...@yahoo.com> on 2003/09/11 21:06:50 UTC
[RT] Woody dynamic widgets design
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 <wd:widgets/> for reusable widget definitions.
Create <wd:include/> 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.
Sample form definition:
<wd:form xmlns:wd="http://apache.org/cocoon/woody/definition/1.0">
<wd:widgets id="fullname">
<wd:field id="firstname" required="true">
<wd:datatype base="string"/>
<wd:label>First Name</wd:label>
</wd:field>
<wd:field id="middlename" required="true">
<wd:datatype base="string"/>
<wd:label>Middle Name</wd:label>
</wd:field>
<wd:field id="lastname" required="true">
<wd:datatype base="string"/>
<wd:label>Last Name</wd:label>
</wd:field>
</wd:widgets>
<wd:union id="name" default="noname">
<wd:case id="noname"/>
<wd:case id="nickname">
<wd:field id="nickname" required="true">
<wd:datatype base="string"/>
<wd:label>Nickname</wd:label>
</wd:field>
</wd:case>
<wd:case id="fullname">
<wd:include id="fullname"/>
</wd:case>
</wd:union>
</wd:form>
Make the form template dynamic:
Rely on aggregation, etc. to ensure all templates are in the same source.
This will allow support for recursively nested unions.
Create a container <wt:templates/> for reusable templates.
Create <wt:include/> to reference the reusable template containers.
Create <wt:union/> to select templates based on the widget instance discriminants.
The context in <wt:union/> is the contained widgets so recursively included
templates will reference the proper widgets. We would need to introduce
xpath-like syntax (e.g. "/widget", "../widget", and "widget/widget") to allow
other widgets to be referenced from templates contained in a union.
Sample form template:
<page xmlns:wt="http://apache.org/cocoon/woody/template/1.0">
<title>The Title</title>
<content>
<wt:form-template action="#{$continuation/id}.continue" method="POST">
<wt:templates id="fullname">
<wt:widget-label id="firstname"/>: <wt:widget id="firstname"/>
<wt:widget-label id="middlename"/>: <wt:widget id="middlename"/>
<wt:widget-label id="lastname"/>: <wt:widget id="lastname"/>
</wt:templates>
<wt:union id="name">
<wt:case id="noname"/>
<wt:case id="nickname">
<wt:widget-label id="nickname"/>: <wt:widget id="nickname"/>
</wt:case>
<wt:case id="fullname">
<wt:include id="fullname"/>
</wt:case>
</wt:union>
<input type="submit"/>
</wt:form-template>
</content>
</page>
Make the binding dynamic:
I have not worked on this yet, but it will probably follow the same pattern
as the definitions and templates sections.
Make the flowscript support the dynamic widgets:
I will look at this next, along with the binding.
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?
--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
Posted by Timothy Larson <ti...@yahoo.com>.
--- Bruno Dumon <br...@outerthought.org> 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
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-09-11 at 22:32, Timothy Larson wrote:
> --- Bruno Dumon <br...@outerthought.org> 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
bruno@outerthought.org bruno@apache.org
Re: [RT] Woody dynamic widgets design
Posted by Timothy Larson <ti...@yahoo.com>.
--- Bruno Dumon <br...@outerthought.org> 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
Posted by Bruno Dumon <br...@outerthought.org>.
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 <wd:widgets/> for reusable widget definitions.
> Create <wd:include/> 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
bruno@outerthought.org bruno@apache.org
Re: [RT] Woody dynamic widgets design
Posted by Timothy Larson <ti...@yahoo.com>.
--- Sylvain Wallez <sy...@anyware-tech.com> 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 <union> 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 <wt:include> 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
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Timothy Larson wrote:
<snip/>
>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 <union> 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