Orbeon Forms community mailing list

hierarchical forms without nested XForms controls in Orbeon

Classic

List

Threaded

14 messages Options

Philip.Cantin

hierarchical forms without nested XForms controls in Orbeon

While working with nested repeats, I've come to the realization that displaying recursive sections that pertain to parts of an XML schema won't be easy with nested repeats.

Then I remember coming across this article here:

http://www.nabble.com/arbitrarily-nested-document--td16947606.html#a16948126

I am interested in doing exactly what Jaime was trying to do - build a form based on an XML schema with some recursive elements. Erik mentioned building a UI that didn't require nested XForms controls. Is this even possible to do with a hierarchical form? And if so, what would be a rough idea of a possible design layout for such a structure that would also work within Orbeon? Maybe referencing the repeats somehow?

Any ideas/suggestions are certainly welcome!

---Philip

Alessandro Vernet

Re: hierarchical forms without nested XForms controls in Orbeon

Administrator

Philip,

Philip.Cantin wrote

While working with nested repeats, I've come to the realization that displaying recursive sections that pertain to parts of an XML schema won't be easy with nested repeats.

Then I remember coming across this article here:

http://www.nabble.com/arbitrarily-nested-document--td16947606.html#a16948126

I am interested in doing exactly what Jaime was trying to do - build a form based on an XML schema with some recursive elements. Erik mentioned building a UI that didn't require nested XForms controls. Is this even possible to do with a hierarchical form? And if so, what would be a rough idea of a possible design layout for such a structure that would also work within Orbeon? Maybe referencing the repeats somehow?

If you want to support an arbitrarily deep level of nesting, you will have to generate the XForms, for instance with XSLT. Or am I misunderstanding your question?

Alex

Philip.Cantin

Re: hierarchical forms without nested XForms controls in Orbeon

Alex,

Well, I'm not sure yet if you are or aren't. I'll try illustrating my desired goal a bit more, just to be sure.

In particular, let's say I have the following XForms instance that is currently being represented by a group of XForms controls separated by fieldsets:

<root>
<element1>
<element2>
<element3 />
</element2>
</element1>
</root>

And then let's say that the UI has add/delete controls, such that adding <element2> displays a part of the UI corresponding to <element3>, and adding <element1> displays a part of the UI corresponding to <element2> and <element3>.

Suppose that, inside the UI corresponding to <element3>, there is a trigger to add the entire UI corresponding to <element1>, <element2>, and <element3>, INSIDE of <element3>'s fieldset. In other words, recursion takes place within <element3>'s UI, and the resulting instance would look like this:

<root>
<element1>
<element2>
<element3>
<element1>
<element2>
<element3 />
</element2>
</element1>
</element3>
</element2>
</element1>
</root>

Is this possible in Orbeon with nested repeats? Is this what I would need XSLT for? Or perhaps creating separate XForms documents (some for the recursive controls, and one for the main document) would be a better approach?

Or perhaps there is a way to reference the markup that is within repeats? In other words, if I have something like this:

<xf:repeat id="repeat-1" nodeset="...">
...
control-set-1
...
<xf:repeat id="repeat-2" nodeset="...">
...
control-set-2
...
<xf:repeat id="repeat-3 nodeset="...">
...
control-set-3
...
</xf:repeat>
</xf:repeat>
<xf:repeat>

Is there a way to get control-set-3, for example, to display in the XForms document by accessing/referencing it somehow OUTSIDE of the entire repeat structure?

I hope I am being clear enough in my use case; please be sure to let me know if I am not. :-)

---Philip

Alessandro Vernet wrote

Philip,

Philip.Cantin wrote

While working with nested repeats, I've come to the realization that displaying recursive sections that pertain to parts of an XML schema won't be easy with nested repeats.

Then I remember coming across this article here:

http://www.nabble.com/arbitrarily-nested-document--td16947606.html#a16948126

I am interested in doing exactly what Jaime was trying to do - build a form based on an XML schema with some recursive elements. Erik mentioned building a UI that didn't require nested XForms controls. Is this even possible to do with a hierarchical form? And if so, what would be a rough idea of a possible design layout for such a structure that would also work within Orbeon? Maybe referencing the repeats somehow?

If you want to support an arbitrarily deep level of nesting, you will have to generate the XForms, for instance with XSLT. Or am I misunderstanding your question?

Alex

Alessandro Vernet

Re: hierarchical forms without nested XForms controls in Orbeon

Administrator

Philip,

Philip.Cantin wrote

Suppose that, inside the UI corresponding to <element3>, there is a trigger to add the entire UI corresponding to <element1>, <element2>, and <element3>, INSIDE of <element3>'s fieldset. In other words, recursion takes place within <element3>'s UI, and the resulting instance would look like this:

<root>
<element1>
<element2>
<element3>
<element1>
<element2>
<element3 />
</element2>
</element1>
</element3>
</element2>
</element1>
</root>

Thank you for the clarification. Unfortunately you can't do this in a generic way. You can have:

<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>

But when you add an element1 inside element3, nothing will happen. For this to work you'd need to write:

<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>

Of course you can do this and put "control-set-1" (1 to 3) in separate files that you XInclude, so you don't have to repeat all the controls. But then you can't insert another element1 into the element3 at the deepest level. You can write the following to support one more level:

<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
<xforms:repeat nodeset="element1">
control-set-1
<xforms:repeat nodeset="element2">
control-set-2
<xforms:repeat nodeset="element3">
control-set-3
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>
</xforms:repeat>

The bottom line is that you need to decide in advance how many levels you want to support. This is a limitation of XForms (not Orbeon Forms). I.e. there are no recursive repeats in XForms. A way around this is to do a round-trip to the server (replace="all") and generate the xforms:repeat in XSLT based on the data.

Alex

Roald de Wit-2

Re: Re: hierarchical forms without nested XForms controls in Orbeon

Hi Alessandro,

Alessandro Vernet wrote:
> The bottom line is that you need to decide in advance how many levels you
> want to support. This is a limitation of XForms (not Orbeon Forms). I.e.
> there are no recursive repeats in XForms. A way around this is to do a
> round-trip to the server (replace="all") and generate the xforms:repeat in
> XSLT based on the data.
>
Would this round-trip to the server be visible to the user, i.e. a
visible page refresh (as in the 'old' days before AJAX) or could this be
done without the user noticing it?
Do you have an example that does this?

Regards,

Roald

--
Roald de Wit
Software Engineer
[hidden email]

Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/

The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Alessandro Vernet

Re: Re: hierarchical forms without nested XForms controls in Orbeon

Administrator

Roald,

Roald de Wit-2 wrote

Would this round-trip to the server be visible to the user, i.e. a
visible page refresh (as in the 'old' days before AJAX) or could this be
done without the user noticing it?
Do you have an example that does this?

Yes, it would be a full page reload, where the HTML is downloaded again from the server, not just an Ajax request. I don't have an example that does this exactly, but essentially you can do this by either:

1) Storing with a <xforms:setvalue> the "level" needed in an instance, running an <xforms:submission replace="all"> that submits that instance.
2) Passing the level as a request parameter on the URL with <xforms:load>.

#1 is a bit simpler because you can access the submitted instance as with doc('input:instance'). If you do #2 you can use the page flow to "extract" the request parameter and store it in the instance. See:

http://www.orbeon.com/ops/doc/reference-page-flow#url-extraction

Alex

Philip.Cantin

Re: hierarchical forms without nested XForms controls in Orbeon

In reply to this post by Alessandro Vernet

Alex,

Alessandro Vernet wrote

A way around this is to do a round-trip to the server (replace="all") and generate the xforms:repeat in XSLT based on the data.

I wanted to ask if you could elaborate a little more on this. In particular:

1) If instance('views') holds the current instance data I'd like to be changed (with the nested repeats and all), then this is the instance that needs to be submitted in the <xforms:submission> statement, right?
2) Is XPL necessary to run an XSLT when a submission occurs upon trigger click?

My thinking of the problem, at the moment, is going like this (and please let me know if I'm misunderstanding something):

1) When wanting to recursively add a section, I would want to do an <xforms:insert> which changes this:

<1>
<2>
<3 /> <--- section with the "add" trigger
</2>
</1>

into this:

<1>
<2>
<3>
<1>
<2>
<3/>
</2>
</1>
</3>
</2>
</1>

I would also need to have the trigger dispatch an submission that looks something like this:

<xf:submission ref="instance('views')" id="lworkcit-refresh" action="/path/to/page" method="post" replace="all" validate="false" />

2) Originally, /path/to/page, in my page_flow.xml, was the first page loaded, and I thought loading the page again (and forcing a round-trip to the server) would cause the UI to be updated appropriately. This doesn't seem to work, and I'd like to try the 'generate the xforms:repeat in XSLT based on the data' route.

3) I'm figuring the page pointing to /path/to/page should have an XPL model attached to it, which uses an XSLT processor to transform the data from instance('views'). If this is a good approach, then how is the transformed data placed back into the instance?

Forgive my somewhat amateur questions, but I'm still getting my feet wet with XPL. :-) Thanks in advance!

---Philip

Hank Ratzesberger

Re: Re: hierarchical forms without nested XForms controls in Orbeon

Hi Philip,

If I have understood...

On Sep 30, 2009, at 2:56 PM, Philip.Cantin wrote:

>
> Alex,
>
>
> Alessandro Vernet wrote:
>>
>> A way around this is to do a round-trip to the server
>> (replace="all") and
>> generate the xforms:repeat in XSLT based on the data.
>>
>
> I wanted to ask if you could elaborate a little more on this. In
> particular:
>
> 1) If instance('views') holds the current instance data I'd like to be
> changed (with the nested repeats and all), then this is the
> instance that
> needs to be submitted in the <xforms:submission> statement, right?

If you do a replace="all" then the whole page will be refreshed. The
state
of all your models will be lost, about the same as if the user
clicked refresh.
If there is any other data you need to carry over, then you will need
to pass
that as well in the submission or use session listeners, etc.

> 2) Is XPL necessary to run an XSLT when a submission occurs upon
> trigger
> click?

No. If your page is the view="" attribute, and it contains the XSLT
namespace:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:version="2.0">

Then it will be processed by page-flow controller. You can use any
xsl elements.
<xsl:for-each> is convenient.

I'm not ready to comment on the rest of this, except to say, look at the
explanation for the pfc

http://www.orbeon.com/ops/doc/reference-page-flow#default-submission

Your submission can point to the same target as your page.

Regards,
Hank

>
> My thinking of the problem, at the moment, is going like this (and
> please
> let me know if I'm misunderstanding something):
>
>
> 1) When wanting to recursively add a section, I would want to do an
> <xforms:insert> which changes this:
>
> <1>
> <2>
> <3 /> <--- section with the "add" trigger
> </2>
> </1>
>
> into this:
>
>
> <1>
> <2>
> <3>
> <1>
> <2>
> <3/>
> </2>
> </1>
> </3>
> </2>
> </1>
>
> I would also need to have the trigger dispatch an submission that
> looks
> something like this:
>
> <xf:submission ref="instance('views')" id="lworkcit-refresh"
> action="/path/to/page" method="post" replace="all" validate="false" />
>
> 2) Originally, /path/to/page, in my page_flow.xml, was the first page
> loaded, and I thought loading the page again (and forcing a round-
> trip to
> the server) would cause the UI to be updated appropriately. This
> doesn't
> seem to work, and I'd like to try the 'generate the xforms:repeat
> in XSLT
> based on the data' route.
>
> 3) I'm figuring the page pointing to /path/to/page should have an
> XPL model
> attached to it, which uses an XSLT processor to transform the data
> from
> instance('views'). If this is a good approach, then how is the
> transformed
> data placed back into the instance?
>
>
> Forgive my somewhat amateur questions, but I'm still getting my
> feet wet
> with XPL. :-) Thanks in advance!
>
>
> ---Philip
>
>
>
> --
> View this message in context: http://www.nabble.com/hierarchical-
> forms-without-nested-XForms-controls-in-Orbeon-
> tp23548575p25689782.html
> Sent from the ObjectWeb OPS - Users mailing list archive at
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

