Support for other themes in epilogue

Hi,


In the epilogue pipeline (epilogue-servlet.xpl), the theme is applied in
a xpl:choose statement which is currently:


            <p:choose href="#request">
                <p:when test="starts-with(/request/request-path, '/doc/') or /request/parameters/parameter[name = 'orbeon-theme']/value = 'plain'">
                    <p:processor name="oxf:unsafe-xslt">
                        <p:input name="data" href="#xformed-data"/>
                        <p:input name="request" href="#request"/>
                        <p:input name="config" href="theme-plain.xsl"/>
                        <p:output name="data" id="themed-data"/>
                    </p:processor>
                </p:when>
                <p:otherwise>
                    <p:processor name="oxf:unsafe-xslt">
                        <p:input name="data" href="#xformed-data"/>
                        <p:input name="request" href="#request"/>
                        <p:input name="config" href="theme-portal.xsl"/>
                        <p:output name="data" id="themed-data"/>
                    </p:processor>
                </p:otherwise>
            </p:choose>

This means that if for a new application I want to add my own theme, I
need to either modify the epilogue pipes under resources/config or copy
it elsewhere to create my own epilogue.

In both cases, this makes my application vulnerable to other changes in
the epilogue. Experience tells me that this is a pipe which is prone to
change when Orbeon Forms is updated because the epilogue mixes both
system related stuff which is needed to make Orbeon Forms work and
application related stuff such as themes.

Couldn't we find a way to pass the location of the transformation that
needs to be applied to the epilogue so that other application can easily
reuse it to apply their own themes?

Thanks,

Eric
--
GPG-PGP: 2A528005
Lisez-moi sur XMLfr.
                       http://xmlfr.org/index/person/eric+van+der+vlist/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


--
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 Eric,

On 5/21/07, Eric van der Vlist <[hidden email]> wrote:
> In both cases, this makes my application vulnerable to other changes in
> the epilogue. Experience tells me that this is a pipe which is prone to
> change when Orbeon Forms is updated because the epilogue mixes both
> system related stuff which is needed to make Orbeon Forms work and
> application related stuff such as themes.

Yes, indeed.

> Couldn't we find a way to pass the location of the transformation that
> needs to be applied to the epilogue so that other application can easily
> reuse it to apply their own themes?

I think this is one of the last things that a significant portion of
the people creating an application on Orbeon Forms will want to
modify. We could specify the location the stylesheet in
properties.xml. Do you have an other suggestion? Do you see anything
else that you would like to be moved out of the epilogue and put in
configuration files?

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi,
don't know if you had noticed to discussion i had some day ago about the
epilogue and the questions that are still open, but if it is ok to make
further suggestions about the epilogue, it would be a great thing to be able
to have the possibility of adding a theme with working xform-controls!

At the moment i had added this xform-menu to the theme-widgets.xsl, but i
think i would be great to be able to add and own additional theme through
the configuration without having to touch the theme-widgets or to manipulate
the xforms-epilogue. Would such a solution also be possible? Or is this a
question belonging to another thread?

And reffering to another thread with the context of the epilogue. Is it
possible to manually transform and selfcreated page with xform-controls to
an working html-page? Perhaps this would be a another "nice to have"
processor, where one can input an created page including xforms to get a
working xhtml-page - just like the epilogue does, but that one can include
to his own XPL. Or is this just possible yet? Cause i tried but could not
make it work... but ok, i think is a question for another thread i
suppose... so sorry for bovering this one...

But supporting of an working "xform-theme" would be great!
Regards,

Marcus


----- Original Message -----
From: "Alessandro Vernet" <[hidden email]>
To: <[hidden email]>
Sent: Monday, May 21, 2007 3:41 PM
Subject: Re: [ops-users] Support for other themes in epilogue


--------------------------------------------------------------------------------


>
> --
> 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
>




--
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

Marcus,
    Such a solution is possible, take the xforms-epilogue.xpl out of the jar and modify it to do this.

Ryan


Marcus wrote:

Hi,
don't know if you had noticed to discussion i had some day ago about the epilogue and the questions that are still open, but if it is ok to make further suggestions about the epilogue, it would be a great thing to be able to have the possibility of adding a theme with working xform-controls!

At the moment i had added this xform-menu to the theme-widgets.xsl, but i think i would be great to be able to add and own additional theme through the configuration without having to touch the theme-widgets or to manipulate the xforms-epilogue. Would such a solution also be possible? Or is this a question belonging to another thread?

