Hi Thomas,

I considered also some kind of routing, almost all web frameworks try to 
accomplish this.

I am in favor of, what you already implemented. As I understand it, it is 
a parameter based mapping.

You already implemented a valve with uses mapFromURL and a 
MappedTemplateLink (extends TemplateURL) a ApplicationTool, which uses 
mapToURL. If someone decides to use it, he would like to use it with the 
aim to do it consistently, whereever it is possible and that's, what he 
needs. He would then add the valve to the pipeline and use the new 
ApplicationTool in the templates.


Might it be that performance is an issue? The method mapFromUrl is called 
only once per request, but mapToURL multiple times in a template with a 
lot of links.. I will check the code in more detail ...

Another question would be, how to know if any arbitrary TemplateURL might 
become friendly? We might need to add some tests more...  ;-)
 I hopefully could add some tests and might want to use it in our docker 
turbine archetype, create a branch there or try to test it in a more 
integrated environment. Nevertheless it is a feature we should add IMO. 

>From my side, it's a deal, and we may proceed for some time in the branch, 
but merge it, as soon as it seems to be stable and useable. What do you 
think?

Best regards, Georg

Thinking about what it is not you might agree: Achieving a more controller 
based routing or even providing a routing table might be not only quite 
some more effort, but something totally different requiring probably a 
complete rewrite of the pipeline valves layer. Your URLMapperService on 
the other side is a consistent, lightweight, and very elegant way of a URL 
routing mechanism in "The Turbine way". ;-)



Von:    Thomas Vandahl <[email protected]>
An:     Turbine Developers List <[email protected]>
Datum:  05.01.2021 16:27
Betreff:        Need some help: was: svn commit: r1885148 - 
/turbine/core/branches/URLMapperService/



On 05.01.21 15:50, [email protected] wrote:
> Author: tv
> Date: Tue Jan  5 14:50:42 2021
> New Revision: 1885148
> 
> URL: http://svn.apache.org/viewvc?rev=1885148&view=rev
> Log:
> Experimental URL mapper implementation
> 
> Added:
>      turbine/core/branches/URLMapperService/
>        - copied from r1885147, turbine/core/trunk/
> 

Hi folks,

I've been carrying this with me for quite some time. The Liferay Portal 
supports a rule-based mapping of (almost) arbitrary URLs to sets of 
application parameters and vice-versa. (See 
https://help.liferay.com/hc/en-us/articles/360017880652-Making-URLs-Friendlier
)

Why not build something like this for Turbine?
So this is my first attempt on a possible implementation.

What does it do?
Say, you want to simplify your URLs to make them easier to read, type or 
remember.

- Instead of /context/app/template/Book.vm?id=1234
   Use /context/app/book/1234

- Instead of /context/app/template/Book.vm/action/BookSave
   Use /context/app/book/save

Say, you want to publish certain landing pages that map to a 
parametrized page in your app.

- Instead of /context/app/template/BookList.vm?sale=true
   Use /context/app/books-on-sale

You get the point. Some kind of mod_redirect, but *bi-directional*.

*If you think this may be for you, please help me testing.*

How do I use it?
I'm planning to write some documentation but for the time being, check 
out the branch turbine/core/branches/URLMapperService/ and have a look 
at the files
- conf/turbine-url-mapping.xml for some configuration examples
- conf/test/TurbineURLMapperServiceTest.properties for the service 
configuration
- 
src/test/org/apache/turbine/services/urlmapper/TurbineURLMapperServiceTest.java 

for some preliminary test cases.

Please check if this meets your needs, check your use-cases, 
corner-cases, performance etc.

I'm eager to get your feedback.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to