Hank Ratzesberger
NEES@UCSB
Institute for Crustal Studies,
University of California, Santa Barbara
805-893-8042

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Philip.Cantin

Re: Re: hierarchical forms without nested XForms controls in Orbeon

Thanks for the reply, Hank. :-) I think I've got a better understanding of what to do now, and I've been able to incorporate generic XSLT in my forms. That leaves me with one (hopefully) final question.

I have a nested XBL component structure that looks like this (where each XBL component is represented by fr:n):

---CONTENT OF FR:1---

<xf:repeat>
...XHTML content...
<fr:2 />
</xf:repeat>

---CONTENT OF FR:2---

<xf:repeat>
...XHTML content...
<fr:3 />
</xf:repeat>

---CONTENT OF FR:3---

<xf:repeat>
...XHTML content...
---WHERE I WOULD LIKE RECURSION TO HAPPEN (perhaps have <fr:1 /> be placed here?)---
</xf:repeat>

For actually implementing the recursion mechanism, I was wondering if it was possible to place the <fr:1> component inside <fr:3> without a StackOverflowError. Can variable tracking be possible in this case, such as a variable that knows when to stop the recursion? Or is there no choice but to implement something like this:

<xsl:if test="$recursion-level = 1">
<fr:recursion1 /> <--- XBL component that reflects a repeat structure that recurses once
</xsl:if>
<xsl:if test="$recursion-level = 2">
<fr:recursion2 /> <--- XBL component that reflects a repeat structure that recurses twice
</xsl:if>

...

Thanks in advance for any help or suggestions offered! :-) And please let me know if anything I said is unclear.

Hank Ratzesberger wrote

Hi Philip,

If I have understood...

On Sep 30, 2009, at 2:56 PM, Philip.Cantin wrote:

>
> Alex,
>
>
> Alessandro Vernet wrote:
>>
>> A way around this is to do a round-trip to the server
>> (replace="all") and
>> generate the xforms:repeat in XSLT based on the data.
>>
>
> I wanted to ask if you could elaborate a little more on this. In
> particular:
>
> 1) If instance('views') holds the current instance data I'd like to be
> changed (with the nested repeats and all), then this is the
> instance that
> needs to be submitted in the <xforms:submission> statement, right?

If you do a replace="all" then the whole page will be refreshed. The
state
of all your models will be lost, about the same as if the user
clicked refresh.
If there is any other data you need to carry over, then you will need
to pass
that as well in the submission or use session listeners, etc.

> 2) Is XPL necessary to run an XSLT when a submission occurs upon
> trigger
> click?

No. If your page is the view="" attribute, and it contains the XSLT
namespace:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:version="2.0">

Then it will be processed by page-flow controller. You can use any
xsl elements.
<xsl:for-each> is convenient.

I'm not ready to comment on the rest of this, except to say, look at the
explanation for the pfc

http://www.orbeon.com/ops/doc/reference-page-flow#default-submission

Your submission can point to the same target as your page.

Regards,
Hank

>
> My thinking of the problem, at the moment, is going like this (and
> please
> let me know if I'm misunderstanding something):
>
>
> 1) When wanting to recursively add a section, I would want to do an
> <xforms:insert> which changes this:
>
> <1>
> <2>
> <3 /> <--- section with the "add" trigger
> </2>
> </1>
>
> into this:
>
>
> <1>
> <2>
> <3>
> <1>
> <2>
> <3/>
> </2>
> </1>
> </3>
> </2>
> </1>
>
> I would also need to have the trigger dispatch an submission that
> looks
> something like this:
>
> <xf:submission ref="instance('views')" id="lworkcit-refresh"
> action="/path/to/page" method="post" replace="all" validate="false" />
>
> 2) Originally, /path/to/page, in my page_flow.xml, was the first page
> loaded, and I thought loading the page again (and forcing a round-
> trip to
> the server) would cause the UI to be updated appropriately. This
> doesn't
> seem to work, and I'd like to try the 'generate the xforms:repeat
> in XSLT
> based on the data' route.
>
> 3) I'm figuring the page pointing to /path/to/page should have an
> XPL model
> attached to it, which uses an XSLT processor to transform the data
> from
> instance('views'). If this is a good approach, then how is the
> transformed
> data placed back into the instance?
>
>
> Forgive my somewhat amateur questions, but I'm still getting my
> feet wet
> with XPL. :-) Thanks in advance!
>
>
> ---Philip
>
>
>
> --
> View this message in context: http://www.nabble.com/hierarchical-
> forms-without-nested-XForms-controls-in-Orbeon-
> tp23548575p25689782.html
> Sent from the ObjectWeb OPS - Users mailing list archive at
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the ops-users@ow2.org
> mailing list.
> To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
> For general help: mailto:sympa@ow2.org?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