And reffering to another thread with the context of the epilogue. Is it possible to manually transform and selfcreated page with xform-controls to an working html-page? Perhaps this would be a another "nice to have" processor, where one can input an created page including xforms to get a working xhtml-page - just like the epilogue does, but that one can include to his own XPL. Or is this just possible yet? Cause i tried but could not make it work... but ok, i think is a question for another thread i suppose... so sorry for bovering this one...

But supporting of an working "xform-theme" would be great!
Regards,

Marcus


----- Original Message ----- From: "Alessandro Vernet" [hidden email]
To: [hidden email]
Sent: Monday, May 21, 2007 3:41 PM
Subject: Re: [ops-users] Support for other themes in epilogue

Hi Eric,

On 5/21/07, Eric van der Vlist [hidden email] wrote:

In both cases, this makes my application vulnerable to other changes in
the epilogue. Experience tells me that this is a pipe which is prone to
change when Orbeon Forms is updated because the epilogue mixes both
system related stuff which is needed to make Orbeon Forms work and
application related stuff such as themes.

Yes, indeed.

Couldn't we find a way to pass the location of the transformation that
needs to be applied to the epilogue so that other application can easily
reuse it to apply their own themes?

I think this is one of the last things that a significant portion of
the people creating an application on Orbeon Forms will want to
modify. We could specify the location the stylesheet in
properties.xml. Do you have an other suggestion? Do you see anything
else that you would like to be moved out of the epilogue and put in
configuration files?

Alex
-- 
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/

--------------------------------------------------------------------------------

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

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Marcus,

Le lundi 21 mai 2007 à 16:06 +0200, Marcus a écrit : These issues definitely seem to be connected since I am basically asking
for a level of "customization" in the epilogue...

> And reffering to another thread with the context of the epilogue. Is it
> possible to manually transform and selfcreated page with xform-controls to
> an working html-page? Perhaps this would be a another "nice to have"
> processor, where one can input an created page including xforms to get a
> working xhtml-page - just like the epilogue does, but that one can include
> to his own XPL. Or is this just possible yet? Cause i tried but could not
> make it work... but ok, i think is a question for another thread i
> suppose... so sorry for bovering this one...

Yes, this one is rather a request to define an extension point rather
than a discussion on how to make a different epilogue.xpl work :) ..;

Cheers,

Eric

> But supporting of an working "xform-theme" would be great!
> Regards,
>
> Marcus
>

--
GPG-PGP: 2A528005
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


--
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

Ryan,

Le lundi 21 mai 2007 à 19:29 +0100, Ryan Puddephatt a écrit :
> Marcus,
>     Such a solution is possible, take the xforms-epilogue.xpl out of
> the jar and modify it to do this.

Yep, but my point was rather to ask which mechanism could be implemented
to add an extension point that would survive an upgrade to the next
release...

Deriving a custom epilogue.xpl or updating the standard one isn't that
difficult, but experience tells me that the epilogue contains a lot of
Orbeon Forms' internal treatments that is updated between different
releases and that this can be a serious pain when you need to
consolidate your changes with the standard one release after release.

Eric
--
GPG-PGP: 2A528005
Weblog:
                 http://eric.van-der-vlist.com/blog?t=category&a=English
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


--
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

Eric,
    We have implemented an "xforms-theme" into the xforms-epilogue.xpl easily, without having to do a merge for some time now, but I agree it would be nice to keep that file in the jar so its is always kept up-to-date. My opinion would be to add an XSLT processor before the widgets that makes a call to xforms-theme.xsl under /config and "out-of-the-box" it would contain <xsl:import href="oxf:/oxf/xslt/utils/copy.xsl"/> to just copy the existing page. Then allowing full customization by a user

As I say we successfully implemented this without any trouble, and have been using it for 6 months so its certainly possible without much change.

Ryan


Eric van der Vlist wrote:

Hi Marcus,

Le lundi 21 mai 2007 à 16:06 +0200, Marcus a écrit :
  

Hi,
don't know if you had noticed to discussion i had some day ago about the 
epilogue and the questions that are still open, but if it is ok to make 
further suggestions about the epilogue, it would be a great thing to be able 
to have the possibility of adding a theme with working xform-controls!

