XQueryURLRewrite implementation change proposal

[thomas.0007]

XQueryURLRewrite  is a very convenient and simple way to separate the request URL format from the inner xquery implementation structure.
The way it is implemented in a single xquery file where the URL is checked against number patterns in a long if-then-else statement could be convenient for a simple cases,with small number of applications on a single server.

 

If we have a project with multiple applications, developed by a number of teams it will be not practical to keep the logic for all URL redirection rules in a single file and it will be a single point of failure for the whole server if somebody misspells a command in controller.xql file.

 

I would like to propose a small extension in the logic of  how XQueryURLRewrite finds the file with redirection rules.

The idea is to search for controller.xql first in the sub-directories matching the URL structure and if not such file is found then execute the main webapp/controller.xql.

 

1. We can have controller.xql ( or whatever reserved name we choose) in any directory under webapp.

2. XQueryURLRewrite will try to interpret every part of the URL separated by slash as a directory from webapp down, looking for controller.xql file in this directory.

3. If controller.xql  is found then use it, respecting all relative paths to the directory where controller.xql was found. 

4. If not then try to interpret next part of the URL as a directory.

5. When we add the next part of the URL and the path points to a non exiting directory, then we use webapp/controller.xql

 

I believe this approach of separating redirection rules by application will make the development and maintenance simpler and more robust.

When we install an application WAR file, all redirections will work automatically, because the application will come with its own controller.xql.

When we remove the application all relevant redirections will go as well and all this will happen without need to touch webapp/controller.xql at all.

 

Then webapp/controller.xql  will be used for same very generic cases of redirection.

I hope this will be of any help.

 

Regards,

Tom

--
Thomas White

51 Glebewood
Bracknell
Berks RG12 9SD
Mobile:[phone]
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007

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

_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[Wolfgang Meier-2]

> I would like to propose a small extension in the logic of  how
> XQueryURLRewrite finds the file with redirection rules.
> The idea is to search for controller.xql first in the sub-directories
> matching the URL structure and if not such file is found then execute
> the main webapp/controller.xql.

I agree that having a single controller is not very convenient. I like
your proposal, though there's one problem to solve: with the current
implementation, controller.xql does not need to be in the file system.
It could also be stored in the db. This is an important feature. We
would thus need to implement the same logic in the db as for the file
system. This will make XQueryURLRewrite slightly more complicated.
Another problem is that the filter caches the URIs it already processed.
We would need to clean those whenever one of the controller changes.

Anyway, I guess those issues can be solved.

Wolfgang

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[coach3pete]

Can the master controller delegate to other controllers?
Erik

On Jan 6, 2009, at 2:58 PM, Wolfgang wrote:

>> I would like to propose a small extension in the logic of  how
>> XQueryURLRewrite finds the file with redirection rules.
>> The idea is to search for controller.xql first in the sub-directories
>> matching the URL structure and if not such file is found then execute
>> the main webapp/controller.xql.
>
> I agree that having a single controller is not very convenient. I like
> your proposal, though there's one problem to solve: with the current
> implementation, controller.xql does not need to be in the file system.
> It could also be stored in the db. This is an important feature. We
> would thus need to implement the same logic in the db as for the file
> system. This will make XQueryURLRewrite slightly more complicated.
> Another problem is that the filter caches the URIs it already  
> processed.
> We would need to clean those whenever one of the controller changes.
>
> Anyway, I guess those issues can be solved.
>
> Wolfgang
>
> ------------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> Exist-open mailing list
> Exist-open@...
> https://lists.sourceforge.net/lists/listinfo/exist-open

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[simo ivanov]

The biggest value I'd see in a rewrite of this filter from the current
form would be the ability to add custom java code for the following stages:

- parsing the URL (the servlet mapping)
- selecting (or skipping this stage entirely ;)) the xquery URL to
forward to (the config parameter)
- eventually, passing URL bits to xquery functions "naturally" (although
request attributes work fine at the moment),

while keeping it simple and fast.

Considering the current implementation, I'd see the biggest return in
slightly better code organization. For example, all the action that now
happens in the doFilter method can be split in two or three protected
methods -- parseURL (I need more than the servlet mapping, and do it in
the xquery now), selectForwardResource (this is nearly good enough now)
and, maybe, returnCached or something similar. I would basically keep  a
very simple implementation (the current has too many features already
IMHO) as the default. The rest of the utility APIs are probably fine as now.

This basic filter can be extended trivially for any mapping and extra
functionality needed, and allow the people who only need the thinnest
layer enough rope without extra overhead.

IMHO, attaching a model and serialization logic would fit better in a
separate filter that is chainable to the URL rewriter, but implemented
in a separate class or even package.

Best regards,


coach3pete wrote:

