OPS 3.0 Beta 2
using classic (non-ajax) xforms engine Not sure if others have run into the same problem, but from time to time I "implement" a bug within my view.xsl page which throws an error like the one I show below. Such error message does not provide much help, except just telling me that an error occurred somewhere during epilogue processing. From experience I found out that these kinds of errors are most often caused by a xforms construct in my view.xsl page. To troubleshoot such events I proceed by progressively cutting out big chunks of the view.xml code and running the action causing the error until I locate the culprit. Ideally OPS would provide a more accurate info about the problem, but in the meantime - is there some "best practices" that I could make development more efficient? Orbeon PresentationServer (OPS) - Error Page Error Message The following error has occurred: Error Message OPS Call Stack The OPS Call Stack helps you determine what sequence of OPS operations have caused the error. Resource URL Line Column Description XML Element oxf:/config/epilogue.xpl 15 40 reading processor output (name='data') <p:param type="input" name="data"/> oxf:/ops/pfc/xforms-epilogue.xpl 20 40 reading processor output (name='data') <p:param type="input" name="data"/> oxf:/ops/pfc/xforms-epilogue.xpl 42 60 reading processor output (name='data', id='annotated-data') <p:output name="data" id="annotated-data"/> oxf:/ops/pfc/xforms-epilogue.xpl 50 56 reading processor output (name='data', id='xhtml-data') <p:output name="data" id="xhtml-data"/> oxf:/ops/pfc/xforms-epilogue.xpl 58 67 reading processor output (name='data', ref='xformed-data') <p:output name="data" ref="xformed-data"/> oxf:/config/epilogue.xpl 28 58 reading processor output (name='xformed-data', id='xformed-data') <p:output name="xformed-data" id="xformed-data"/> oxf:/config/epilogue-servlet.xpl 29 48 reading processor output (name='xformed-data') <p:param type="input" name="xformed-data"/> oxf:/config/epilogue.xpl 46 46 executing processor (name='{http://www.orbeon.com/oxf/processors}pipeline') <p:processor name="oxf:pipeline">...</p:processor> oxf:/iEDI/page-flow.xml 69 47 executing processor (name='{http://www.orbeon.com/oxf/processors}pipeline') oxf:/iEDI/page-flow.xpl 18 39 executing processor (name='{http://www.orbeon.com/oxf/processors}page-flow') <p:processor name="oxf:page-flow">...</p:processor> oxf:/page-flow.xml 22 69 reading page model data output (page id='home', model='oxf:/iEDI/page-flow.xpl') <page id="home" path-info="/*" model="oxf:/iEDI/page-flow.xpl"/> -- 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
|
Alexander,
Below the OPS Call Stack, you have the Java Call Stack. What is the exception you are getting? If what I mean is not clear, could you take a screenshot of the page you are getting? Alex On 11/23/05, Alexander Zatko <[hidden email]> wrote: > OPS 3.0 Beta 2 > using classic (non-ajax) xforms engine > > Not sure if others have run into the same problem, but from time to > time I "implement" a bug within my view.xsl page which throws an error > like the one I show below. Such error message does not provide much > help, except just telling me that an error occurred somewhere during > epilogue processing. From experience I found out that these kinds of > errors are most often caused by a xforms construct in my view.xsl page. > To troubleshoot such events I proceed by progressively cutting out big > chunks of the view.xml code and running the action causing the error > until I locate the culprit. > > Ideally OPS would provide a more accurate info about the problem, but > in the meantime - is there some "best practices" that I could make > development more efficient? > > Orbeon PresentationServer (OPS) - Error Page > Error Message > > The following error has occurred: > Error Message > > OPS Call Stack > > The OPS Call Stack helps you determine what sequence of OPS operations > have caused the error. > Resource URL Line Column Description XML Element > oxf:/config/epilogue.xpl 15 40 reading processor output > (name='data') <p:param type="input" name="data"/> > oxf:/ops/pfc/xforms-epilogue.xpl 20 40 reading processor output > (name='data') <p:param type="input" name="data"/> > oxf:/ops/pfc/xforms-epilogue.xpl 42 60 reading processor output > (name='data', id='annotated-data') <p:output name="data" > id="annotated-data"/> > oxf:/ops/pfc/xforms-epilogue.xpl 50 56 reading processor output > (name='data', id='xhtml-data') <p:output name="data" > id="xhtml-data"/> > oxf:/ops/pfc/xforms-epilogue.xpl 58 67 reading processor output > (name='data', ref='xformed-data') <p:output name="data" > ref="xformed-data"/> > oxf:/config/epilogue.xpl 28 58 reading processor output > (name='xformed-data', id='xformed-data') <p:output > name="xformed-data" id="xformed-data"/> > oxf:/config/epilogue-servlet.xpl 29 48 reading processor output > (name='xformed-data') <p:param type="input" name="xformed-data"/> > oxf:/config/epilogue.xpl 46 46 executing processor > (name='{http://www.orbeon.com/oxf/processors}pipeline') <p:processor > name="oxf:pipeline">...</p:processor> > oxf:/iEDI/page-flow.xml 69 47 executing processor > (name='{http://www.orbeon.com/oxf/processors}pipeline') > oxf:/iEDI/page-flow.xpl 18 39 executing processor > (name='{http://www.orbeon.com/oxf/processors}page-flow') > <p:processor name="oxf:page-flow">...</p:processor> > oxf:/page-flow.xml 22 69 reading page model data output (page > id='home', model='oxf:/iEDI/page-flow.xpl') <page id="home" > path-info="/*" model="oxf:/iEDI/page-flow.xpl"/> > > > > > > -- > 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 > > > -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ -- 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
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Alex,
After I sent the email I noticed the java stack trace section which confirmed my suspicion that I had problem in the XForms-related part of the view.xsl. I located the problem and fixed it - by the trial and error method I briefly describe below as the java report did not tell me much (not due to the lack of information in it :-)). The original intention of my post was not to ask for help solving a particular problem, but to point out that in some cases the error messages are quite cryptic to a person not understanding the inner workings of the OPS framework. I chose to learn OPS for the most part because it allows me to build web apps using pure XML techniques (declarative representation, functional programming) without having to know the details of how OPS does what it does. I know there are different people using OPS in different ways, but for users who chose OPS for similar reasons to mine, good error reporting can ease the leraning curve of this otherwise great product. I will try to send you a better report when I generate this kind of error again. Thank you A. On Nov 25, 2005, at 7:44 PM, Alessandro Vernet wrote: > Alexander, > > Below the OPS Call Stack, you have the Java Call Stack. What is the > exception you are getting? If what I mean is not clear, could you take > a screenshot of the page you are getting? > > Alex > > On 11/23/05, Alexander Zatko <[hidden email]> wrote: >> OPS 3.0 Beta 2 >> using classic (non-ajax) xforms engine >> >> Not sure if others have run into the same problem, but from time to >> time I "implement" a bug within my view.xsl page which throws an error >> like the one I show below. Such error message does not provide much >> help, except just telling me that an error occurred somewhere during >> epilogue processing. From experience I found out that these kinds of >> errors are most often caused by a xforms construct in my view.xsl >> page. >> To troubleshoot such events I proceed by progressively cutting out big >> chunks of the view.xml code and running the action causing the error >> until I locate the culprit. >> >> Ideally OPS would provide a more accurate info about the problem, but >> in the meantime - is there some "best practices" that I could make >> development more efficient? >> >> Orbeon PresentationServer (OPS) - Error Page >> Error Message >> >> The following error has occurred: >> Error Message >> >> OPS Call Stack >> >> The OPS Call Stack helps you determine what sequence of OPS operations >> have caused the error. >> Resource URL Line Column Description XML Element >> oxf:/config/epilogue.xpl 15 40 reading processor >> output >> (name='data') <p:param type="input" name="data"/> >> oxf:/ops/pfc/xforms-epilogue.xpl 20 40 reading >> processor output >> (name='data') <p:param type="input" name="data"/> >> oxf:/ops/pfc/xforms-epilogue.xpl 42 60 reading >> processor output >> (name='data', id='annotated-data') <p:output name="data" >> id="annotated-data"/> >> oxf:/ops/pfc/xforms-epilogue.xpl 50 56 reading >> processor output >> (name='data', id='xhtml-data') <p:output name="data" >> id="xhtml-data"/> >> oxf:/ops/pfc/xforms-epilogue.xpl 58 67 reading >> processor output >> (name='data', ref='xformed-data') <p:output name="data" >> ref="xformed-data"/> >> oxf:/config/epilogue.xpl 28 58 reading processor >> output >> (name='xformed-data', id='xformed-data') <p:output >> name="xformed-data" id="xformed-data"/> >> oxf:/config/epilogue-servlet.xpl 29 48 reading >> processor output >> (name='xformed-data') <p:param type="input" name="xformed-data"/> >> oxf:/config/epilogue.xpl 46 46 executing processor >> (name='{http://www.orbeon.com/oxf/processors}pipeline') >> <p:processor >> name="oxf:pipeline">...</p:processor> >> oxf:/iEDI/page-flow.xml 69 47 executing processor >> (name='{http://www.orbeon.com/oxf/processors}pipeline') >> oxf:/iEDI/page-flow.xpl 18 39 executing processor >> (name='{http://www.orbeon.com/oxf/processors}page-flow') >> <p:processor name="oxf:page-flow">...</p:processor> >> oxf:/page-flow.xml 22 69 reading page model data >> output (page >> id='home', model='oxf:/iEDI/page-flow.xpl') <page id="home" >> path-info="/*" model="oxf:/iEDI/page-flow.xpl"/> >> >> >> >> >> >> -- >> 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 >> >> >> > > -- > Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ > > > -- > 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 |
Administrator
|
Alexander,
I understand your point, and in fact this is a problem we are aware off. This often happens when the view is generated with a stylesheet, instead of just having a static XML file. The effect is that line and column information in the original XSLT is lost because of the way the XSLT engine works and when the data gets to the XForms engine, we don't have that line/column number information that would allow us to give an error message pointing more precisely to the source of the problem. One way to avoid this situation is to use a static file for the view whenever it is possible (instead of an XSLT file). With XForms NG, this is actually possible in most cases, especially since you can now use XInclude instead of XSLT to insert an instance into the view. For this reason, for performance, for the sake of simplicity, with PresentationServer 3.0 we recommend using static views. Alex On 11/25/05, Alexander Zatko <[hidden email]> wrote: > Alex, > > After I sent the email I noticed the java stack trace section which > confirmed my suspicion that I had problem in the XForms-related part of > the view.xsl. I located the problem and fixed it - by the trial and > error method I briefly describe below as the java report did not tell > me much (not due to the lack of information in it :-)). > > The original intention of my post was not to ask for help solving a > particular problem, but to point out that in some cases the error > messages are quite cryptic to a person not understanding the inner > workings of the OPS framework. I chose to learn OPS for the most part > because it allows me to build web apps using pure XML techniques > (declarative representation, functional programming) without having to > know the details of how OPS does what it does. I know there are > different people using OPS in different ways, but for users who chose > OPS for similar reasons to mine, good error reporting can ease the > leraning curve of this otherwise great product. > > I will try to send you a better report when I generate this kind of > error again. > > Thank you > > A. > > On Nov 25, 2005, at 7:44 PM, Alessandro Vernet wrote: > > > Alexander, > > > > Below the OPS Call Stack, you have the Java Call Stack. What is the > > exception you are getting? If what I mean is not clear, could you take > > a screenshot of the page you are getting? > > > > Alex > > > > On 11/23/05, Alexander Zatko <[hidden email]> wrote: > >> OPS 3.0 Beta 2 > >> using classic (non-ajax) xforms engine > >> > >> Not sure if others have run into the same problem, but from time to > >> time I "implement" a bug within my view.xsl page which throws an error > >> like the one I show below. Such error message does not provide much > >> help, except just telling me that an error occurred somewhere during > >> epilogue processing. From experience I found out that these kinds of > >> errors are most often caused by a xforms construct in my view.xsl > >> page. > >> To troubleshoot such events I proceed by progressively cutting out big > >> chunks of the view.xml code and running the action causing the error > >> until I locate the culprit. > >> > >> Ideally OPS would provide a more accurate info about the problem, but > >> in the meantime - is there some "best practices" that I could make > >> development more efficient? > >> > >> Orbeon PresentationServer (OPS) - Error Page > >> Error Message > >> > >> The following error has occurred: > >> Error Message > >> > >> OPS Call Stack > >> > >> The OPS Call Stack helps you determine what sequence of OPS operations > >> have caused the error. > >> Resource URL Line Column Description XML Element > >> oxf:/config/epilogue.xpl 15 40 reading processor > >> output > >> (name='data') <p:param type="input" name="data"/> > >> oxf:/ops/pfc/xforms-epilogue.xpl 20 40 reading > >> processor output > >> (name='data') <p:param type="input" name="data"/> > >> oxf:/ops/pfc/xforms-epilogue.xpl 42 60 reading > >> processor output > >> (name='data', id='annotated-data') <p:output name="data" > >> id="annotated-data"/> > >> oxf:/ops/pfc/xforms-epilogue.xpl 50 56 reading > >> processor output > >> (name='data', id='xhtml-data') <p:output name="data" > >> id="xhtml-data"/> > >> oxf:/ops/pfc/xforms-epilogue.xpl 58 67 reading > >> processor output > >> (name='data', ref='xformed-data') <p:output name="data" > >> ref="xformed-data"/> > >> oxf:/config/epilogue.xpl 28 58 reading processor > >> output > >> (name='xformed-data', id='xformed-data') <p:output > >> name="xformed-data" id="xformed-data"/> > >> oxf:/config/epilogue-servlet.xpl 29 48 reading > >> processor output > >> (name='xformed-data') <p:param type="input" name="xformed-data"/> > >> oxf:/config/epilogue.xpl 46 46 executing processor > >> (name='{http://www.orbeon.com/oxf/processors}pipeline') > >> <p:processor > >> name="oxf:pipeline">...</p:processor> > >> oxf:/iEDI/page-flow.xml 69 47 executing processor > >> (name='{http://www.orbeon.com/oxf/processors}pipeline') > >> oxf:/iEDI/page-flow.xpl 18 39 executing processor > >> (name='{http://www.orbeon.com/oxf/processors}page-flow') > >> <p:processor name="oxf:page-flow">...</p:processor> > >> oxf:/page-flow.xml 22 69 reading page model data > >> output (page > >> id='home', model='oxf:/iEDI/page-flow.xpl') <page id="home" > >> path-info="/*" model="oxf:/iEDI/page-flow.xpl"/> > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > >> > > > > -- > > Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ > > > > > > -- > > 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 > > > -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ -- 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
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Alex,
I think I will try to change the current architecture to make the view files static. This brings up an issue of design patterns suitable for OPS framework. The documentation should probably have a separate section that would discuss this subject. Also, currently the tutorial and many examples included with the OPS installation commonly use XSL in the view without mentioning (as I am aware) the negative impact this pattern has for debugging, if XForms are used at the same time. I do not want this to sound as a complaint - I understand that creating good documentation would take away time you can spend on building OPS, but while you are re-doing the documentation, maybe now is a good time to take a look at this issue. Thank you A. On Nov 26, 2005, at 1:16 AM, Alessandro Vernet wrote: > Alexander, > > I understand your point, and in fact this is a problem we are aware > off. This often happens when the view is generated with a stylesheet, > instead of just having a static XML file. The effect is that line and > column information in the original XSLT is lost because of the way the > XSLT engine works and when the data gets to the XForms engine, we > don't have that line/column number information that would allow us to > give an error message pointing more precisely to the source of the > problem. > > One way to avoid this situation is to use a static file for the view > whenever it is possible (instead of an XSLT file). With XForms NG, > this is actually possible in most cases, especially since you can now > use XInclude instead of XSLT to insert an instance into the view. For > this reason, for performance, for the sake of simplicity, with > PresentationServer 3.0 we recommend using static views. > > Alex > > On 11/25/05, Alexander Zatko <[hidden email]> wrote: >> Alex, >> >> After I sent the email I noticed the java stack trace section which >> confirmed my suspicion that I had problem in the XForms-related part >> of >> the view.xsl. I located the problem and fixed it - by the trial and >> error method I briefly describe below as the java report did not tell >> me much (not due to the lack of information in it :-)). >> >> The original intention of my post was not to ask for help solving a >> particular problem, but to point out that in some cases the error >> messages are quite cryptic to a person not understanding the inner >> workings of the OPS framework. I chose to learn OPS for the most part >> because it allows me to build web apps using pure XML techniques >> (declarative representation, functional programming) without having to >> know the details of how OPS does what it does. I know there are >> different people using OPS in different ways, but for users who chose >> OPS for similar reasons to mine, good error reporting can ease the >> leraning curve of this otherwise great product. >> >> I will try to send you a better report when I generate this kind of >> error again. >> >> Thank you >> >> A. >> >> On Nov 25, 2005, at 7:44 PM, Alessandro Vernet wrote: >> >>> Alexander, >>> >>> Below the OPS Call Stack, you have the Java Call Stack. What is the >>> exception you are getting? If what I mean is not clear, could you >>> take >>> a screenshot of the page you are getting? >>> >>> Alex >>> >>> On 11/23/05, Alexander Zatko <[hidden email]> wrote: >>>> OPS 3.0 Beta 2 >>>> using classic (non-ajax) xforms engine >>>> >>>> Not sure if others have run into the same problem, but from time to >>>> time I "implement" a bug within my view.xsl page which throws an >>>> error >>>> like the one I show below. Such error message does not provide much >>>> help, except just telling me that an error occurred somewhere during >>>> epilogue processing. From experience I found out that these kinds of >>>> errors are most often caused by a xforms construct in my view.xsl >>>> page. >>>> To troubleshoot such events I proceed by progressively cutting out >>>> big >>>> chunks of the view.xml code and running the action causing the error >>>> until I locate the culprit. >>>> >>>> Ideally OPS would provide a more accurate info about the problem, >>>> but >>>> in the meantime - is there some "best practices" that I could make >>>> development more efficient? >>>> >>>> Orbeon PresentationServer (OPS) - Error Page >>>> Error Message >>>> >>>> The following error has occurred: >>>> Error Message >>>> >>>> OPS Call Stack >>>> >>>> The OPS Call Stack helps you determine what sequence of OPS >>>> operations >>>> have caused the error. >>>> Resource URL Line Column Description XML Element >>>> oxf:/config/epilogue.xpl 15 40 reading processor >>>> output >>>> (name='data') <p:param type="input" name="data"/> >>>> oxf:/ops/pfc/xforms-epilogue.xpl 20 40 reading >>>> processor output >>>> (name='data') <p:param type="input" name="data"/> >>>> oxf:/ops/pfc/xforms-epilogue.xpl 42 60 reading >>>> processor output >>>> (name='data', id='annotated-data') <p:output name="data" >>>> id="annotated-data"/> >>>> oxf:/ops/pfc/xforms-epilogue.xpl 50 56 reading >>>> processor output >>>> (name='data', id='xhtml-data') <p:output name="data" >>>> id="xhtml-data"/> >>>> oxf:/ops/pfc/xforms-epilogue.xpl 58 67 reading >>>> processor output >>>> (name='data', ref='xformed-data') <p:output name="data" >>>> ref="xformed-data"/> >>>> oxf:/config/epilogue.xpl 28 58 reading processor >>>> output >>>> (name='xformed-data', id='xformed-data') <p:output >>>> name="xformed-data" id="xformed-data"/> >>>> oxf:/config/epilogue-servlet.xpl 29 48 reading >>>> processor output >>>> (name='xformed-data') <p:param type="input" >>>> name="xformed-data"/> >>>> oxf:/config/epilogue.xpl 46 46 executing processor >>>> (name='{http://www.orbeon.com/oxf/processors}pipeline') >>>> <p:processor >>>> name="oxf:pipeline">...</p:processor> >>>> oxf:/iEDI/page-flow.xml 69 47 executing processor >>>> (name='{http://www.orbeon.com/oxf/processors}pipeline') >>>> oxf:/iEDI/page-flow.xpl 18 39 executing processor >>>> (name='{http://www.orbeon.com/oxf/processors}page-flow') >>>> <p:processor name="oxf:page-flow">...</p:processor> >>>> oxf:/page-flow.xml 22 69 reading page model data >>>> output (page >>>> id='home', model='oxf:/iEDI/page-flow.xpl') <page id="home" >>>> path-info="/*" model="oxf:/iEDI/page-flow.xpl"/> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>> >>> -- >>> Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ >>> >>> >>> -- >>> 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 >> >> >> > > -- > Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/ > > > -- > 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 |
Administrator
|
Alexander Zatko wrote:
> Also, currently the tutorial and many examples included with the OPS > installation commonly use XSL in the view without mentioning (as I > am aware) the negative impact this pattern has for debugging, if > XForms are used at the same time. I do not want this to sound as a > complaint - I understand that creating good documentation would take > away time you can spend on building OPS, but while you are re-doing > the documentation, maybe now is a good time to take a look at this > issue. The tutorial is clearly out of date, but many examples now use static XHTML views with XInclude. For now, I have added a note to mention the impact of using XSLT on debugging to the "XForms Instance Initialization" section of the doc in CVS. -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 |
Free forum by Nabble | Edit this page |