Hank Ratzesberger
NEES@UCSB
Institute for Crustal Studies,
University of California, Santa Barbara
805-893-8042

--
You receive this message as a subscriber of the ops-users@ow2.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
For general help: mailto:sympa@ow2.org?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Hank Ratzesberger

Re: Re: Re: hierarchical forms without nested XForms controls in Orbeon

Hi Philip,

On Oct 6, 2009, at 4:58 PM, Philip.Cantin wrote:

>
> <xsl:if test="$recursion-level = 1">
> <fr:recursion1 /> <--- XBL component that reflects a repeat
> structure
> that recurses once
> </xsl:if>
> <xsl:if test="$recursion-level = 2">
> <fr:recursion2 /> <--- XBL component that reflects a repeat
> structure
> that recurses twice
> </xsl:if>
>
> ...
>
> Thanks in advance for any help or suggestions offered! :-) And
> please let me
> know if anything I said is unclear.

Because xlst is a processing step that is performed before the xhtml is
given to the xforms engine, it is a little unclear what order things
will
happen here. You can use xslt to create the xbl and xf elements but not
the other way around.

Also, the xslt must be specifically given data, it does not have access
to any model/instance except by submission, default submission or an
xpl model.

Cheers,
Hank

>
>
>
> Hank Ratzesberger wrote:
>>
>> Hi Philip,
>>
>> If I have understood...
>>
>> On Sep 30, 2009, at 2:56 PM, Philip.Cantin wrote:
>>
>>>
>>> Alex,
>>>
>>>
>>> Alessandro Vernet wrote:
>>>>
>>>> A way around this is to do a round-trip to the server
>>>> (replace="all") and
>>>> generate the xforms:repeat in XSLT based on the data.
>>>>
>>>
>>> I wanted to ask if you could elaborate a little more on this. In
>>> particular:
>>>
>>> 1) If instance('views') holds the current instance data I'd like
>>> to be
>>> changed (with the nested repeats and all), then this is the
>>> instance that
>>> needs to be submitted in the <xforms:submission> statement, right?
>>
>> If you do a replace="all" then the whole page will be refreshed. The
>> state
>> of all your models will be lost, about the same as if the user
>> clicked refresh.
>> If there is any other data you need to carry over, then you will need
>> to pass
>> that as well in the submission or use session listeners, etc.
>>
>>
>>> 2) Is XPL necessary to run an XSLT when a submission occurs upon
>>> trigger
>>> click?
>>
>> No. If your page is the view="" attribute, and it contains the XSLT
>> namespace:
>>
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> xsl:version="2.0">
>>
>> Then it will be processed by page-flow controller. You can use any
>> xsl elements.
>> <xsl:for-each> is convenient.
>>
>> I'm not ready to comment on the rest of this, except to say, look
>> at the
>> explanation for the pfc
>>
>> http://www.orbeon.com/ops/doc/reference-page-flow#default-submission
>>
>> Your submission can point to the same target as your page.
>>
>> Regards,
>> Hank
>>
>>
>>>
>>> My thinking of the problem, at the moment, is going like this (and
>>> please
>>> let me know if I'm misunderstanding something):
>>>
>>>
>>> 1) When wanting to recursively add a section, I would want to do an
>>> <xforms:insert> which changes this:
>>>
>>> <1>
>>> <2>
>>> <3 /> <--- section with the "add" trigger
>>> </2>
>>> </1>
>>>
>>> into this:
>>>
>>>
>>> <1>
>>> <2>
>>> <3>
>>> <1>
>>> <2>
>>> <3/>
>>> </2>
>>> </1>
>>> </3>
>>> </2>
>>> </1>
>>>
>>> I would also need to have the trigger dispatch an submission that
>>> looks
>>> something like this:
>>>
>>> <xf:submission ref="instance('views')" id="lworkcit-refresh"
>>> action="/path/to/page" method="post" replace="all"
>>> validate="false" />
>>>
>>> 2) Originally, /path/to/page, in my page_flow.xml, was the first
>>> page
>>> loaded, and I thought loading the page again (and forcing a round-
>>> trip to
>>> the server) would cause the UI to be updated appropriately. This
>>> doesn't
>>> seem to work, and I'd like to try the 'generate the xforms:repeat
>>> in XSLT
>>> based on the data' route.
>>>
>>> 3) I'm figuring the page pointing to /path/to/page should have an
>>> XPL model
>>> attached to it, which uses an XSLT processor to transform the data
>>> from
>>> instance('views'). If this is a good approach, then how is the
>>> transformed
>>> data placed back into the instance?
>>>
>>>
>>> Forgive my somewhat amateur questions, but I'm still getting my
>>> feet wet
>>> with XPL. :-) Thanks in advance!
>>>
>>>
>>> ---Philip
>>>
>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/hierarchical-
>>> forms-without-nested-XForms-controls-in-Orbeon-
>>> tp23548575p25689782.html
>>> Sent from the ObjectWeb OPS - Users mailing list archive at
>>> Nabble.com.
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the [hidden email]
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> Hank Ratzesberger
>> NEES@UCSB
>> Institute for Crustal Studies,
>> University of California, Santa Barbara
>> 805-893-8042
>>
>>
>>
>>
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]
>> mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>
> --
> View this message in context: http://www.nabble.com/hierarchical-
> forms-without-nested-XForms-controls-in-Orbeon-
> tp23548575p25778484.html
> Sent from the ObjectWeb OPS - Users mailing list archive at
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

