|
»
« Return to Thread: XQueryURLRewrite implementation change proposal
Re: XQueryURLRewrite implementation change proposal
by simo ivanov
::
Rate this Message:
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
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
« Return to Thread: XQueryURLRewrite implementation change proposal
| Free embeddable forum powered by Nabble | Forum Help |