At the moment i had added this xform-menu to the theme-widgets.xsl, but i 
think i would be great to be able to add and own additional theme through 
the configuration without having to touch the theme-widgets or to manipulate 
the xforms-epilogue. Would such a solution also be possible? Or is this a 
question belonging to another thread?
    

These issues definitely seem to be connected since I am basically asking
for a level of "customization" in the epilogue...

  

And reffering to another thread with the context of the epilogue. Is it 
possible to manually transform and selfcreated page with xform-controls to 
an working html-page? Perhaps this would be a another "nice to have" 
processor, where one can input an created page including xforms to get a 
working xhtml-page - just like the epilogue does, but that one can include 
to his own XPL. Or is this just possible yet? Cause i tried but could not 
make it work... but ok, i think is a question for another thread i 
suppose... so sorry for bovering this one...
    

Yes, this one is rather a request to define an extension point rather
than a discussion on how to make a different epilogue.xpl work :) ..;

Cheers,

Eric

  

But supporting of an working "xform-theme" would be great!
Regards,

Marcus

    

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

I think so far we have the following proposals on the table:

1) Have the theme stylesheet defined in properties.xml. Then
epilogue-servlet.xpl uses that stylesheet instead of calling
theme-portal.xsl by default. So to change the theme, one does not need
to change the epilogue.

2) As an alternative to #1, Ryan suggested to always call
/config/xforms-theme.xsl from the epilogue. In the example
xforms-theme.xsl == theme-portal.xsl, and one can modify this file as
needed.

On #1 vs. #2, #1 is on the side of "configuration rules" and #2
"convention rules". In this case, I would side with #1 because this is
a case where one is likely to change the default, and doing so will be
easier if done in properties.xml (replace theme-portal.xsl with
theme-plain.xsl in that file). Am I missing part of the story?

3) There is the issue of configuring theme-widget.xsl to add other
"widgets". This was raised by Marcus. In the long run we want to move
away from theme-widget.xsl and use XBL instead. Waiting for this to be
implemented, I don't expect to see significant changes to
theme-widget.xsl, so my preference is to leave it as-is in the
meantime.

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Alex,
#1 sound good and i'm sure it would be ok for use without of any
xforms-controls
#3 so in the mean time just add "menus" or anything which needs
xform-controls, just like the language-option i.e. to the theme-widgets -
right? That will be ok for me too, don't know what others think about! But
being able to use xform-controls in a menu makes many things easier i think
:-)

I think the mail aspect is, that updating ones webapp with a new release of
OPS should be as easy as possible without having to extract config-files out
of the jar and add his own changes "every" time :-) Even if "every" means
perhaps 2 times a year or so. Being able to include own themes - perhaps one
for normal and one which may include xform-controls just by adding those to
the normal properties.xml would be great, so that the epilog will add them
automatically when they are mentioned and otherwise leave them untouched.
Would that be a possible solution which won't take long to integrate, but
would make live easier in the mean time?

And may i ask what XBL is? Never heard of it until now :-)


----- Original Message -----
From: "Alessandro Vernet" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, May 22, 2007 2:50 PM
Subject: Re: [ops-users] Support for other themes in epilogue


--------------------------------------------------------------------------------


>
> --
> 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
>




--
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

Le mardi 22 mai 2007 à 14:50 +0200, Alessandro Vernet a écrit : I don't know how other people are using Orbeon Forms, but what I usually
do is:

      * install the war file
      * add new applications in a resources sub directory
      * proxy a these applications to the outside world

This lets me access the nice samples and documentation internally by
connecting directly to tomcat or jetty and provide isolated accesses to
my applications through the proxy.

Do you have better alternatives to deploy a set of different Orbeon
Forms distinct applications?

The problem with this solution is that you can't use single common theme
but need to keep the default one to access the samples and documentation
and use a different one for each application.

In fact, the solution that would work best for me is to kind of
generalize the choose that exists in the epilogue:

            <p:choose href="#request">
                <p:when test="starts-with(/request/request-path, '/doc/') or /request/parameters/parameter[name = 'orbeon-theme']/value = 'plain'">
                    <p:processor name="oxf:unsafe-xslt">
                        <p:input name="data" href="#xformed-data"/>
                        <p:input name="request" href="#request"/>
                        <p:input name="config" href="theme-plain.xsl"/>
                        <p:output name="data" id="themed-data"/>
                    </p:processor>
                </p:when>
                <p:otherwise>
                    <p:processor name="oxf:unsafe-xslt">
                        <p:input name="data" href="#xformed-data"/>
                        <p:input name="request" href="#request"/>
                        <p:input name="config" href="theme-portal.xsl"/>
                        <p:output name="data" id="themed-data"/>
                    </p:processor>
                </p:otherwise>
            </p:choose>


