You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alejandro Scandroli <al...@gmail.com> on 2011/03/29 09:38:33 UTC
[ANNOUNCEMENT] tapestry-routing 0.0.1 released!
>From the same guys that brought you tapestry-exceptionpage,
tapestry-model, tapestry-resteasy, tapestry-security,
tynamo-federatedaccounts and other beautiful little modules, here
comes yet another beautiful little module called tapestry-routing.
In a nutshell, tapestry-routing allows you to provide your own custom
mapping between Tapestry pages and URLs.
Did you ever wanted to change the order of the path params in an URL?
now you can!
Let's say you have a page: pages.projects.Members which have 2
parameters in its activation context: (Long projectId, Long memberId)
and you want the URL for that page to look like /projects/1/members/1
Just add the @At annotation to you page, like this:
package ...pages.projects;
@At(" /projects/{0}/members/{1}")
public class Members {
void onActivate(Long projectId, Long memberId)
That's it!
tapestry-routing Dispatcher will take care of recognizing incoming
requests and dispatching the proper render request
tapestry-routing PageRenderLinkTransformer will do the rest of the
work, it will transform every Link for a page render request
formatting it according to your route rule.
We really need some feedback, so please give it a try:
http://tynamo.org/tapestry-routing+guide
Enjoy,
Tynamo Team
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Mon, Apr 4, 2011 at 10:17 AM, Alejandro Scandroli
<al...@gmail.com> wrote:
> Hi Howard, Thiago
>
>> How well does it handle a change to the @At annotation once the
>> application is loaded? Or the addition of new pages with @At
>> annotations?
>
> This first version doesn't handle either. But these features are next in line.
> http://jira.codehaus.org/browse/TYNAMO-88
> My first idea was to implement UpdateListener and then reload all the
> routes. Now, I'd think twice before doing that :D
> I don't know what would be a performant (does this word exists?)
> solution for this. Maybe trying to hook each Route object with an
> InvalidationListener, I don't know... but I promise to take a deeper
> look.
>
>>
>>> I hope I didn't come off as dismissive ... but I am curious about how
>>> other people approach these problems and whether they take in the big
>>> picture.
>>
>> I haven't thought much on different implementations for the same feature,
>> but the first thing I would think is URL rewriting (using LinkTransformer or
>> something else). Maybe this, in combination with a ComponentClassTransformer
>> (so the changes in the page class annotations could be picked at runtime and
>> maybe even avoid the class scanning completely) could be used to provide an
>> alternative implementation to tapestry-routing. Alejandro, am I right? :)
>>
>
> I did consider the ComponentClassTransformer but one of the main
> (hidden) features of the current implementation is that routes are
> overridable by actual Tapestry pages. I know most projects don't need
> such a feature but in Tynamo it's a MUST.
>
>> I'm beginning to move in the direction of providing a
>> solution that works for a non-clustered environment, with enough
>> information for a clustered override to be created if needed.
>
> EXCELLENT! I'll without hesitation use your implementation and ditch mine :D
> Could you please take into account that "hidden" feature I just mentioned.
>
>> We may
>> see something like duplicate form submission prevention based on this.
>>
>
> I'm sorry but I don't get this last sentence.
I've wanted Tapestry to include a system to prevent duplicate form
submissions ... that is, to handle the case where the user clicks the
submit button multiple times from impatience while the form is being
processed. The normal approach to this is that each form gets a
one-use token (recorded as hidden form data) so that Tapestry can
detect a repeat submission o the same form.
I've never implemented this in any version of Tapestry because there
isn't a simple way to coordinate the tokens across servers in a
cluster (without also mandating the use of server-side session).
However, the majority of Tapestry apps, even the biggest ones, are
running in non-clustered mode. So my thinking on this issue, and
similar ones, it to provide a basic implementation that (for example)
stores the tokens in memory, but design it in such a way that an
interested user could override a small portion of the overall solution
so as to support their cluster properly. How information gets shared
across a cluster is very implementation dependent and even application
specific; they may have JMS set up, or Terracotta, or something I
don't even know about.
But my main point is that Tapestry can provide the 90% solution, and
(via service overrides), allow a custom implementation for the 10%
that don't fit. I think that's very good.
>
>
> Cheers.
> Alejandro.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by Alejandro Scandroli <al...@gmail.com>.
Hi Howard, Thiago
> How well does it handle a change to the @At annotation once the
> application is loaded? Or the addition of new pages with @At
> annotations?
This first version doesn't handle either. But these features are next in line.
http://jira.codehaus.org/browse/TYNAMO-88
My first idea was to implement UpdateListener and then reload all the
routes. Now, I'd think twice before doing that :D
I don't know what would be a performant (does this word exists?)
solution for this. Maybe trying to hook each Route object with an
InvalidationListener, I don't know... but I promise to take a deeper
look.
>
>> I hope I didn't come off as dismissive ... but I am curious about how
>> other people approach these problems and whether they take in the big
>> picture.
>
> I haven't thought much on different implementations for the same feature,
> but the first thing I would think is URL rewriting (using LinkTransformer or
> something else). Maybe this, in combination with a ComponentClassTransformer
> (so the changes in the page class annotations could be picked at runtime and
> maybe even avoid the class scanning completely) could be used to provide an
> alternative implementation to tapestry-routing. Alejandro, am I right? :)
>
I did consider the ComponentClassTransformer but one of the main
(hidden) features of the current implementation is that routes are
overridable by actual Tapestry pages. I know most projects don't need
such a feature but in Tynamo it's a MUST.
> I'm beginning to move in the direction of providing a
> solution that works for a non-clustered environment, with enough
> information for a clustered override to be created if needed.
EXCELLENT! I'll without hesitation use your implementation and ditch mine :D
Could you please take into account that "hidden" feature I just mentioned.
> We may
> see something like duplicate form submission prevention based on this.
>
I'm sorry but I don't get this last sentence.
Cheers.
Alejandro.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 29 Mar 2011 19:36:18 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I hope I didn't come off as dismissive ... but I am curious about how
> other people approach these problems and whether they take in the big
> picture.
I haven't thought much on different implementations for the same feature,
but the first thing I would think is URL rewriting (using LinkTransformer
or something else). Maybe this, in combination with a
ComponentClassTransformer (so the changes in the page class annotations
could be picked at runtime and maybe even avoid the class scanning
completely) could be used to provide an alternative implementation to
tapestry-routing. Alejandro, am I right? :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by Howard Lewis Ship <hl...@gmail.com>.
How well does it handle a change to the @At annotation once the
application is loaded? Or the addition of new pages with @At
annotations?
I hope I didn't come off as dismissive ... but I am curious about how
other people approach these problems and whether they take in the big
picture. I'm beginning to move in the direction of providing a
solution that works for a non-clustered environment, with enough
information for a clustered override to be created if needed. We may
see something like duplicate form submission prevention based on this.
On Tue, Mar 29, 2011 at 3:20 PM, Alejandro Scandroli
<al...@gmail.com> wrote:
> You are absolutely right Howard. That's the case. All the pages are
> scanned at startup time to look for the @At annotation and to build
> the routes map.
> If you want to avoid the "scanning" phase you can, but you will need
> to contribute, one by one, all your @At annotated pages to the
> Dispatcher.
> I don't have any experiences with projects with hundreds of pages nor
> clustering, that's why I didn't take that into account. I'm using it
> and I took the time to sharing it because I thought it could be useful
> for some else, there is a lot of scenarios where having this level of
> customization in your URLs could be interesting even if we have to pay
> a little performance penalty. Of course there are scenarios where this
> shouldn't be used at all, for instance in a clustered environment. I
> will add these comments to the wiki so all users are warned.
>
> Cheers.
> Alejandro.
>
> On Tue, Mar 29, 2011 at 5:53 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> I've never put a feature such as this into Tapestry core, because it
>> seems to me that you have to, at start up, locate and load all page
>> classes to find the @At annotation (something I'd rather not do,
>> because a Tapestry application might have hundreds of pages, and I
>> don't want to pay that startup cost). Is that the case? If not, in a
>> cluster, how to you recognize the routing for a page that has not yet
>> been loaded?
>>
>> On Tue, Mar 29, 2011 at 12:38 AM, Alejandro Scandroli
>> <al...@gmail.com> wrote:
>>> From the same guys that brought you tapestry-exceptionpage,
>>> tapestry-model, tapestry-resteasy, tapestry-security,
>>> tynamo-federatedaccounts and other beautiful little modules, here
>>> comes yet another beautiful little module called tapestry-routing.
>>>
>>> In a nutshell, tapestry-routing allows you to provide your own custom
>>> mapping between Tapestry pages and URLs.
>>>
>>> Did you ever wanted to change the order of the path params in an URL?
>>> now you can!
>>>
>>> Let's say you have a page: pages.projects.Members which have 2
>>> parameters in its activation context: (Long projectId, Long memberId)
>>> and you want the URL for that page to look like /projects/1/members/1
>>> Just add the @At annotation to you page, like this:
>>>
>>> package ...pages.projects;
>>> @At(" /projects/{0}/members/{1}")
>>> public class Members {
>>> void onActivate(Long projectId, Long memberId)
>>>
>>> That's it!
>>> tapestry-routing Dispatcher will take care of recognizing incoming
>>> requests and dispatching the proper render request
>>> tapestry-routing PageRenderLinkTransformer will do the rest of the
>>> work, it will transform every Link for a page render request
>>> formatting it according to your route rule.
>>>
>>> We really need some feedback, so please give it a try:
>>> http://tynamo.org/tapestry-routing+guide
>>>
>>> Enjoy,
>>> Tynamo Team
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by Alejandro Scandroli <al...@gmail.com>.
You are absolutely right Howard. That's the case. All the pages are
scanned at startup time to look for the @At annotation and to build
the routes map.
If you want to avoid the "scanning" phase you can, but you will need
to contribute, one by one, all your @At annotated pages to the
Dispatcher.
I don't have any experiences with projects with hundreds of pages nor
clustering, that's why I didn't take that into account. I'm using it
and I took the time to sharing it because I thought it could be useful
for some else, there is a lot of scenarios where having this level of
customization in your URLs could be interesting even if we have to pay
a little performance penalty. Of course there are scenarios where this
shouldn't be used at all, for instance in a clustered environment. I
will add these comments to the wiki so all users are warned.
Cheers.
Alejandro.
On Tue, Mar 29, 2011 at 5:53 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've never put a feature such as this into Tapestry core, because it
> seems to me that you have to, at start up, locate and load all page
> classes to find the @At annotation (something I'd rather not do,
> because a Tapestry application might have hundreds of pages, and I
> don't want to pay that startup cost). Is that the case? If not, in a
> cluster, how to you recognize the routing for a page that has not yet
> been loaded?
>
> On Tue, Mar 29, 2011 at 12:38 AM, Alejandro Scandroli
> <al...@gmail.com> wrote:
>> From the same guys that brought you tapestry-exceptionpage,
>> tapestry-model, tapestry-resteasy, tapestry-security,
>> tynamo-federatedaccounts and other beautiful little modules, here
>> comes yet another beautiful little module called tapestry-routing.
>>
>> In a nutshell, tapestry-routing allows you to provide your own custom
>> mapping between Tapestry pages and URLs.
>>
>> Did you ever wanted to change the order of the path params in an URL?
>> now you can!
>>
>> Let's say you have a page: pages.projects.Members which have 2
>> parameters in its activation context: (Long projectId, Long memberId)
>> and you want the URL for that page to look like /projects/1/members/1
>> Just add the @At annotation to you page, like this:
>>
>> package ...pages.projects;
>> @At(" /projects/{0}/members/{1}")
>> public class Members {
>> void onActivate(Long projectId, Long memberId)
>>
>> That's it!
>> tapestry-routing Dispatcher will take care of recognizing incoming
>> requests and dispatching the proper render request
>> tapestry-routing PageRenderLinkTransformer will do the rest of the
>> work, it will transform every Link for a page render request
>> formatting it according to your route rule.
>>
>> We really need some feedback, so please give it a try:
>> http://tynamo.org/tapestry-routing+guide
>>
>> Enjoy,
>> Tynamo Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've never put a feature such as this into Tapestry core, because it
seems to me that you have to, at start up, locate and load all page
classes to find the @At annotation (something I'd rather not do,
because a Tapestry application might have hundreds of pages, and I
don't want to pay that startup cost). Is that the case? If not, in a
cluster, how to you recognize the routing for a page that has not yet
been loaded?
On Tue, Mar 29, 2011 at 12:38 AM, Alejandro Scandroli
<al...@gmail.com> wrote:
> From the same guys that brought you tapestry-exceptionpage,
> tapestry-model, tapestry-resteasy, tapestry-security,
> tynamo-federatedaccounts and other beautiful little modules, here
> comes yet another beautiful little module called tapestry-routing.
>
> In a nutshell, tapestry-routing allows you to provide your own custom
> mapping between Tapestry pages and URLs.
>
> Did you ever wanted to change the order of the path params in an URL?
> now you can!
>
> Let's say you have a page: pages.projects.Members which have 2
> parameters in its activation context: (Long projectId, Long memberId)
> and you want the URL for that page to look like /projects/1/members/1
> Just add the @At annotation to you page, like this:
>
> package ...pages.projects;
> @At(" /projects/{0}/members/{1}")
> public class Members {
> void onActivate(Long projectId, Long memberId)
>
> That's it!
> tapestry-routing Dispatcher will take care of recognizing incoming
> requests and dispatching the proper render request
> tapestry-routing PageRenderLinkTransformer will do the rest of the
> work, it will transform every Link for a page render request
> formatting it according to your route rule.
>
> We really need some feedback, so please give it a try:
> http://tynamo.org/tapestry-routing+guide
>
> Enjoy,
> Tynamo Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org