You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@turbine.apache.org by tv...@apache.org on 2021/01/05 14:50:43 UTC
svn commit: r1885148 - /turbine/core/branches/URLMapperService/
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/
Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Georg,
On 06.01.21 10:59, Georg Kallidis wrote:
> 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 ...
There are possibilities for aggressive caching. I need to figure out how
to balance cache size with request count, however.
> Another question would be, how to know if any arbitrary TemplateURL might
> become friendly? We might need to add some tests more... ;-)
The whole idea is based on pattern matching. If you want to have more
control over the behavior, you may as well use two different link tools
in the context.
> 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". ;-)
I didn't have that in mind, initially. I wanted a non-intrusive
solution. But you are right, the approach could be extended to arbitrary
routing to screens and/or actions, e.g. by adding the screen class or
template to the mapping configuration.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
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 <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 05.01.2021 16:27
Betreff: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
On 05.01.21 15:50, tv@apache.org 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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Behaviour ignored-parameter in Turbine service URLMapperService
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Hi Turbine Devs,
i tested the merged url mapper and added some more tests and a xdoc draft.
Additionally I changed the behaviour for ignore-parameter, if the same
parameter is there as capturing group name in pattern url. The new result
is that it clears out the ignored parameter's value from the the mapped
url, if it is set as capturing group name (and as ignored-parame)ter.
Could this be achieved easier? I don't know at the moment.
Before the change ignore-parameter does
- in mapFromUrl not set the parameter in the result parameters (nothing
changed here)
- in mapToUrl the ignored keys are removed from the required keys (same
as before). If provided as query data they will be retained in the result
(the mapped uri). That is, as I understand, the intention is, that they
need not be set as a capturing group name or a implict key.
Setting an ignored parameter as implicit parameter makes no sense and has
no effect, as it is cleared out (implicity does just mean, that the
parameter is set to a default value, when converting it back with
mapFromUrl).
But an ignored parameter provided as a capturing group name? It just would
retain the value in the result, as any capturing group name, that is, if
provided as query data. That case could be achieved by NOT ignoring the
parameter, as then the required keys contain ans set it. But if we want to
match an URI containing the ignored parameter and want it removed from the
mapped url at the same time ? Before, when providing a ignored parameter
as capturing key it wouldn't ignore it's value, but set it. Now it's
ignored. See the two cases in TurbineURLMapperJSONServiceTest.
As all the tests pass, I am not aware of anything that would break ..
please let me know, what you think ..
Best regards, Georg
Von: "Georg Kallidis" <ge...@cedis.fu-berlin.de>
An: "Turbine Developers List" <de...@turbine.apache.org>
Datum: 01.02.2021 10:53
Betreff: Re: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi all,
I merged the branch into trunk (/turbine/core/trunk). I 'll delete the
branch later to avoid inconsistencies, if nobody complains. Please don't
forget to update your working copies!
Best regards, Georg
Von: Jeffery Painter <je...@jivecast.com>
An: dev@turbine.apache.org
Datum: 18.01.2021 17:48
Betreff: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi guys,
I have not had time to look, but I am OK with whatever you two decide
:-) It sounds like a nice addition to the framework, and when I get
some time, I would like to play with it.
-
Jeffery
On 1/17/21 10:56 AM, Thomas Vandahl wrote:
> On 15.01.21 13:48, Georg Kallidis wrote:
>> What do you think, should we merge it? Are there rules to be
>> respected, do
>> we need a vote taking place? What's Jeffery's opinion?
>
> I don't know of any rules. I would like to hear Jeffs opinion, though,
> before we proceed.
>
> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Hi all,
I merged the branch into trunk (/turbine/core/trunk). I 'll delete the
branch later to avoid inconsistencies, if nobody complains. Please don't
forget to update your working copies!
Best regards, Georg
Von: Jeffery Painter <je...@jivecast.com>
An: dev@turbine.apache.org
Datum: 18.01.2021 17:48
Betreff: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi guys,
I have not had time to look, but I am OK with whatever you two decide
:-) It sounds like a nice addition to the framework, and when I get
some time, I would like to play with it.
-
Jeffery
On 1/17/21 10:56 AM, Thomas Vandahl wrote:
> On 15.01.21 13:48, Georg Kallidis wrote:
>> What do you think, should we merge it? Are there rules to be
>> respected, do
>> we need a vote taking place? What's Jeffery's opinion?
>
> I don't know of any rules. I would like to hear Jeffs opinion, though,
> before we proceed.
>
> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Jeffery Painter <je...@jivecast.com>.
Hi guys,
I have not had time to look, but I am OK with whatever you two decide
:-) It sounds like a nice addition to the framework, and when I get
some time, I would like to play with it.
-
Jeffery
On 1/17/21 10:56 AM, Thomas Vandahl wrote:
> On 15.01.21 13:48, Georg Kallidis wrote:
>> What do you think, should we merge it? Are there rules to be
>> respected, do
>> we need a vote taking place? What's Jeffery's opinion?
>
> I don't know of any rules. I would like to hear Jeffs opinion, though,
> before we proceed.
>
> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Thomas Vandahl <tv...@apache.org>.
On 15.01.21 13:48, Georg Kallidis wrote:
> What do you think, should we merge it? Are there rules to be respected, do
> we need a vote taking place? What's Jeffery's opinion?
I don't know of any rules. I would like to hear Jeffs opinion, though,
before we proceed.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Re: Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
What do you think, should we merge it? Are there rules to be respected, do
we need a vote taking place? What's Jeffery's opinion?
-Georg
Von: "Georg Kallidis" <ge...@cedis.fu-berlin.de>
An: "Turbine Developers List" <de...@turbine.apache.org>
Datum: 15.01.2021 12:45
Betreff: Re: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).
I stumbled across this before. The may be something wrong with the pool
handling of parsers. In my case, I got pool depletion with only local
testing. Very strange.
I fixed it by adjusting property max-total for fulcrum pool2 in fulcrum
parser component (by default 1024, which was the threshold) in
fulcrumcomponentConfiguration.xml.
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 15.01.2021 09:49
Betreff: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi Georg,
On 13.01.21 17:40, Georg Kallidis wrote:
> - override parameters is only applied when mapping from URL, but not the
> other way around. This might be as expected, as "simpleurling" reads
from
> the provided parameters and if implicit parameter are set might not
allow
> to override a value, as this is the defined matcher. As a result
override
> parameter is asymmetric and not applied when creating the url
(mapToURL),
> but only when "reading" from it (mapFromURL). Ignore parameters take
> precedence over all others.
Yes, this is intentional. Overriding parameters is supposed to be used
when parameters are delivered that do not fit into the application
(anymore). The use-case is deprecation of an URL parameter that was
published before, for example.
> - Ignore-parameters in class URLMapentry is a Map, although only the
keys
> are used, might be better an array, but for sake of simplicity having to
> care for only one XmlAdapter, this is not necessarily required.
This is not necessarily the case. You may want to ignore a certain
key-value pair only, for example.
> - This works still in Java 16, but we should be aware of this:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.turbine.services.urlmapper.TurbineURLMapperService to method
> java.util.regex.Pattern.namedGroups()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.turbine.services.urlmapper.TurbineURLMapperService
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future
release
Yes. I'll need to think about this again. Too bad that the method
exists, but is private.
> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).
I stumbled across this before. The may be something wrong with the pool
handling of parsers. In my case, I got pool depletion with only local
testing. Very strange.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).
I stumbled across this before. The may be something wrong with the pool
handling of parsers. In my case, I got pool depletion with only local
testing. Very strange.
I fixed it by adjusting property max-total for fulcrum pool2 in fulcrum
parser component (by default 1024, which was the threshold) in
fulcrumcomponentConfiguration.xml.
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 15.01.2021 09:49
Betreff: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi Georg,
On 13.01.21 17:40, Georg Kallidis wrote:
> - override parameters is only applied when mapping from URL, but not the
> other way around. This might be as expected, as "simpleurling" reads
from
> the provided parameters and if implicit parameter are set might not
allow
> to override a value, as this is the defined matcher. As a result
override
> parameter is asymmetric and not applied when creating the url
(mapToURL),
> but only when "reading" from it (mapFromURL). Ignore parameters take
> precedence over all others.
Yes, this is intentional. Overriding parameters is supposed to be used
when parameters are delivered that do not fit into the application
(anymore). The use-case is deprecation of an URL parameter that was
published before, for example.
> - Ignore-parameters in class URLMapentry is a Map, although only the
keys
> are used, might be better an array, but for sake of simplicity having to
> care for only one XmlAdapter, this is not necessarily required.
This is not necessarily the case. You may want to ignore a certain
key-value pair only, for example.
> - This works still in Java 16, but we should be aware of this:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.turbine.services.urlmapper.TurbineURLMapperService to method
> java.util.regex.Pattern.namedGroups()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.turbine.services.urlmapper.TurbineURLMapperService
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future
release
Yes. I'll need to think about this again. Too bad that the method
exists, but is private.
> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).
I stumbled across this before. The may be something wrong with the pool
handling of parsers. In my case, I got pool depletion with only local
testing. Very strange.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Georg,
On 13.01.21 17:40, Georg Kallidis wrote:
> - override parameters is only applied when mapping from URL, but not the
> other way around. This might be as expected, as "simpleurling" reads from
> the provided parameters and if implicit parameter are set might not allow
> to override a value, as this is the defined matcher. As a result override
> parameter is asymmetric and not applied when creating the url (mapToURL),
> but only when "reading" from it (mapFromURL). Ignore parameters take
> precedence over all others.
Yes, this is intentional. Overriding parameters is supposed to be used
when parameters are delivered that do not fit into the application
(anymore). The use-case is deprecation of an URL parameter that was
published before, for example.
> - Ignore-parameters in class URLMapentry is a Map, although only the keys
> are used, might be better an array, but for sake of simplicity having to
> care for only one XmlAdapter, this is not necessarily required.
This is not necessarily the case. You may want to ignore a certain
key-value pair only, for example.
> - This works still in Java 16, but we should be aware of this:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.turbine.services.urlmapper.TurbineURLMapperService to method
> java.util.regex.Pattern.namedGroups()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.turbine.services.urlmapper.TurbineURLMapperService
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
Yes. I'll need to think about this again. Too bad that the method
exists, but is private.
> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).
I stumbled across this before. The may be something wrong with the pool
handling of parsers. In my case, I got pool depletion with only local
testing. Very strange.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/ -
about yaml
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
yes, the problem is that although commons configuration does implement
yaml style, it's intention is "configuration", which is very similar like
reading single entries (line by line) in property style - not
mapping/deserializing it into a class.
This was done here for the url mapper quite easily, as the mapping classes
already existed. Another advange was, that in the map patterns the xml
entity escaping could be removed, which makes them more readable...
But it was kind of an exercise/showcase.
Using it (e.g. in a fulcrum component) would imply a different mechanism
than now: Dropping the commons configuration and instead mapping the yml
file to a mapper class, where the configuration assignments would take
place or could be retrieved. This is just a thought about, how this might
be used at more places. May be the intake fulcrum component would be the
best candidate, as there already xml mapper classes are provided ...
Generally I think using yaml does lower the entry bar level to use a
software project (i.e. Turbine) and might even what "newcomers" expect. If
it could be done (as in this case) with very little effort, I think we
could afford to provide it (at least as an optional feature, which it's
still).
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 15.01.2021 10:13
Betreff: Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Hi Georg,
On 13.01.21 17:40, Georg Kallidis wrote:
> I just already updated the branch adding some tests (and one peformance
> test) and a yaml-configuration option (using the jackson library).
I like the YAML configuration approach. It looks much cleaner than the
chatty XML file.
We don't have this configuration format anywhere else, however. That
makes three different config formats within Turbine: properties, xml and
yaml. Looks clumsy to me.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Georg,
On 13.01.21 17:40, Georg Kallidis wrote:
> I just already updated the branch adding some tests (and one peformance
> test) and a yaml-configuration option (using the jackson library).
I like the YAML configuration approach. It looks much cleaner than the
chatty XML file.
We don't have this configuration format anywhere else, however. That
makes three different config formats within Turbine: properties, xml and
yaml. Looks clumsy to me.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Hi Thomas,
I just already updated the branch adding some tests (and one peformance
test) and a yaml-configuration option (using the jackson library).
My considerations are:
- override parameters is only applied when mapping from URL, but not the
other way around. This might be as expected, as "simpleurling" reads from
the provided parameters and if implicit parameter are set might not allow
to override a value, as this is the defined matcher. As a result override
parameter is asymmetric and not applied when creating the url (mapToURL),
but only when "reading" from it (mapFromURL). Ignore parameters take
precedence over all others.
- I made the following small change: if calling mapToUrl more than once, I
think it would be nice to be idempotent - to get the same mapped link back
again (MappedTemplateLink will be as application tool in a velocity
context) - might be relevant if used in velocity context more than once.
- Ignore-parameters in class URLMapentry is a Map, although only the keys
are used, might be better an array, but for sake of simplicity having to
care for only one XmlAdapter, this is not necessarily required.
- This works still in Java 16, but we should be aware of this:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.turbine.services.urlmapper.TurbineURLMapperService to method
java.util.regex.Pattern.namedGroups()
WARNING: Please consider reporting this to the maintainers of
org.apache.turbine.services.urlmapper.TurbineURLMapperService
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
And a simple question mark let's me think about what it does mean:
(?<contextPath>\w+) and placeholders . Is it a valid pattern ..
actually it's a pattern, if the entities are converted (< to <, and
> to >), which are only there due to the fact that it's definition is
xml wrapped. This is kind of a "marker" character as the question mark is
masked (as the round bracket brackets) in the (meta) pattern, which reads
this map pattern = namedGroupsPattern (where the group match is of course
done as well).
I think, we should merge it with the trunk.
The performance penalty when including it into the pipeline and in the
velocity templates as application tool seems to be tolerable (but my
performance test does not succeed with more than 1000 calls and I could
not find the reason behind yet though ..).
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 05.01.2021 16:27
Betreff: Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
On 05.01.21 15:50, tv@apache.org 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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Need some help: was: svn commit: r1885148 -
/turbine/core/branches/URLMapperService/
Posted by Thomas Vandahl <tv...@apache.org>.
On 05.01.21 15:50, tv@apache.org 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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org