Philip.Cantin

Re: Re: Re: hierarchical forms without nested XForms controls in Orbeon

Okay, maybe I am quite a bit more lost than I had originally thought.

How can the XSLT engine access XForms instance data without using an XPL model, and purely relying on an xforms:submission? I do know that, for example, using <xsl:if> statements can only see variables within the XSLT context and not the XForms context. Once a submission occurs, how then can the XForms data be retrieved by XSLT statements?

Maybe this would help everyone understand where I'm coming from. I've attached a simple example to this message illustrating where I am with trying to implement a basic recursion mechanism based on XSLT (using the idea of "repeats within XSLT" that Alex had mentioned in a previous reply to this thread). Citeinfo.xbl is where the recursion is supposed to happen. It's a number of files, so it can't be run in the sandbox, but I'm able to run it using http://localhost:8080/orbeon/xforms-xbl-test/.

Mainly, I'd like to know where I'm going wrong with my approach to the problem based on my code, and if a XForms/XBL approach is possible with this problem (with traces of XSLT), or if I'm going to need my XBL components be XSLT stylesheets instead.

Thanks again for your insight Hank, and in advance to anyone else who can help shed some light on this.

---Philip

xforms-xbl-test3.zip

Hank Ratzesberger wrote

Hi Philip,

On Oct 6, 2009, at 4:58 PM, Philip.Cantin wrote:

>
> <xsl:if test="$recursion-level = 1">
> <fr:recursion1 /> <--- XBL component that reflects a repeat
> structure
> that recurses once
> </xsl:if>
> <xsl:if test="$recursion-level = 2">
> <fr:recursion2 /> <--- XBL component that reflects a repeat
> structure
> that recurses twice
> </xsl:if>
>
> ...
>
> Thanks in advance for any help or suggestions offered! :-) And
> please let me
> know if anything I said is unclear.

