Re: [ANNOUNCEMENT] tapestry-routing 0.0.1 released!

[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!

[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