to apply a theme that depends on the request-path.

Now, there is also the problem that these theme transformations come too
late in the pipeline to use XForms control. If I want to define common
XForms controls to add a search or a login entry on each of my pages, I
need to do so before that stage...

Is there something in these transformations that requires that they are
performed that late or could they be applied before the XForms
transformation?


> 3) There is the issue of configuring theme-widget.xsl to add other
> "widgets". This was raised by Marcus. In the long run we want to move
> away from theme-widget.xsl and use XBL instead. Waiting for this to be
> implemented, I don't expect to see significant changes to
> theme-widget.xsl, so my preference is to leave it as-is in the
> meantime.

Makes sense!

Thanks,

Eric


> Alex
> pièce jointe document plein texte (message-footer.txt)
> --
> 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
--
GPG-PGP: 2A528005
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


--
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

Marcus,

On 5/22/07, Marcus <[hidden email]> wrote:
> Being able to include own themes - perhaps one
> for normal and one which may include xform-controls just by adding those to
> the normal properties.xml would be great, so that the epilog will add them
> automatically when they are mentioned and otherwise leave them untouched.
> Would that be a possible solution which won't take long to integrate, but
> would make live easier in the mean time?

I don't quite understand that one. What would the multiple theme be
used for? Is this similar to what Eric is suggesting (i.e. theme
chosen based on the path e.g. one theme for your application and one
theme for the examples)?

> And may i ask what XBL is? Never heard of it until now :-)

For a short answer:
http://en.wikipedia.org/wiki/XBL

For a longer one:
http://www.w3.org/TR/xbl/

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric,

On 5/22/07, Eric van der Vlist <[hidden email]> wrote: Would it work if the theme you setup in properties.xml could be not
only an XSLT stylesheet but also an XPL. Then in your XPL you could
implement the logic you are describing?

> Is there something in these transformations that requires that they are
> performed that late or could they be applied before the XForms
> transformation?

Nothing *has* to be done after the XForms transformation. In fact
theme-plain.xsl doesn't do much there. But this is your opportunity to
change what is generated by default by the XForms engine if you want
to.

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Alex,
i'm sorry for my english and the difficulties to understand what i am trying
to explain :-)
OK, i.e. imagine the following szenario:

I don't know if it possible at the moment to tell the webapp with the
properties just to use the theme-plain every time. Does this work, so the
first point would be clearer now.
In my case i need xform-controls on my menu, wich i wanted to include to
every page and of course with that i am able to change the menu behaviours
based on the subpages i'm browsing at the moment! But to achiev that i have
to change the theme-widgets, or manualy include an own theme with changing
the xforms-epilogue. In both cases i have to touch the standard files which
are shipped with the release and i think it would be good to be able to tell
the properties i.e. the name of the own theme and than it will be included
without having to touch anything of the base files. Does that make sence to
you?

For new users it would much more easier just to add the path of the theme to
properties when updating the OPS files, rather than someone has to do the
changes to all the bsaic files, perhaps extracting some out of the jar
files. You know what i mean? Not every person that has to work with an
webapp based on OPS may be able to understand what he has to do in detail,
but setting a path in some config-file should be possible for nearly
everyone.

Hope that makes my point much more clearer to you,
best regards, Marcus


----- Original Message -----
From: "Alessandro Vernet" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, May 22, 2007 11:15 PM
Subject: Re: [ops-users] Support for other themes in epilogue


--------------------------------------------------------------------------------


>
> --
> 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
>




--
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

Marcus,

On 5/22/07, Marcus <[hidden email]> wrote: Yes, this makes sense. And I think we are going towards what follows,
which would work well in the scenario you describe:

