Specifying large number of pages in page-flow.xml

In an application with tens of pages to be displayed, if all these are declared in a single page-flow.xml, I am afraid the page-flow document will be unreadable and unmaintainable. Is there a way to modularize the control flow specified in page-flow.xml? For instance, is there a way to specify something along the lines of "include" or "import" multiple page-flows in a page-flow.xml?
What is the recommended way to solve the problem of a potentially large page-flow.xml file?

Chary



--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Chary,

I don't think so.

If the url's to your pages have regular
expression patterns, then you can possibly
group them using the pattern matcher.  I used
this to find the "index.xsl" or "*.xsl" files
associated with urls that end in "/" or in
some name "/support/customer" (for example would
find the file /support/customer.xsl.  (Mostly
this was to eliminate extensions in the urls.)
The following is for a third level url.  I needed
others for first and second level.

<page path-info="/mariner/([^/]*)/([^/]*)/(.*)"
  matcher="oxf:perl5-matcher"
  xforms="oxf:/mariner/default.xml"
  model="oxf:/mariner/default.xpl">
    <param ref="/form/directory"/>
    <param ref="/form/tertiary"/>
    <param ref="/form/file"/>
</page>

(I can forward the whole example if you wish.)

The pattern matcher could be used for whole
groups of files.  The documentation portlet
is one example, where whole groups of files
are handled by one page flow that matches
the pattern and an xpl file that (I think)
use the Request Generator to obtain the
rest.

HTH,
Hank


----- Original Message -----
To: <[hidden email]>
Sent: Tuesday, August 09, 2005 8:55 AM
Subject: [ops-users] Specifying large number of pages in page-flow.xml


> In an application with tens of pages to be displayed, if all these are declared in a single page-flow.xml, I am afraid the
> page-flow document will be unreadable and unmaintainable. Is there a way to modularize the control flow specified in
> page-flow.xml? For instance, is there a way to specify something along the lines of "include" or "import" multiple page-flows in a
> page-flow.xml?
> What is the recommended way to solve the problem of a potentially large page-flow.xml file?
>
> Chary
>
>


>




--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hank Ratzesberger wrote:

 > <page path-info="/mariner/([^/]*)/([^/]*)/(.*)"
 >  matcher="oxf:perl5-matcher"
 >  xforms="oxf:/mariner/default.xml"
 >  model="oxf:/mariner/default.xpl">
 >    <param ref="/form/directory"/>
 >    <param ref="/form/tertiary"/>
 >    <param ref="/form/file"/>
 > </page>

I should mention that with 3.0 beta:

o The xforms attribute is deprecated and replaced by the
   default-submission attribute. The point of this is to decouple
   entirely the PFC from the XForms implementation, while still
   allowing convenient integration not only with the OPS XForms engine,
   but with client-side XForms engines or client able to send XML data
   to OPS.

o The <param> element is deprecated as well and replaced by the
   <setvalue> element. The point of this is to provide an enhanced
   syntax allowing for retrieving not only matcher groups but URL
   parameters.

With the new syntax, the example becomes:

   <page path-info="/mariner/([^/]*)/([^/]*)/(.*)"
         matcher="oxf:perl5-matcher"
         default-submission="oxf:/mariner/default.xml"
         model="oxf:/mariner/default.xpl">
      <setvalue ref="/form/directory" matcher-group="1"/>
      <setvalue ref="/form/tertiary" matcher-group="2"/>
      <setvalue ref="/form/file" matcher-group="3"/>
   </page>

-Erik




--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Chary,

There are two main ways of modularizing the PFC:

o Using sub-page-flows, as done now for some OPS examples. This
   involves creating a page-flow.xpl calling the sub-page-flow.xml, and
   setting page-flow.xpl as a model in the main page flow.

o Using XInclude. There are currently two problems with this:

   o OPS uses Xerces for XInclude processing, and until 2.7.1 (released
     recently) XInclude support was limited to entirely embedding the
     included document. We will see if we manage to switch to 2.7.1/2
     for OPS 3.0 final.

   o The schema for the PFC does not like the xml:base attributes added
     by XInclude (should really fix this now).

Check the following email for reference:

http://mail-archive.objectweb.org/ops-users/2005-03/msg00229.html

-Erik

[hidden email] wrote:

 > In an application with tens of pages to be displayed, if all these
 > are declared in a single page-flow.xml, I am afraid the page-flow
 > document will be unreadable and unmaintainable. Is there a way to
 > modularize the control flow specified in page-flow.xml? For
 > instance, is there a way to specify something along the lines of
 > "include" or "import" multiple page-flows in a page-flow.xml?

 > What is the recommended way to solve the problem of a potentially
 > large page-flow.xml file?
 >
 > Chary



--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws