Sylvain Wallez wrote:
> Ben Pope wrote:
>
> ><project>
> > <people>
> > <person id="0">
> > <name>Me</name>
> > </person>
> > <person id="1">
> > <name>You</name>
> > </person>
> > <person id="2">
> > <name>Him</name>
> > </person>
> > </people>
> > <rooms>
> > <room id="0">
> > <name>Lounge</name>
> > <person idref="0"/>
> > <person idref="1"/>
> > </room>
> > <room id="1">
> > <name>Kitchen</name>
> > <person idref="2"/>
> > </room>
> > </rooms>
> ></project>
> >
> >That describes a list of people which are in a particular
> room, so Me
> >and You are in the Lounge and Him is in the Kitchen.
> >
> >I want to have a form that displays, for a given room, a list of the
> >people in it.
<SNIP />
> Hmm... I hope I'm not the only one to do fancy CForms stuff :-/
>
> Your room repeater links to existing people through their ID
> but should
> display their name. This is typically a selection-list with IDs as
> labels and names as values.
Ahh yes. That makes sense for name. My first reaction is how do I easily
add fields such as age, favourite colour etc, and have those bind as well.
If I run a repeater over /rooms/person I want bindings that are equivalent
to:
<fb:value id="name" path="/project/people/[EMAIL PROTECTED]()/idref]/name"
/>
<fb:value id="age" path="/project/people/[EMAIL PROTECTED]()/idref]/age" />
Which would only be valid in an xslt, of course.
As mentioned before, I started work on an "xref-repeater" which would
understand my requirements - it's syntax was something like:
<fb:xref-repeater id="people"
source-parent-path="/project/[EMAIL PROTECTED]'0']"
source-row-path="person"
target-parent-path="/project/people"
target-row-path="person" />
It would then likely need a source-identity and target-identity, or some
other way of specifying the id=idref relationship.
Unfortunately I didn't get very far with it as I don't really understand the
o.a.c.forms.binding package, despite stepping through it in eclipse.
> About the ability to add new names at any level, this looks like a
> combo-box (editable dropdown). We've hacked such a thing for
> one of our
> projects, and basically the idea is to have a single widget
> be rendered
> as two inputs.
>
> Say you have
> <fd:field id="personref">
> <fd:selection-list src="cocoon:/person-selection-list"/>
> </fd:field>
That's identical (except names) to something I have to display a
selectionlist of person/names now.
> The editable combobox renders this as :
> - a dropdown list of name "personref" with the contents of the
> selection-list
> - an input of name "personref.label".
>
> When the user chooses in the dropdown, the selected value is
> copied to personref.label.
OK, I'm with you.
> When the user types in the personref.label input, a new
> option is added
> to the dropdown, having "new" as a value, and the typed text as label.
OK.
> On form submit, the flowscript checks if "personref" equals
> "new" and if
> true creates a new person with the name in the
> "personref.label" request
> parameter and replaces the "new" value with the newly created id.
>
> Binding can then go on as usual.
>
> This is a bit hacky, but it works :-)
That's excellent, Sylvain. I'll give it a go later.