> Can the master controller delegate to other controllers?
> Erik
>
> On Jan 6, 2009, at 2:58 PM, Wolfgang wrote:
>
>>> I would like to propose a small extension in the logic of  how
>>> XQueryURLRewrite finds the file with redirection rules.
>>> The idea is to search for controller.xql first in the sub-directories
>>> matching the URL structure and if not such file is found then execute
>>> the main webapp/controller.xql.
>> I agree that having a single controller is not very convenient. I like
>> your proposal, though there's one problem to solve: with the current
>> implementation, controller.xql does not need to be in the file system.
>> It could also be stored in the db. This is an important feature. We
>> would thus need to implement the same logic in the db as for the file
>> system. This will make XQueryURLRewrite slightly more complicated.
>> Another problem is that the filter caches the URIs it already  
>> processed.
>> We would need to clean those whenever one of the controller changes.
>>
>> Anyway, I guess those issues can be solved.
>>
>> Wolfgang

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[simo ivanov]

I am afraid my previous comment needs a slight clarification ...

By "the xquery URL to forward to" I mean the xquery controller.

Similarly, for "passing URL bits to xquery functions" - the URL bits
should be going to the xquery controller, not to some abstract "xquery
functions".

Best regards,

simo ivanov wrote:
> - selecting (or skipping this stage entirely ;)) the xquery URL to
> forward to (the config parameter)
> - eventually, passing URL bits to xquery functions "naturally" (although
> request attributes work fine at the moment),



------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[Wolfgang Meier-2]

> I would like to propose a small extension in the logic of  how
> XQueryURLRewrite finds the file with redirection rules.
> The idea is to search for controller.xql first in the sub-directories
> matching the URL structure and if not such file is found then execute the
> main webapp/controller.xql.

I implemented your proposal in rev 9247. XQueryURLRewrite can now scan
the directory or collection hierarchy to find a controller.xql which
matches the request path. For example, if the requested path is
/exist/a/b, XQueryURLRewrite will check the directories webapp/a and
webapp/a/b for an XQuery file called controller.xql and executes the
last one it finds.

The start point for the search is determined by configuration
parameter "base" in web.xml. This parameter can also point to a
collection in the db, causing XQueryURLRewrite to search the
collection hierarchy instead of the file system.

    <filter>
        <filter-name>XQueryURLRewrite</filter-name>
        <filter-class>org.exist.http.urlrewrite.XQueryURLRewrite</filter-class>
        <init-param>
            <param-name>base</param-name>
            <param-value>xmldb:exist:///db</param-value>
        </init-param>
    </filter>

Wolfgang

------------------------------------------------------------------------------
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[thomas.0007]

Wolfgang,

The implementation of the multiple controller.xql is really useful. The only
small inconvenience to use this feature is the fact the if any modules are
imported by controller.xql, we still need to specify the full path of the
module relative to webapps. It would have been much easier if the controller
picks up the modules from the same directory.
The good news is that the relative import paths already have been
implemented (Patch #2812962) and I was wandering if there is any chance to
include the relative module import in the coming release.

Regards,
Thomas


"Wolfgang Meier" <wolfgang@...> wrote in message
news:19f274050906300047y3d850ee7r1329a1610e0b2a49@......
> I would like to propose a small extension in the logic of how
> XQueryURLRewrite finds the file with redirection rules.
> The idea is to search for controller.xql first in the sub-directories
> matching the URL structure and if not such file is found then execute the
> main webapp/controller.xql.

I implemented your proposal in rev 9247. XQueryURLRewrite can now scan
the directory or collection hierarchy to find a controller.xql which
matches the request path. For example, if the requested path is
/exist/a/b, XQueryURLRewrite will check the directories webapp/a and
webapp/a/b for an XQuery file called controller.xql and executes the
last one it finds.

The start point for the search is determined by configuration
parameter "base" in web.xml. This parameter can also point to a
collection in the db, causing XQueryURLRewrite to search the
collection hierarchy instead of the file system.

    <filter>
        <filter-name>XQueryURLRewrite</filter-name>
        <filter-class>org.exist.http.urlrewrite.XQueryURLRewrite</filter-class>
        <init-param>
            <param-name>base</param-name>
            <param-value>xmldb:exist:///db</param-value>
        </init-param>
    </filter>

Wolfgang

------------------------------------------------------------------------------
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open




------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[Dannes Wessels-2]

On 17 Jul 2009, at 18:20 , Thomas White wrote:

> The good news is that the relative import paths already have been
> implemented (Patch #2812962) and I was wandering if there is any  
> chance to
> include the relative module import in the coming release.


We need to test the patch first thoroughly. I have some testcases in  
minde, not sure weather they will pass....

I'll try to add these tests asap.


Kind regards

Dannes

--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624










------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

[thomas.0007]

Dannes,

I guess when the relative module include is in place then the redirection from the controller.xql to other .xql files can be relative as well.

 

Thomas

2009/7/17 Dannes Wessels <dizzzz@...>

On 17 Jul 2009, at 18:20 , Thomas White wrote:

The good news is that the relative import paths already have been
implemented (Patch #2812962) and I was wandering if there is any chance to
include the relative module import in the coming release.

We need to test the patch first thoroughly. I have some testcases in minde, not sure weather they will pass....

I'll try to add these tests asap.


Kind regards

Dannes

--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

--
Thomas White

Mobile:[phone]
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open