Because xlst is a processing step that is performed before the xhtml is
given to the xforms engine, it is a little unclear what order things
will
happen here. You can use xslt to create the xbl and xf elements but not
the other way around.

Also, the xslt must be specifically given data, it does not have access
to any model/instance except by submission, default submission or an
xpl model.

Cheers,
Hank

Hank Ratzesberger

Re: Re: Re: Re: hierarchical forms without nested XForms controls in Orbeon

Hi Philip,

On Oct 7, 2009, at 11:30 AM, Philip.Cantin wrote:

>
> Okay, maybe I am quite a bit more lost than I had originally thought.
>
> How can the XSLT engine access XForms instance data without using
> an XPL
> model, and purely relying on an xforms:submission? I do know that, for
> example, using <xsl:if> statements can only see variables within
> the XSLT
> context and not the XForms context. Once a submission occurs, how
> then can
> the XForms data be retrieved by XSLT statements?

The XSLT step occurs in page-flow epilogue.

http://www.orbeon.com/ops/doc/reference-page-flow#accessing-submission

It's not completely clear to me because I don't use the feature
this way... but I believe that to access the data in XSL from a
submission, it must have the attribute replace="all" which will
refresh the page and hence re-process it the XSLT.

That's all I can offer at this time.

--Hank

>
> Maybe this would help everyone understand where I'm coming from. I've
> attached a simple example to this message illustrating where I am with
> trying to implement a basic recursion mechanism based on XSLT
> (using the
> idea of "repeats within XSLT" that Alex had mentioned in a previous
> reply to
> this thread). Citeinfo.xbl is where the recursion is supposed to
> happen.
> It's a number of files, so it can't be run in the sandbox, but I'm
> able to
> run it using http://localhost:8080/orbeon/xforms-xbl-test/.
>
> Mainly, I'd like to know where I'm going wrong with my approach to the
> problem based on my code, and if a XForms/XBL approach is possible
> with this
> problem (with traces of XSLT), or if I'm going to need my XBL
> components be
> XSLT stylesheets instead.
>
>
> Thanks again for your insight Hank, and in advance to anyone else
> who can
> help shed some light on this.
>
>
> ---Philip
>
>
> http://www.nabble.com/file/p25791664/xforms-xbl-test3.zip
> xforms-xbl-test3.zip
>
>
>
> Hank Ratzesberger wrote:
>>
>> Hi Philip,
>>
>>
>> On Oct 6, 2009, at 4:58 PM, Philip.Cantin wrote:
>>
>>>
>>> <xsl:if test="$recursion-level = 1">
>>> <fr:recursion1 /> <--- XBL component that reflects a repeat
>>> structure
>>> that recurses once
>>> </xsl:if>
>>> <xsl:if test="$recursion-level = 2">
>>> <fr:recursion2 /> <--- XBL component that reflects a repeat
>>> structure
>>> that recurses twice
>>> </xsl:if>
>>>
>>> ...
>>>
>>> Thanks in advance for any help or suggestions offered! :-) And
>>> please let me
>>> know if anything I said is unclear.
>>
>>
>> Because xlst is a processing step that is performed before the
>> xhtml is
>> given to the xforms engine, it is a little unclear what order things
>> will
>> happen here. You can use xslt to create the xbl and xf elements
>> but not
>> the other way around.
>>
>> Also, the xslt must be specifically given data, it does not have
>> access
>> to any model/instance except by submission, default submission or an
>> xpl model.
>>
>> Cheers,
>> Hank
>>
>
> --
> View this message in context: http://www.nabble.com/hierarchical-
> forms-without-nested-XForms-controls-in-Orbeon-
> tp23548575p25791664.html
> Sent from the ObjectWeb OPS - Users mailing list archive at
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

Erik Bruchez-3

Re: Re: Re: Re: Re: hierarchical forms without nested XForms controls in Orbeon

What about a solution without XSLT?

http://pastie.org/656922

The idea is that you use a single level of repeat, but it shows
visually like multiple levels.

-Erik

On Wed, Oct 7, 2009 at 4:23 PM, Hank Ratzesberger
<[hidden email]> wrote:

