Hi,
While working on the XForms W3C test suite test harness for Orbeon, I hit the following: Orbeon doesn't requires you to prepend your app with 'apps/' in the request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if your app is in resources/apps/xforms-test-suite) when using the default distributed global page-flow.xml. This is a nice feature, but when static resources are served (by adding a files element, e.g.: <files path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to use orbeon/apps/xforms-test-suite/images/add.gif instead. This is quite annoying because the XForms 1.1 test suite uses a lot of relative resources for instances, css, ... (I could rewrite them but this isn't nice). When I looked to the problem I found that I could easily hack a workaround by changing the following xpath in PageFlowControllerProcessor (see also attached patch): "string(/request/request-path)" into: "string(if (starts-with(/request/request-path, '/apps/')) then /request/request-path else concat('/apps/', /request/request-path))" It really feels like a hack but I was wondering if we couldn't add an extra optional 'rewrite-path' attribute on the files element, which will cause a rewrite of the path, in which you can use the groups of the matcher. So the entries in the global page-flow.xml will look like: <files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> Correct me if I'm wrong but this could easily be done by using the output of the regexp processor, used in the pipeline constructed in the PageFlowControllerProcessor for handling files. What is your opinion on this? -- Regards, Nick Van den Bleeken -- 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 files-patch.txt (1K) Download Attachment |
There was a typo in my previous e-mail, it should be:
<files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> (rewrite path should be /apps/${5} and not /apps/${1}) Sorry for the small error Regards, Nick Van den Bleeken On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> wrote: > Hi, > > While working on the XForms W3C test suite test harness for Orbeon, I > hit the following: > > Orbeon doesn't requires you to prepend your app with 'apps/' in the > request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if > your app is in resources/apps/xforms-test-suite) when using the > default distributed global page-flow.xml. This is a nice feature, but > when static resources are served (by adding a files element, e.g.: > <files path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" > matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to > use orbeon/apps/xforms-test-suite/images/add.gif instead. This is > quite annoying because the XForms 1.1 test suite uses a lot of > relative resources for instances, css, ... (I could rewrite them but > this isn't nice). > > When I looked to the problem I found that I could easily hack a > workaround by changing the following xpath in > PageFlowControllerProcessor (see also attached patch): > > "string(/request/request-path)" > > into: > > "string(if (starts-with(/request/request-path, '/apps/')) then > /request/request-path else concat('/apps/', /request/request-path))" > > It really feels like a hack but I was wondering if we couldn't add an > extra optional 'rewrite-path' attribute on the files element, which > will cause a rewrite of the path, in which you can use the groups of > the matcher. So the entries in the global page-flow.xml will look > like: > > <files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" > matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> > > Correct me if I'm wrong but this could easily be done by using the > output of the regexp processor, used in the pipeline constructed in > the PageFlowControllerProcessor for handling files. > > What is your opinion on this? > > -- > Regards, > > Nick Van den Bleeken > -- Regards, Nick Van den Bleeken -- 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 |
Hi Nick,
Oops, I wanted to answer this way earlier. Let's try to figure this out. I think you are right. Here is a scenario: RESOURCES/apps/xforms-test-suite/my-test.xhtml This is loaded in the browser as: http://localhost:8080/orbeon/xforms-test-suite/my-test.xhtml IIRC we did this in order to have a nicer URL without the "apps" prefix. Now if my-test.xhtml refers to foobar.gif, we have: http://localhost:8080/orbeon/xforms-test-suite/foobar.gif and we expect this to be under: RESOURCES/apps/xforms-test-suite/foobar.gif But right now, this will be fetched under: RESOURCES/xforms-test-suite/foobar.gif which will 404. The idea of taking an incoming resource and considering that it's an application resource is good I think. We need to exclude "platform paths" from this. E.g. some resources start with /ops or /config etc. and need to stay there. Do you want to give this a try? ;) -Erik On Tue, Jan 26, 2010 at 3:51 AM, Nick Van den Bleeken <[hidden email]> wrote: > There was a typo in my previous e-mail, it should be: > > <files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" > matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> > > (rewrite path should be /apps/${5} and not /apps/${1}) > > Sorry for the small error > > Regards, > > Nick Van den Bleeken > > On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> wrote: >> Hi, >> >> While working on the XForms W3C test suite test harness for Orbeon, I >> hit the following: >> >> Orbeon doesn't requires you to prepend your app with 'apps/' in the >> request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if >> your app is in resources/apps/xforms-test-suite) when using the >> default distributed global page-flow.xml. This is a nice feature, but >> when static resources are served (by adding a files element, e.g.: >> <files path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" >> matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to >> use orbeon/apps/xforms-test-suite/images/add.gif instead. This is >> quite annoying because the XForms 1.1 test suite uses a lot of >> relative resources for instances, css, ... (I could rewrite them but >> this isn't nice). >> >> When I looked to the problem I found that I could easily hack a >> workaround by changing the following xpath in >> PageFlowControllerProcessor (see also attached patch): >> >> "string(/request/request-path)" >> >> into: >> >> "string(if (starts-with(/request/request-path, '/apps/')) then >> /request/request-path else concat('/apps/', /request/request-path))" >> >> It really feels like a hack but I was wondering if we couldn't add an >> extra optional 'rewrite-path' attribute on the files element, which >> will cause a rewrite of the path, in which you can use the groups of >> the matcher. So the entries in the global page-flow.xml will look >> like: >> >> <files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> >> >> Correct me if I'm wrong but this could easily be done by using the >> output of the regexp processor, used in the pipeline constructed in >> the PageFlowControllerProcessor for handling files. >> >> What is your opinion on this? >> >> -- >> Regards, >> >> Nick Van den Bleeken >> > > > > -- > Regards, > > Nick Van den Bleeken > > > -- > 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 |
HI Erik,
Do you want this as a general fix if the path doesn't start with /apps/ add it or do you want the fix with allows you to configure this using <files path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> If you say what you want I can implement it. Regards, Nick Van den Bleeken [hidden email] On Fri, Feb 5, 2010 at 02:01, Erik Bruchez-3 [via Orbeon Forms (ops-users)] <[hidden email]> wrote: > Hi Nick, > > Oops, I wanted to answer this way earlier. > > Let's try to figure this out. > > I think you are right. Here is a scenario: > > RESOURCES/apps/xforms-test-suite/my-test.xhtml > > This is loaded in the browser as: > > http://localhost:8080/orbeon/xforms-test-suite/my-test.xhtml > > IIRC we did this in order to have a nicer URL without the "apps" prefix. > > Now if my-test.xhtml refers to foobar.gif, we have: > > http://localhost:8080/orbeon/xforms-test-suite/foobar.gif > > and we expect this to be under: > > RESOURCES/apps/xforms-test-suite/foobar.gif > > But right now, this will be fetched under: > > RESOURCES/xforms-test-suite/foobar.gif > > which will 404. > > The idea of taking an incoming resource and considering that it's an > application resource is good I think. We need to exclude "platform > paths" from this. E.g. some resources start with /ops or /config etc. > and need to stay there. > > Do you want to give this a try? ;) > > -Erik > > On Tue, Jan 26, 2010 at 3:51 AM, Nick Van den Bleeken <[hidden email]> > wrote: >> There was a typo in my previous e-mail, it should be: >> >> <files >> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >> >> (rewrite path should be /apps/${5} and not /apps/${1}) >> >> Sorry for the small error >> >> Regards, >> >> Nick Van den Bleeken >> >> On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> >> wrote: >>> Hi, >>> >>> While working on the XForms W3C test suite test harness for Orbeon, I >>> hit the following: >>> >>> Orbeon doesn't requires you to prepend your app with 'apps/' in the >>> request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if >>> your app is in resources/apps/xforms-test-suite) when using the >>> default distributed global page-flow.xml. This is a nice feature, but >>> when static resources are served (by adding a files element, e.g.: >>> <files >>> path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" >>> matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to >>> use orbeon/apps/xforms-test-suite/images/add.gif instead. This is >>> quite annoying because the XForms 1.1 test suite uses a lot of >>> relative resources for instances, css, ... (I could rewrite them but >>> this isn't nice). >>> >>> When I looked to the problem I found that I could easily hack a >>> workaround by changing the following xpath in >>> PageFlowControllerProcessor (see also attached patch): >>> >>> "string(/request/request-path)" >>> >>> into: >>> >>> "string(if (starts-with(/request/request-path, '/apps/')) then >>> /request/request-path else concat('/apps/', /request/request-path))" >>> >>> It really feels like a hack but I was wondering if we couldn't add an >>> extra optional 'rewrite-path' attribute on the files element, which >>> will cause a rewrite of the path, in which you can use the groups of >>> the matcher. So the entries in the global page-flow.xml will look >>> like: >>> >>> <files >>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> >>> >>> Correct me if I'm wrong but this could easily be done by using the >>> output of the regexp processor, used in the pipeline constructed in >>> the PageFlowControllerProcessor for handling files. >>> >>> What is your opinion on this? >>> >>> -- >>> Regards, >>> >>> Nick Van den Bleeken >>> >> >> >> >> -- >> Regards, >> >> Nick Van den Bleeken >> >> >> -- >> 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 > > > ________________________________ > View message @ > http://n4.nabble.com/Path-problem-with-serving-static-files-tp1290244p1469645.html > To start a new topic under ObjectWeb OPS - Users, email > [hidden email] > To unsubscribe from ObjectWeb OPS - Users, click here. > -- Regards, Nick Van den Bleeken |
Administrator
|
Nick,
(As a note, if you just want the test suite to work, it is possible to add a top-level page flow rule for /apps/xforms-test-suite/*.) In the big picture it is still better to have a more general fix! So one question is: does this need to be a feature exposed through the syntax of the PFC, or should it be hard-coded. Orbeon Forms has a notion of two different types of paths for resources: * platform paths: start w/ '/ops/', '/config/', '/xbl/orbeon/', '/xforms-server' (should add '/forms/orbeon'!) * application paths (everything else) This distinction is made so we can rewrite versioned resources with the proper version number: an Orbeon version number for Orbeon resources, and an application version number for applications. Our main concern here are application paths. One issue is that '/apps' is not the only possible non-platform prefix, because we also have the '/xbl' and '/forms' prefixes to handle. For both it is possible to have component-specific resources like JS, CSS, and image files. So we can't just check on '/apps' I think. The algorithm should probably be: "Any non-platform resource path that does not already start with either '/apps', '/xbl', or '/forms' shall be prefixed with '/apps'". Now is it possible to implement this algorithm with regexps and something like the rewrite-path attribute you suggested? If so, and if it's not too hard to implement, I guess we could expose that to the PFC syntax. If not or too hard, then we probably need to implement it natively in the PFC. Whichever way we do it, it might be a good idea to have the ability to turn this off, since some users do not put their apps under '/apps'. -Erik On Sun, Feb 7, 2010 at 8:28 AM, nvdbleek <[hidden email]> wrote: > HI Erik, > > Do you want this as a general fix if the path doesn't start with > /apps/ add it or do you want the fix with allows you to configure this > using > > <files > path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" > matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> > > If you say what you want I can implement it. > > Regards, > > Nick Van den Bleeken > [hidden email] > > On Fri, Feb 5, 2010 at 02:01, Erik Bruchez-3 [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> Hi Nick, >> >> Oops, I wanted to answer this way earlier. >> >> Let's try to figure this out. >> >> I think you are right. Here is a scenario: >> >> RESOURCES/apps/xforms-test-suite/my-test.xhtml >> >> This is loaded in the browser as: >> >> http://localhost:8080/orbeon/xforms-test-suite/my-test.xhtml >> >> IIRC we did this in order to have a nicer URL without the "apps" prefix. >> >> Now if my-test.xhtml refers to foobar.gif, we have: >> >> http://localhost:8080/orbeon/xforms-test-suite/foobar.gif >> >> and we expect this to be under: >> >> RESOURCES/apps/xforms-test-suite/foobar.gif >> >> But right now, this will be fetched under: >> >> RESOURCES/xforms-test-suite/foobar.gif >> >> which will 404. >> >> The idea of taking an incoming resource and considering that it's an >> application resource is good I think. We need to exclude "platform >> paths" from this. E.g. some resources start with /ops or /config etc. >> and need to stay there. >> >> Do you want to give this a try? ;) >> >> -Erik >> >> On Tue, Jan 26, 2010 at 3:51 AM, Nick Van den Bleeken <[hidden email]> >> wrote: >>> There was a typo in my previous e-mail, it should be: >>> >>> <files >>> >>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >>> >>> (rewrite path should be /apps/${5} and not /apps/${1}) >>> >>> Sorry for the small error >>> >>> Regards, >>> >>> Nick Van den Bleeken >>> >>> On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> >>> wrote: >>>> Hi, >>>> >>>> While working on the XForms W3C test suite test harness for Orbeon, I >>>> hit the following: >>>> >>>> Orbeon doesn't requires you to prepend your app with 'apps/' in the >>>> request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if >>>> your app is in resources/apps/xforms-test-suite) when using the >>>> default distributed global page-flow.xml. This is a nice feature, but >>>> when static resources are served (by adding a files element, e.g.: >>>> <files >>>> >>>> path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" >>>> matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to >>>> use orbeon/apps/xforms-test-suite/images/add.gif instead. This is >>>> quite annoying because the XForms 1.1 test suite uses a lot of >>>> relative resources for instances, css, ... (I could rewrite them but >>>> this isn't nice). >>>> >>>> When I looked to the problem I found that I could easily hack a >>>> workaround by changing the following xpath in >>>> PageFlowControllerProcessor (see also attached patch): >>>> >>>> "string(/request/request-path)" >>>> >>>> into: >>>> >>>> "string(if (starts-with(/request/request-path, '/apps/')) then >>>> /request/request-path else concat('/apps/', /request/request-path))" >>>> >>>> It really feels like a hack but I was wondering if we couldn't add an >>>> extra optional 'rewrite-path' attribute on the files element, which >>>> will cause a rewrite of the path, in which you can use the groups of >>>> the matcher. So the entries in the global page-flow.xml will look >>>> like: >>>> >>>> <files >>>> >>>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >>>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> >>>> >>>> Correct me if I'm wrong but this could easily be done by using the >>>> output of the regexp processor, used in the pipeline constructed in >>>> the PageFlowControllerProcessor for handling files. >>>> >>>> What is your opinion on this? >>>> >>>> -- >>>> Regards, >>>> >>>> Nick Van den Bleeken >>>> >>> >>> >>> >>> -- >>> Regards, >>> >>> Nick Van den Bleeken >>> >>> >>> -- >>> 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 >> >> >> ________________________________ >> View message @ >> >> http://n4.nabble.com/Path-problem-with-serving-static-files-tp1290244p1469645.html >> To start a new topic under ObjectWeb OPS - Users, email >> [hidden email] >> To unsubscribe from ObjectWeb OPS - Users, click here. >> > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Path problem with serving static > files. > 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 > > -- 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 |
Administrator
|
Hi Nick,
While I was looking at some URL rewriting code, I started putting in place some code to address this. Basically, the idea is to implement the policy above: "Any non-platform resource path that does not already start with either '/apps', '/xbl', or '/forms' shall be prefixed with '/apps'". I didn't want to go through the trouble of exposing this at the level of the PFC, so in addition to the recently added oxf.url-rewriting.platform-paths, I just added two properties to control this: * oxf.url-rewriting.app-paths * oxf.url-rewriting.app-prefix Also see the doc [1] and the commit [2]. For now the properties are commented out in the default properties-base.xml, but the idea would be to enable them soon by default. Usually, app authors wouldn't have to modify these properties if they put apps under /apps. -Erik [1] http://wiki.orbeon.com/forms/doc/developer-guide/configuration-properties/configuration-properties-base#TOC-URL-rewriting [2] http://github.com/orbeon/orbeon-forms/commit/bdb00962a72d9faa15a1a7e21a293c5a7185b7c0 On Tue, Feb 9, 2010 at 11:56 AM, Erik Bruchez <[hidden email]> wrote: > Nick, > > (As a note, if you just want the test suite to work, it is possible to > add a top-level page flow rule for /apps/xforms-test-suite/*.) > > In the big picture it is still better to have a more general fix! > > So one question is: does this need to be a feature exposed through the > syntax of the PFC, or should it be hard-coded. > > Orbeon Forms has a notion of two different types of paths for resources: > > * platform paths: start w/ '/ops/', '/config/', '/xbl/orbeon/', > '/xforms-server' (should add '/forms/orbeon'!) > * application paths (everything else) > > This distinction is made so we can rewrite versioned resources with > the proper version number: an Orbeon version number for Orbeon > resources, and an application version number for applications. > > Our main concern here are application paths. > > One issue is that '/apps' is not the only possible non-platform > prefix, because we also have the '/xbl' and '/forms' prefixes to > handle. For both it is possible to have component-specific resources > like JS, CSS, and image files. > > So we can't just check on '/apps' I think. The algorithm should probably be: > > "Any non-platform resource path that does not already start with > either '/apps', '/xbl', or '/forms' shall be prefixed with '/apps'". > > Now is it possible to implement this algorithm with regexps and > something like the rewrite-path attribute you suggested? If so, and if > it's not too hard to implement, I guess we could expose that to the > PFC syntax. If not or too hard, then we probably need to implement it > natively in the PFC. > > Whichever way we do it, it might be a good idea to have the ability to > turn this off, since some users do not put their apps under '/apps'. > > -Erik > > On Sun, Feb 7, 2010 at 8:28 AM, nvdbleek <[hidden email]> wrote: >> HI Erik, >> >> Do you want this as a general fix if the path doesn't start with >> /apps/ add it or do you want the fix with allows you to configure this >> using >> >> <files >> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >> >> If you say what you want I can implement it. >> >> Regards, >> >> Nick Van den Bleeken >> [hidden email] >> >> On Fri, Feb 5, 2010 at 02:01, Erik Bruchez-3 [via Orbeon Forms >> (ops-users)] <[hidden email]> wrote: >>> Hi Nick, >>> >>> Oops, I wanted to answer this way earlier. >>> >>> Let's try to figure this out. >>> >>> I think you are right. Here is a scenario: >>> >>> RESOURCES/apps/xforms-test-suite/my-test.xhtml >>> >>> This is loaded in the browser as: >>> >>> http://localhost:8080/orbeon/xforms-test-suite/my-test.xhtml >>> >>> IIRC we did this in order to have a nicer URL without the "apps" prefix. >>> >>> Now if my-test.xhtml refers to foobar.gif, we have: >>> >>> http://localhost:8080/orbeon/xforms-test-suite/foobar.gif >>> >>> and we expect this to be under: >>> >>> RESOURCES/apps/xforms-test-suite/foobar.gif >>> >>> But right now, this will be fetched under: >>> >>> RESOURCES/xforms-test-suite/foobar.gif >>> >>> which will 404. >>> >>> The idea of taking an incoming resource and considering that it's an >>> application resource is good I think. We need to exclude "platform >>> paths" from this. E.g. some resources start with /ops or /config etc. >>> and need to stay there. >>> >>> Do you want to give this a try? ;) >>> >>> -Erik >>> >>> On Tue, Jan 26, 2010 at 3:51 AM, Nick Van den Bleeken <[hidden email]> >>> wrote: >>>> There was a typo in my previous e-mail, it should be: >>>> >>>> <files >>>> >>>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >>>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >>>> >>>> (rewrite path should be /apps/${5} and not /apps/${1}) >>>> >>>> Sorry for the small error >>>> >>>> Regards, >>>> >>>> Nick Van den Bleeken >>>> >>>> On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> >>>> wrote: >>>>> Hi, >>>>> >>>>> While working on the XForms W3C test suite test harness for Orbeon, I >>>>> hit the following: >>>>> >>>>> Orbeon doesn't requires you to prepend your app with 'apps/' in the >>>>> request url (e.g.: http://localhost:8080/orbeon/xforms-test-suite/ if >>>>> your app is in resources/apps/xforms-test-suite) when using the >>>>> default distributed global page-flow.xml. This is a nice feature, but >>>>> when static resources are served (by adding a files element, e.g.: >>>>> <files >>>>> >>>>> path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" >>>>> matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to >>>>> use orbeon/apps/xforms-test-suite/images/add.gif instead. This is >>>>> quite annoying because the XForms 1.1 test suite uses a lot of >>>>> relative resources for instances, css, ... (I could rewrite them but >>>>> this isn't nice). >>>>> >>>>> When I looked to the problem I found that I could easily hack a >>>>> workaround by changing the following xpath in >>>>> PageFlowControllerProcessor (see also attached patch): >>>>> >>>>> "string(/request/request-path)" >>>>> >>>>> into: >>>>> >>>>> "string(if (starts-with(/request/request-path, '/apps/')) then >>>>> /request/request-path else concat('/apps/', /request/request-path))" >>>>> >>>>> It really feels like a hack but I was wondering if we couldn't add an >>>>> extra optional 'rewrite-path' attribute on the files element, which >>>>> will cause a rewrite of the path, in which you can use the groups of >>>>> the matcher. So the entries in the global page-flow.xml will look >>>>> like: >>>>> >>>>> <files >>>>> >>>>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >>>>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> >>>>> >>>>> Correct me if I'm wrong but this could easily be done by using the >>>>> output of the regexp processor, used in the pipeline constructed in >>>>> the PageFlowControllerProcessor for handling files. >>>>> >>>>> What is your opinion on this? >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Nick Van den Bleeken >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Nick Van den Bleeken >>>> >>>> >>>> -- >>>> 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 >>> >>> >>> ________________________________ >>> View message @ >>> >>> http://n4.nabble.com/Path-problem-with-serving-static-files-tp1290244p1469645.html >>> To start a new topic under ObjectWeb OPS - Users, email >>> [hidden email] >>> To unsubscribe from ObjectWeb OPS - Users, click here. >>> >> >> >> -- >> Regards, >> >> Nick Van den Bleeken >> >> ________________________________ >> View this message in context: Re: Re: Path problem with serving static >> files. >> 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 >> >> > -- 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 |
Hi Erik,
Sorry that it took so long to respond... Thank you for implementing this. I don't know if it is on purpose, but the documentation [1] states that /apps is the default value for oxf.url-rewriting.app-prefix but this currently not the case. This element is commented out in properties-base.xml with a TODO comment 'Uncomment this properties once we are confident', and therefore oxf.url-rewriting.app-prefix defaults to the empty string. I think either the documentation or properties-base.xml needs to be updated. If you update properties-base.xml you probably want to say something about that in the upgrade guide, because people could already have prepended everything with /apps to work around the 'bug'. Regards, Nick Van den Bleeken On Wed, Apr 21, 2010 at 02:15, Erik Bruchez [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Hi Nick, -- Regards, Nick Van den Bleeken |
Nick,
Thanks for the feedback! That's right, we just plan to make "/apps" the default in the future but right now it's the empty string. I reviewed the URL rewriting properties doc and updated it to be clearer. -Erik On Sat, May 8, 2010 at 5:26 AM, nvdbleek <[hidden email]> wrote: > Hi Erik, > > Sorry that it took so long to respond... > > Thank you for implementing this. I don't know if it is on purpose, but the > documentation [1] states that /apps is the default value for > oxf.url-rewriting.app-prefix but this currently not the case. This element > is commented out in properties-base.xml with a TODO comment 'Uncomment this > properties once we are confident', and therefore > oxf.url-rewriting.app-prefix defaults to the empty string. > > I think either the documentation or properties-base.xml needs to be > updated. If you update properties-base.xml you probably want to say > something about that in the upgrade guide, because people could already have > prepended everything with /apps to work around the 'bug'. > > Regards, > > Nick Van den Bleeken > > On Wed, Apr 21, 2010 at 02:15, Erik Bruchez [via Orbeon Forms (ops-users)] > <[hidden email]> wrote: >> >> Hi Nick, >> >> While I was looking at some URL rewriting code, I started putting in >> place some code to address this. >> >> Basically, the idea is to implement the policy above: >> >> "Any non-platform resource path that does not already start with >> either '/apps', '/xbl', or '/forms' shall be prefixed with '/apps'". >> >> I didn't want to go through the trouble of exposing this at the level >> of the PFC, so in addition to the recently added >> oxf.url-rewriting.platform-paths, I just added two properties to >> control this: >> >> * oxf.url-rewriting.app-paths >> * oxf.url-rewriting.app-prefix >> >> Also see the doc [1] and the commit [2]. >> >> For now the properties are commented out in the default >> properties-base.xml, but the idea would be to enable them soon by >> default. Usually, app authors wouldn't have to modify these properties >> if they put apps under /apps. >> >> -Erik >> >> [1] >> http://wiki.orbeon.com/forms/doc/developer-guide/configuration-properties/configuration-properties-base#TOC-URL-rewriting >> [2] >> http://github.com/orbeon/orbeon-forms/commit/bdb00962a72d9faa15a1a7e21a293c5a7185b7c0 >> >> On Tue, Feb 9, 2010 at 11:56 AM, Erik Bruchez <[hidden email]> wrote: >> > Nick, >> > >> > (As a note, if you just want the test suite to work, it is possible to >> > add a top-level page flow rule for /apps/xforms-test-suite/*.) >> > >> > In the big picture it is still better to have a more general fix! >> > >> > So one question is: does this need to be a feature exposed through the >> > syntax of the PFC, or should it be hard-coded. >> > >> > Orbeon Forms has a notion of two different types of paths for resources: >> > >> > * platform paths: start w/ '/ops/', '/config/', '/xbl/orbeon/', >> > '/xforms-server' (should add '/forms/orbeon'!) >> > * application paths (everything else) >> > >> > This distinction is made so we can rewrite versioned resources with >> > the proper version number: an Orbeon version number for Orbeon >> > resources, and an application version number for applications. >> > >> > Our main concern here are application paths. >> > >> > One issue is that '/apps' is not the only possible non-platform >> > prefix, because we also have the '/xbl' and '/forms' prefixes to >> > handle. For both it is possible to have component-specific resources >> > like JS, CSS, and image files. >> > >> > So we can't just check on '/apps' I think. The algorithm should probably >> > be: >> > >> > "Any non-platform resource path that does not already start with >> > either '/apps', '/xbl', or '/forms' shall be prefixed with '/apps'". >> > >> > Now is it possible to implement this algorithm with regexps and >> > something like the rewrite-path attribute you suggested? If so, and if >> > it's not too hard to implement, I guess we could expose that to the >> > PFC syntax. If not or too hard, then we probably need to implement it >> > natively in the PFC. >> > >> > Whichever way we do it, it might be a good idea to have the ability to >> > turn this off, since some users do not put their apps under '/apps'. >> > >> > -Erik >> > >> > On Sun, Feb 7, 2010 at 8:28 AM, nvdbleek <[hidden email]> wrote: >> >> HI Erik, >> >> >> >> Do you want this as a general fix if the path doesn't start with >> >> /apps/ add it or do you want the fix with allows you to configure this >> >> using >> >> >> >> <files >> >> >> >> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> >> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >> >> >> >> If you say what you want I can implement it. >> >> >> >> Regards, >> >> >> >> Nick Van den Bleeken >> >> [hidden email] >> >> >> >> On Fri, Feb 5, 2010 at 02:01, Erik Bruchez-3 [via Orbeon Forms >> >> (ops-users)] <[hidden email]> wrote: >> >>> Hi Nick, >> >>> >> >>> Oops, I wanted to answer this way earlier. >> >>> >> >>> Let's try to figure this out. >> >>> >> >>> I think you are right. Here is a scenario: >> >>> >> >>> RESOURCES/apps/xforms-test-suite/my-test.xhtml >> >>> >> >>> This is loaded in the browser as: >> >>> >> >>> http://localhost:8080/orbeon/xforms-test-suite/my-test.xhtml >> >>> >> >>> IIRC we did this in order to have a nicer URL without the "apps" >> >>> prefix. >> >>> >> >>> Now if my-test.xhtml refers to foobar.gif, we have: >> >>> >> >>> http://localhost:8080/orbeon/xforms-test-suite/foobar.gif >> >>> >> >>> and we expect this to be under: >> >>> >> >>> RESOURCES/apps/xforms-test-suite/foobar.gif >> >>> >> >>> But right now, this will be fetched under: >> >>> >> >>> RESOURCES/xforms-test-suite/foobar.gif >> >>> >> >>> which will 404. >> >>> >> >>> The idea of taking an incoming resource and considering that it's an >> >>> application resource is good I think. We need to exclude "platform >> >>> paths" from this. E.g. some resources start with /ops or /config etc. >> >>> and need to stay there. >> >>> >> >>> Do you want to give this a try? ;) >> >>> >> >>> -Erik >> >>> >> >>> On Tue, Jan 26, 2010 at 3:51 AM, Nick Van den Bleeken <[hidden email]> >> >>> wrote: >> >>>> There was a typo in my previous e-mail, it should be: >> >>>> >> >>>> <files >> >>>> >> >>>> >> >>>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> >>>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${5}"/> >> >>>> >> >>>> (rewrite path should be /apps/${5} and not /apps/${1}) >> >>>> >> >>>> Sorry for the small error >> >>>> >> >>>> Regards, >> >>>> >> >>>> Nick Van den Bleeken >> >>>> >> >>>> On Tue, Jan 26, 2010 at 12:47, Nick Van den Bleeken <[hidden email]> >> >>>> wrote: >> >>>>> Hi, >> >>>>> >> >>>>> While working on the XForms W3C test suite test harness for Orbeon, >> >>>>> I >> >>>>> hit the following: >> >>>>> >> >>>>> Orbeon doesn't requires you to prepend your app with 'apps/' in the >> >>>>> request url (e.g.: >> >>>>> http://localhost:8080/orbeon/xforms-test-suite/ if >> >>>>> your app is in resources/apps/xforms-test-suite) when using the >> >>>>> default distributed global page-flow.xml. This is a nice feature, >> >>>>> but >> >>>>> when static resources are served (by adding a files element, e.g.: >> >>>>> <files >> >>>>> >> >>>>> >> >>>>> path-info="(?!/([^/]+)/service/).+\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt)" >> >>>>> matcher="oxf:perl5-matcher"/>) relative urls wont' work. You have to >> >>>>> use orbeon/apps/xforms-test-suite/images/add.gif instead. This is >> >>>>> quite annoying because the XForms 1.1 test suite uses a lot of >> >>>>> relative resources for instances, css, ... (I could rewrite them but >> >>>>> this isn't nice). >> >>>>> >> >>>>> When I looked to the problem I found that I could easily hack a >> >>>>> workaround by changing the following xpath in >> >>>>> PageFlowControllerProcessor (see also attached patch): >> >>>>> >> >>>>> "string(/request/request-path)" >> >>>>> >> >>>>> into: >> >>>>> >> >>>>> "string(if (starts-with(/request/request-path, '/apps/')) then >> >>>>> /request/request-path else concat('/apps/', /request/request-path))" >> >>>>> >> >>>>> It really feels like a hack but I was wondering if we couldn't add >> >>>>> an >> >>>>> extra optional 'rewrite-path' attribute on the files element, which >> >>>>> will cause a rewrite of the path, in which you can use the groups of >> >>>>> the matcher. So the entries in the global page-flow.xml will look >> >>>>> like: >> >>>>> >> >>>>> <files >> >>>>> >> >>>>> >> >>>>> path-info="(?!/([^/]+)/service/)((/apps/)|/)?(.+\\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf|html|txt))" >> >>>>> matcher="oxf:perl5-matcher" rewrite-path="/apps/${1}"/> >> >>>>> >> >>>>> Correct me if I'm wrong but this could easily be done by using the >> >>>>> output of the regexp processor, used in the pipeline constructed in >> >>>>> the PageFlowControllerProcessor for handling files. >> >>>>> >> >>>>> What is your opinion on this? >> >>>>> >> >>>>> -- >> >>>>> Regards, >> >>>>> >> >>>>> Nick Van den Bleeken >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Regards, >> >>>> >> >>>> Nick Van den Bleeken >> >>>> >> >>>> >> >>>> -- >> >>>> 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 >> >>> >> >>> >> >>> ________________________________ >> >>> View message @ >> >>> >> >>> >> >>> http://n4.nabble.com/Path-problem-with-serving-static-files-tp1290244p1469645.html >> >>> To start a new topic under ObjectWeb OPS - Users, email >> >>> [hidden email] >> >>> To unsubscribe from ObjectWeb OPS - Users, click here. >> >>> >> >> >> >> >> >> -- >> >> Regards, >> >> >> >> Nick Van den Bleeken >> >> >> >> ________________________________ >> >> View this message in context: Re: Re: Path problem with serving static >> >> files. >> >> 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 >> >> >> >> >> > >> -- >> 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 message @ >> http://n4.nabble.com/Path-problem-with-serving-static-files-tp1290244p2018246.html >> To start a new topic under Orbeon Forms (ops-users), email [hidden email] >> To unsubscribe from Orbeon Forms (ops-users), click here. > > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Re: Path problem with serving static > files. > Sent from the Orbeon Forms (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 > > -- 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, Thank for the fast reply. I think that this is the best solution too. Best, Nick On May 11, 2010 12:39 AM, "Erik Bruchez-3 [via Orbeon Forms (ops-users)]" <[hidden email]> wrote: |
Free forum by Nabble | Edit this page |