1) Leave xforms-wdigets.xsl as-is for now. Future plan is to do this
with UBL. xforms-wdigets.xsl runs before the XForms engine, and is our
opportunity to generate XForms.
2) Have the theme configured in properties.xml (set to
theme-portal.xsl by default, can be changed to theme-plain.xsl, or
something else). Have the possibility of pointing to an XPL file to
implement a scenario where the stylesheet is chosen based on the path
(Eric's use case).

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Le mercredi 23 mai 2007 à 11:29 +0200, Alessandro Vernet a écrit : Well... I am working on a refactoring of my apiculteurs.info web site
and after making some progress, I am not that sure any longer because it
seems that I would need more customization in the epilogue:

      * From what I see of my needs right now, I'd better apply a theme
        before the XForms processing. The good news is that this is easy
        to do by calling the standard epilogue.xpl in a custom,
        application specific, epilogue pipeline.
      * Since I am doing so, I need to avoid applying any theme further
        on in the epilogue and that could be done by the solution you
        are proposing.
      * OTH, I'd also like to activate the xpl:choose that serves XHTML
        to client that support it (assuming that YUI does now support
        XHTML which is something I need to double check) and that makes
        another change I need to make to the standard epilogue. I have
        noticed that doing so breaks the pages of the Orbeon Forms
        documentation which raise well formed errors when they reach the
        browser and this change needs also to be context dependent.  

All in one, customizing the epilogue appears to be more fuzzy than I
first thought!

Eric


--
GPG-PGP: 2A528005
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


--
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 Eric,

On 5/24/07, Eric van der Vlist <[hidden email]> wrote:
>       * From what I see of my needs right now, I'd better apply a theme
>         before the XForms processing. The good news is that this is easy
>         to do by calling the standard epilogue.xpl in a custom,
>         application specific, epilogue pipeline.

That's right: in your page-flow.xml, instead of calling directly
/config/epilogue.xpl, you can call your own XPL which then calls
/config/epilogue.xpl. For those who want to the do some processing
before XForms is transformed to XHTML (Marcus, are you reading this?),
this seems to be a better solution than modifying xforms-widget.xsl.

>       * Since I am doing so, I need to avoid applying any theme further
>         on in the epilogue and that could be done by the solution you
>         are proposing.

Right.

>       * OTH, I'd also like to activate the xpl:choose that serves XHTML
>         to client that support it (assuming that YUI does now support
>         XHTML which is something I need to double check) and that makes
>         another change I need to make to the standard epilogue. I have
>         noticed that doing so breaks the pages of the Orbeon Forms
>         documentation which raise well formed errors when they reach the
>         browser and this change needs also to be context dependent.

I haven't tested this, but from what I have seen in the YUI mailing
list, XHTML is not fully supported yet by YUI. Now it would be
interesting to see what doesn't work: maybe nothing does, or maybe
only some of the more esoteric functionalities aren't working.

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Alex, hi Eric,
of course i'm reading this :-) This was my thread and i'm always happy to
learn something new and get new ideas. I'm afraid i'm a person that learns
most by looking at examples and then try to change details and see how they
react. I was never quite good in just reading and than know exactly what i'm
doing :-)

I'm just reading quite all the mails from the mailing list and hope to learn
more and more, while developing with OF makes more and more fun, after
understanding the details. So I'm thankful that you guys are supporting this
mailing list and do great work out there :-)

Have a nice evening :-)


----- Original Message -----
From: "Alessandro Vernet" <[hidden email]>
To: <[hidden email]>
Sent: Friday, May 25, 2007 11:12 AM
Subject: Re: [ops-users] Support for other themes in epilogue


--------------------------------------------------------------------------------


>
> --
> 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
>




--
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

On 5/26/07, Marcus <[hidden email]> wrote:
> of course i'm reading this :-)

Good, I was just checking ;).

> I'm just reading quite all the mails from the mailing list and hope to learn
> more and more, while developing with OF makes more and more fun, after
> understanding the details. So I'm thankful that you guys are supporting this
> mailing list and do great work out there :-)

Thank you!

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 5/23/07, Alessandro Vernet <[hidden email]> wrote:
> 2) Have the theme configured in properties.xml (set to
> theme-portal.xsl by default, can be changed to theme-plain.xsl, or
> something else). Have the possibility of pointing to an XPL file to
> implement a scenario where the stylesheet is chosen based on the path
> (Eric's use case).

I added an RFE so we don't loose track of this.

http://forge.objectweb.org/tracker/index.php?func=detail&aid=307139&group_id=168&atid=350207

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 5/25/07, Alessandro Vernet <[hidden email]> wrote:--
Daniel E. Renfer
http://kronkltd.net/

--
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