Dan & all,
The extension of the epilogue.xpl works excellent and is a simple and easy change, but what if we only want to make changes in xforms-epilogue.xpl, epilogue-servlet.xpl or epilogue-portal.xpl. I thought about this, and one solution I could see is to have a custom- xpl for this (e.g. custom-xforms-epilogue.xpl) that the user could override as they needed. Obviously each would have different inputs and outputs, but by default they would pass the page through with and oxf:identity and be in the one of the jars. If the user decides to override it, they don't have to worry about merging with future OF releases and the XPL will allow the user to do anything. Whats everyone elses thoughts on this? Ryan Ryan Puddephatt "Measuring programming progress by lines of code is like
measuring aircraft building progress by weight." - Bill Gates Daniel E. Renfer wrote: On 5/25/07, Alessandro Vernet <[hidden email]> wrote: -- 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,
that sounds like a very good version for supporting
and making a custom epilogue very easy!
BTW some of you just wrote, that they use an own
epilogue and connect from there to the standart, right?
Would anyone be so kind to send my such a
custom-epilogue and tell me how to use it?
I'm afraid i'm someone who needs to look at some
code to understand it - most of the time i'm lost with blank theories
:-(
Regards, Marcus
-- 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 |
Administrator
|
In reply to this post by Daniel E. Renfer
On 6/3/07, Daniel E. Renfer <[hidden email]> wrote:
> I serve all of my pages as application/xhtml+xml to clients that support it > and haven't noticed any major problems yet. (granted, I don't use any of the > esoteric controls) This is good to know. > As far as some of the configurable aspects of the epilogue I'd like to see, > I would love to see the "assume some xhtml clients" path be available as a > properties option. And this would serve XHTML to clients that support it, and plain old HTML to other clients? > I would also like to see a way to drop in support for new types without > modifying the epilogue based on XPath tests. For instance, I had to add some > code so Orbeon Forms would serve OpenSearch description documents with the > proper media type. If there was a way I could store just that section of > pipeline to a certain location or store all of the new types I need to add > to a certain file then I could add in support without needing to merge > changes when I update. OK, I understand. We'll try to keep this in mind. 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 |
Administrator
|
In reply to this post by Ryan Puddephatt
Ryan,
On 6/3/07, Ryan Puddephatt <[hidden email]> wrote: > The extension of the epilogue.xpl works excellent and is a simple and > easy change, but what if we only want to make changes in > xforms-epilogue.xpl, epilogue-servlet.xpl or epilogue-portal.xpl. I thought > about this, and one solution I could see is to have a custom- xpl for this > (e.g. custom-xforms-epilogue.xpl) that the user could override as they > needed. Obviously each would have different inputs and outputs, but by > default they would pass the page through with and oxf:identity and be in the > one of the jars. If the user decides to override it, they don't have to > worry about merging with future OF releases and the XPL will allow the user > to do anything. called by the current epilogue before the data is fed to the XForms server? 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 |
I guess there could be two (looking at xforms-epilogue.xpl again). 1 for NG and 1 for 2.8 they would be the first processor in the the p:when/p:otherwise. In the NG custom it would have a data and instance input, the 2.8 would have an extra xforms-model input, both would have a data output, which would continue as normal in the XPL. How does that sound? Ryan Ryan Puddephatt "Measuring programming progress by lines of code is like
measuring aircraft building progress by weight." - Bill Gates Alessandro Vernet wrote: Ryan, -- 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 |
Administrator
|
Ryan,
On 6/4/07, Ryan Puddephatt <[hidden email]> wrote: > I guess there could be two (looking at xforms-epilogue.xpl again). 1 > for NG and 1 for 2.8 they would be the first processor in the the > p:when/p:otherwise. In the NG custom it would have a data and instance > input, the 2.8 would have an extra xforms-model input, both would have a > data output, which would continue as normal in the XPL. > > How does that sound? I like the idea. And we could do that same for the theme, i.e. running an XPL that just runs the XSLT with theme-something.xsl instead of using a property. This would cover Eric's user case, where he would like to run a different theme stylesheet depending on the path. We'll think a little more about this an post a follow-up here. 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 |
In reply to this post by Marcus-2
Marcus,
Here's my custom epilogue. As you can see, there's not much to it. I simply run a XSLT transform and then pass that off to the standard epilogue. -- Daniel E. Renfer http://kronkltd.net/ On 6/4/07, Marcus <[hidden email]> wrote:
-- 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 epilogue.xpl (2K) Download Attachment |
Free forum by Nabble | Edit this page |