> Hi Philip,
>
> On Oct 7, 2009, at 11:30 AM, Philip.Cantin wrote:
>
>>
>> Okay, maybe I am quite a bit more lost than I had originally thought.
>>
>> How can the XSLT engine access XForms instance data without using an XPL
>> model, and purely relying on an xforms:submission? I do know that, for
>> example, using <xsl:if> statements can only see variables within the XSLT
>> context and not the XForms context. Once a submission occurs, how then can
>> the XForms data be retrieved by XSLT statements?
>
> The XSLT step occurs in page-flow epilogue.
>
> http://www.orbeon.com/ops/doc/reference-page-flow#accessing-submission
>
> It's not completely clear to me because I don't use the feature
> this way... but I believe that to access the data in XSL from a
> submission, it must have the attribute replace="all" which will
> refresh the page and hence re-process it the XSLT.
>
> That's all I can offer at this time.
>
> --Hank
>
>>
>> Maybe this would help everyone understand where I'm coming from. I've
>> attached a simple example to this message illustrating where I am with
>> trying to implement a basic recursion mechanism based on XSLT (using the
>> idea of "repeats within XSLT" that Alex had mentioned in a previous reply
>> to
>> this thread). Citeinfo.xbl is where the recursion is supposed to happen.
>> It's a number of files, so it can't be run in the sandbox, but I'm able to
>> run it using http://localhost:8080/orbeon/xforms-xbl-test/.
>>
>> Mainly, I'd like to know where I'm going wrong with my approach to the
>> problem based on my code, and if a XForms/XBL approach is possible with
>> this
>> problem (with traces of XSLT), or if I'm going to need my XBL components
>> be
>> XSLT stylesheets instead.
>>
>>
>> Thanks again for your insight Hank, and in advance to anyone else who can
>> help shed some light on this.
>>
>>
>> ---Philip
>>
>>
>> http://www.nabble.com/file/p25791664/xforms-xbl-test3.zip
>> xforms-xbl-test3.zip
>>
>>
>>
>> Hank Ratzesberger wrote:
>>>
>>> Hi Philip,
>>>
>>>
>>> On Oct 6, 2009, at 4:58 PM, Philip.Cantin wrote:
>>>
>>>>
>>>> <xsl:if test="$recursion-level = 1">
>>>> <fr:recursion1 /> <--- XBL component that reflects a repeat
>>>> structure
>>>> that recurses once
>>>> </xsl:if>
>>>> <xsl:if test="$recursion-level = 2">
>>>> <fr:recursion2 /> <--- XBL component that reflects a repeat
>>>> structure
>>>> that recurses twice
>>>> </xsl:if>
>>>>
>>>> ...
>>>>
>>>> Thanks in advance for any help or suggestions offered! :-) And
>>>> please let me
>>>> know if anything I said is unclear.
>>>
>>>
>>> Because xlst is a processing step that is performed before the xhtml is
>>> given to the xforms engine, it is a little unclear what order things
>>> will
>>> happen here. You can use xslt to create the xbl and xf elements but not
>>> the other way around.
>>>
>>> Also, the xslt must be specifically given data, it does not have access
>>> to any model/instance except by submission, default submission or an
>>> xpl model.
>>>
>>> Cheers,
>>> Hank
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/hierarchical-forms-without-nested-XForms-controls-in-Orbeon-tp23548575p25791664.html
>> Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email] mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> Hank Ratzesberger
> NEES@UCSB
> Institute for Crustal Studies,
> University of California, Santa Barbara
> 805-893-8042
>
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing
> list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Alessandro Vernet

Re: Re: Re: Re: Re: Re: hierarchical forms without nested XForms controls in Orbeon

Administrator

On Thu, Oct 15, 2009 at 4:35 PM, Erik Bruchez <[hidden email]> wrote:
> What about a solution without XSLT?
>
> http://pastie.org/656922
>
> The idea is that you use a single level of repeat, but it shows
> visually like multiple levels.

We also put this tip online at:

http://wiki.orbeon.com/forms/how-to/edit-hierarchy

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet