Transitions

[Mindbridge <mi...@yahoo.com>]

Hi guys,

I'd like to present some ideas for developments in Tapestry. We have been discussing them with Tsvetelin for a while and we have clear ideas as to how they can be integrated in the framework, but we will initially present the ideas only conceptually in an attempt to keep the discussion away from its implementation at the moment and blurring it with details :). Let's see if the ideas make sense first.

Since there are quite a few things, I will split the descriptions into several emails. 


TRANSITIONS

The way web applications typically operate at the moment is to present a page, wait for the user to perform some actions, then activate another page depending on the actions of the user. In a sense this is a state machine, albeit a rather complex one.

Let's call this going from one page to another a "go-to" transition. In those transitions we do not remember where we came from, we only care where we are at the moment. Those are the predominant transitions that occur in a web application right now.

Now let's consider a simple "Are you sure?" page that asks the user whether he really would like to perform the action that he has selected. This page may be activated from a number of places (when deleting an item from a list, when about to send email, etc.) and upon completion it must go back to where it was invoked and return a result (ok or cancel). There is an obvious analogy to that process in the programming world -- invoking a function. Thus, let's name this process a "call" transition and the set of pages that we call into a 'unit' (to use Geoff's naming).

Web frameworks do not normally have built-in support for "call" transitions. The reason is that this is relatively easily implemented in the simpler cases. In Tapestry, for example, you would have a persistent property in the "Are you sure?" page that will contain the name of the page where you would have to return once the user responds. This is passed to the page when it is activated from the place it is invoked.

Unfortunately this approach is limited and does not work in the general case for the following reasons:

    - The 'unit' may be called recursively. Let's say you call A. It can then call B, which could then call A again. When using the approach above you would know where to go back in the latter transition, but you would lose this information about the first one. A 'stack' is necessary to remember who has been invoked and by whom (cf. functions).

    - The 'unit' may be more complex and contain a set of several pages. You should theoretically be able to easily 'return' from any of these pages.

    - The infamous Back and Refresh buttons that users like to use a lot may cause havoc in the organization of the application. For example, X calls A, which calls B, which calls A again. Instead of responding to what he sees, the user presses 'Back' until he reaches the first A and clicks on a button there. This is a 'check-mate' for simpler schemes. They would perform improper actions unrelated to what the user sees on screen at that point and return you to B rather than X. In most cases even the simplest user actions involving 'call' transitions and the Back button are problematic without a special scheme for handling that. 


Should the framework support 'call' transitions, essentially allowing the Web UI equivalent of functions?

The big problem is this: whether one likes it or not, 'call' transitions cannot really be avoided in more complex applications. The developers may try to work around them by rearranging the interface, but there are always things like the 'Are you sure?' page above that lend themselves naturally to the 'call' approach and would require a lot of copy-paste (at least) to work around that. Even so, people are rarely fully protected against the Back button issues described above.

Our experience: A long time ago we developed a Stack component (written by Tsvetelin) that allows something like what was described above. We did not intend to use it a lot initially, but nowadays it pops up regularly in the UIs we develop. Basically, when you have a new tool in your toolbox, you start using the actions that this tool allows far more frequently. Over the months this component has improved greatly, adding handling for the Back button, etc. Nevertheless, it is clear that it cannot provide everything necessary -- support from the framework proper is sorely needed. What's more, it is natural to have this support there, in the same way that programming languages have support for functions -- you can do far more complex stuff much more easily. The fact that this could make Tapestry far better and more usable than the competition is just an additional perk :)


Before I go further, do you think this needs to be considered? 


Best regards,
-mb

Re: Transitions

[Geoff Longman <gl...@intelligentworks.com>]

I'm interested. Would like to hear more..

Geoff


----- Original Message -----
From: "Mindbridge" <mi...@yahoo.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Sunday, September 21, 2003 7:40 AM
Subject: Transitions


Hi guys,

I'd like to present some ideas for developments in Tapestry. We have been
discussing them with Tsvetelin for a while and we have clear ideas as to how
they can be integrated in the framework, but we will initially present the
ideas only conceptually in an attempt to keep the discussion away from its
implementation at the moment and blurring it with details :). Let's see if
the ideas make sense first.

Since there are quite a few things, I will split the descriptions into
several emails.


TRANSITIONS

The way web applications typically operate at the moment is to present a
page, wait for the user to perform some actions, then activate another page
depending on the actions of the user. In a sense this is a state machine,
albeit a rather complex one.

Let's call this going from one page to another a "go-to" transition. In
those transitions we do not remember where we came from, we only care where
we are at the moment. Those are the predominant transitions that occur in a
web application right now.

Now let's consider a simple "Are you sure?" page that asks the user whether
he really would like to perform the action that he has selected. This page
may be activated from a number of places (when deleting an item from a list,
when about to send email, etc.) and upon completion it must go back to where
it was invoked and return a result (ok or cancel). There is an obvious
analogy to that process in the programming world -- invoking a function.
Thus, let's name this process a "call" transition and the set of pages that
we call into a 'unit' (to use Geoff's naming).

Web frameworks do not normally have built-in support for "call" transitions.
The reason is that this is relatively easily implemented in the simpler
cases. In Tapestry, for example, you would have a persistent property in the
"Are you sure?" page that will contain the name of the page where you would
have to return once the user responds. This is passed to the page when it is
activated from the place it is invoked.

Unfortunately this approach is limited and does not work in the general case
for the following reasons:

    - The 'unit' may be called recursively. Let's say you call A. It can
then call B, which could then call A again. When using the approach above
you would know where to go back in the latter transition, but you would lose
this information about the first one. A 'stack' is necessary to remember who
has been invoked and by whom (cf. functions).

    - The 'unit' may be more complex and contain a set of several pages. You
should theoretically be able to easily 'return' from any of these pages.

    - The infamous Back and Refresh buttons that users like to use a lot may
cause havoc in the organization of the application. For example, X calls A,
which calls B, which calls A again. Instead of responding to what he sees,
the user presses 'Back' until he reaches the first A and clicks on a button
there. This is a 'check-mate' for simpler schemes. They would perform
improper actions unrelated to what the user sees on screen at that point and
return you to B rather than X. In most cases even the simplest user actions
involving 'call' transitions and the Back button are problematic without a
special scheme for handling that.


Should the framework support 'call' transitions, essentially allowing the
Web UI equivalent of functions?

The big problem is this: whether one likes it or not, 'call' transitions
cannot really be avoided in more complex applications. The developers may
try to work around them by rearranging the interface, but there are always
things like the 'Are you sure?' page above that lend themselves naturally to
the 'call' approach and would require a lot of copy-paste (at least) to work
around that. Even so, people are rarely fully protected against the Back
button issues described above.

Our experience: A long time ago we developed a Stack component (written by
Tsvetelin) that allows something like what was described above. We did not
intend to use it a lot initially, but nowadays it pops up regularly in the
UIs we develop. Basically, when you have a new tool in your toolbox, you
start using the actions that this tool allows far more frequently. Over the
months this component has improved greatly, adding handling for the Back
button, etc. Nevertheless, it is clear that it cannot provide everything
necessary -- support from the framework proper is sorely needed. What's
more, it is natural to have this support there, in the same way that
programming languages have support for functions -- you can do far more
complex stuff much more easily. The fact that this could make Tapestry far
better and more usable than the competition is just an additional perk :)


Before I go further, do you think this needs to be considered?


Best regards,
-mb


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Transitions

[Harish Krishnaswamy <hk...@comcast.net>]

Page workflow is certainly an attractive feature, I think. I am 
interested in hearing your solution.

-Harish

Mindbridge wrote:

>Hi guys,
>
>I'd like to present some ideas for developments in Tapestry. We have been discussing them with Tsvetelin for a while and we have clear ideas as to how they can be integrated in the framework, but we will initially present the ideas only conceptually in an attempt to keep the discussion away from its implementation at the moment and blurring it with details :). Let's see if the ideas make sense first.
>
>Since there are quite a few things, I will split the descriptions into several emails. 
>
>
>TRANSITIONS
>
>The way web applications typically operate at the moment is to present a page, wait for the user to perform some actions, then activate another page depending on the actions of the user. In a sense this is a state machine, albeit a rather complex one.
>
>Let's call this going from one page to another a "go-to" transition. In those transitions we do not remember where we came from, we only care where we are at the moment. Those are the predominant transitions that occur in a web application right now.
>
>Now let's consider a simple "Are you sure?" page that asks the user whether he really would like to perform the action that he has selected. This page may be activated from a number of places (when deleting an item from a list, when about to send email, etc.) and upon completion it must go back to where it was invoked and return a result (ok or cancel). There is an obvious analogy to that process in the programming world -- invoking a function. Thus, let's name this process a "call" transition and the set of pages that we call into a 'unit' (to use Geoff's naming).
>
>Web frameworks do not normally have built-in support for "call" transitions. The reason is that this is relatively easily implemented in the simpler cases. In Tapestry, for example, you would have a persistent property in the "Are you sure?" page that will contain the name of the page where you would have to return once the user responds. This is passed to the page when it is activated from the place it is invoked.
>
>Unfortunately this approach is limited and does not work in the general case for the following reasons:
>
>    - The 'unit' may be called recursively. Let's say you call A. It can then call B, which could then call A again. When using the approach above you would know where to go back in the latter transition, but you would lose this information about the first one. A 'stack' is necessary to remember who has been invoked and by whom (cf. functions).
>
>    - The 'unit' may be more complex and contain a set of several pages. You should theoretically be able to easily 'return' from any of these pages.
>
>    - The infamous Back and Refresh buttons that users like to use a lot may cause havoc in the organization of the application. For example, X calls A, which calls B, which calls A again. Instead of responding to what he sees, the user presses 'Back' until he reaches the first A and clicks on a button there. This is a 'check-mate' for simpler schemes. They would perform improper actions unrelated to what the user sees on screen at that point and return you to B rather than X. In most cases even the simplest user actions involving 'call' transitions and the Back button are problematic without a special scheme for handling that. 
>
>
>Should the framework support 'call' transitions, essentially allowing the Web UI equivalent of functions?
>
>The big problem is this: whether one likes it or not, 'call' transitions cannot really be avoided in more complex applications. The developers may try to work around them by rearranging the interface, but there are always things like the 'Are you sure?' page above that lend themselves naturally to the 'call' approach and would require a lot of copy-paste (at least) to work around that. Even so, people are rarely fully protected against the Back button issues described above.
>
>Our experience: A long time ago we developed a Stack component (written by Tsvetelin) that allows something like what was described above. We did not intend to use it a lot initially, but nowadays it pops up regularly in the UIs we develop. Basically, when you have a new tool in your toolbox, you start using the actions that this tool allows far more frequently. Over the months this component has improved greatly, adding handling for the Back button, etc. Nevertheless, it is clear that it cannot provide everything necessary -- support from the framework proper is sorely needed. What's more, it is natural to have this support there, in the same way that programming languages have support for functions -- you can do far more complex stuff much more easily. The fact that this could make Tapestry far better and more usable than the competition is just an additional perk :)
>
>
>Before I go further, do you think this needs to be considered? 
>
>
>Best regards,
>-mb
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Transitions

[Richard Lewis-Shell <rl...@mac.com>]

We've also developed a 'transition' framework for use with Tapestry that 
solves some (but not all) of the things you mentioned, and some that you 
haven't (eg. using a page more than once at a time), so I am also very 
interested to see what you've got/what you are thinking...

R

Mindbridge wrote:
> Hi guys,
> 
> I'd like to present some ideas for developments in Tapestry. We have been discussing them with Tsvetelin for a while and we have clear ideas as to how they can be integrated in the framework, but we will initially present the ideas only conceptually in an attempt to keep the discussion away from its implementation at the moment and blurring it with details :). Let's see if the ideas make sense first.
> 
> Since there are quite a few things, I will split the descriptions into several emails. 
> 
> 
> TRANSITIONS
> 
> The way web applications typically operate at the moment is to present a page, wait for the user to perform some actions, then activate another page depending on the actions of the user. In a sense this is a state machine, albeit a rather complex one.
> 
> Let's call this going from one page to another a "go-to" transition. In those transitions we do not remember where we came from, we only care where we are at the moment. Those are the predominant transitions that occur in a web application right now.
> 
> Now let's consider a simple "Are you sure?" page that asks the user whether he really would like to perform the action that he has selected. This page may be activated from a number of places (when deleting an item from a list, when about to send email, etc.) and upon completion it must go back to where it was invoked and return a result (ok or cancel). There is an obvious analogy to that process in the programming world -- invoking a function. Thus, let's name this process a "call" transition and the set of pages that we call into a 'unit' (to use Geoff's naming).
> 
> Web frameworks do not normally have built-in support for "call" transitions. The reason is that this is relatively easily implemented in the simpler cases. In Tapestry, for example, you would have a persistent property in the "Are you sure?" page that will contain the name of the page where you would have to return once the user responds. This is passed to the page when it is activated from the place it is invoked.
> 
> Unfortunately this approach is limited and does not work in the general case for the following reasons:
> 
>     - The 'unit' may be called recursively. Let's say you call A. It can then call B, which could then call A again. When using the approach above you would know where to go back in the latter transition, but you would lose this information about the first one. A 'stack' is necessary to remember who has been invoked and by whom (cf. functions).
> 
>     - The 'unit' may be more complex and contain a set of several pages. You should theoretically be able to easily 'return' from any of these pages.
> 
>     - The infamous Back and Refresh buttons that users like to use a lot may cause havoc in the organization of the application. For example, X calls A, which calls B, which calls A again. Instead of responding to what he sees, the user presses 'Back' until he reaches the first A and clicks on a button there. This is a 'check-mate' for simpler schemes. They would perform improper actions unrelated to what the user sees on screen at that point and return you to B rather than X. In most cases even the simplest user actions involving 'call' transitions and the Back button are problematic without a special scheme for handling that. 
> 
> 
> Should the framework support 'call' transitions, essentially allowing the Web UI equivalent of functions?
> 
> The big problem is this: whether one likes it or not, 'call' transitions cannot really be avoided in more complex applications. The developers may try to work around them by rearranging the interface, but there are always things like the 'Are you sure?' page above that lend themselves naturally to the 'call' approach and would require a lot of copy-paste (at least) to work around that. Even so, people are rarely fully protected against the Back button issues described above.
> 
> Our experience: A long time ago we developed a Stack component (written by Tsvetelin) that allows something like what was described above. We did not intend to use it a lot initially, but nowadays it pops up regularly in the UIs we develop. Basically, when you have a new tool in your toolbox, you start using the actions that this tool allows far more frequently. Over the months this component has improved greatly, adding handling for the Back button, etc. Nevertheless, it is clear that it cannot provide everything necessary -- support from the framework proper is sorely needed. What's more, it is natural to have this support there, in the same way that programming languages have support for functions -- you can do far more complex stuff much more easily. The fact that this could make Tapestry far better and more usable than the competition is just an additional perk :)
> 
> 
> Before I go further, do you think this needs to be considered? 
> 
> 
> Best regards,
> -mb
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

RE: Transitions

["Howard M. Lewis Ship" <hl...@comcast.net>]

I know integrating workflow has been a long-running desire of mine, so let's see what you got going.
Alas, I'm swamped with book rewrites at the moment.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Mindbridge [mailto:mindbridgeweb@yahoo.com] 
> Sent: Sunday, September 21, 2003 7:41 AM
> To: Tapestry development
> Subject: Transitions
> 
> 
> Hi guys,
> 
> I'd like to present some ideas for developments in Tapestry. 
> We have been discussing them with Tsvetelin for a while and 
> we have clear ideas as to how they can be integrated in the 
> framework, but we will initially present the ideas only 
> conceptually in an attempt to keep the discussion away from 
> its implementation at the moment and blurring it with details 
> :). Let's see if the ideas make sense first.
> 
> Since there are quite a few things, I will split the 
> descriptions into several emails. 
> 
> 
> TRANSITIONS
> 
> The way web applications typically operate at the moment is 
> to present a page, wait for the user to perform some actions, 
> then activate another page depending on the actions of the 
> user. In a sense this is a state machine, albeit a rather complex one.
> 
> Let's call this going from one page to another a "go-to" 
> transition. In those transitions we do not remember where we 
> came from, we only care where we are at the moment. Those are 
> the predominant transitions that occur in a web application right now.
> 
> Now let's consider a simple "Are you sure?" page that asks 
> the user whether he really would like to perform the action 
> that he has selected. This page may be activated from a 
> number of places (when deleting an item from a list, when 
> about to send email, etc.) and upon completion it must go 
> back to where it was invoked and return a result (ok or 
> cancel). There is an obvious analogy to that process in the 
> programming world -- invoking a function. Thus, let's name 
> this process a "call" transition and the set of pages that we 
> call into a 'unit' (to use Geoff's naming).
> 
> Web frameworks do not normally have built-in support for 
> "call" transitions. The reason is that this is relatively 
> easily implemented in the simpler cases. In Tapestry, for 
> example, you would have a persistent property in the "Are you 
> sure?" page that will contain the name of the page where you 
> would have to return once the user responds. This is passed 
> to the page when it is activated from the place it is invoked.
> 
> Unfortunately this approach is limited and does not work in 
> the general case for the following reasons:
> 
>     - The 'unit' may be called recursively. Let's say you 
> call A. It can then call B, which could then call A again. 
> When using the approach above you would know where to go back 
> in the latter transition, but you would lose this information 
> about the first one. A 'stack' is necessary to remember who 
> has been invoked and by whom (cf. functions).
> 
>     - The 'unit' may be more complex and contain a set of 
> several pages. You should theoretically be able to easily 
> 'return' from any of these pages.
> 
>     - The infamous Back and Refresh buttons that users like 
> to use a lot may cause havoc in the organization of the 
> application. For example, X calls A, which calls B, which 
> calls A again. Instead of responding to what he sees, the 
> user presses 'Back' until he reaches the first A and clicks 
> on a button there. This is a 'check-mate' for simpler 
> schemes. They would perform improper actions unrelated to 
> what the user sees on screen at that point and return you to 
> B rather than X. In most cases even the simplest user actions 
> involving 'call' transitions and the Back button are 
> problematic without a special scheme for handling that. 
> 
> 
> Should the framework support 'call' transitions, essentially 
> allowing the Web UI equivalent of functions?
> 
> The big problem is this: whether one likes it or not, 'call' 
> transitions cannot really be avoided in more complex 
> applications. The developers may try to work around them by 
> rearranging the interface, but there are always things like 
> the 'Are you sure?' page above that lend themselves naturally 
> to the 'call' approach and would require a lot of copy-paste 
> (at least) to work around that. Even so, people are rarely 
> fully protected against the Back button issues described above.
> 
> Our experience: A long time ago we developed a Stack 
> component (written by Tsvetelin) that allows something like 
> what was described above. We did not intend to use it a lot 
> initially, but nowadays it pops up regularly in the UIs we 
> develop. Basically, when you have a new tool in your toolbox, 
> you start using the actions that this tool allows far more 
> frequently. Over the months this component has improved 
> greatly, adding handling for the Back button, etc. 
> Nevertheless, it is clear that it cannot provide everything 
> necessary -- support from the framework proper is sorely 
> needed. What's more, it is natural to have this support 
> there, in the same way that programming languages have 
> support for functions -- you can do far more complex stuff 
> much more easily. The fact that this could make Tapestry far 
> better and more usable than the competition is just an 
> additional perk :)
> 
> 
> Before I go further, do you think this needs to be considered? 
> 
> 
> Best regards,
> -mb
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Transitions

[David Solis <ds...@legosoft.com.mx>]

How different is from Geoff's approach?

Regards

David

On Sunday, September 21, 2003, at 06:40  AM, Mindbridge wrote:

> Hi guys,
>
> I'd like to present some ideas for developments in Tapestry. We have 
> been discussing them with Tsvetelin for a while and we have clear 
> ideas as to how they can be integrated in the framework, but we will 
> initially present the ideas only conceptually in an attempt to keep 
> the discussion away from its implementation at the moment and blurring 
> it with details :). Let's see if the ideas make sense first.
>
> Since there are quite a few things, I will split the descriptions into 
> several emails.
>
>
> TRANSITIONS
>
> The way web applications typically operate at the moment is to present 
> a page, wait for the user to perform some actions, then activate 
> another page depending on the actions of the user. In a sense this is 
> a state machine, albeit a rather complex one.
>
> Let's call this going from one page to another a "go-to" transition. 
> In those transitions we do not remember where we came from, we only 
> care where we are at the moment. Those are the predominant transitions 
> that occur in a web application right now.
>
> Now let's consider a simple "Are you sure?" page that asks the user 
> whether he really would like to perform the action that he has 
> selected. This page may be activated from a number of places (when 
> deleting an item from a list, when about to send email, etc.) and upon 
> completion it must go back to where it was invoked and return a result 
> (ok or cancel). There is an obvious analogy to that process in the 
> programming world -- invoking a function. Thus, let's name this 
> process a "call" transition and the set of pages that we call into a 
> 'unit' (to use Geoff's naming).
>
> Web frameworks do not normally have built-in support for "call" 
> transitions. The reason is that this is relatively easily implemented 
> in the simpler cases. In Tapestry, for example, you would have a 
> persistent property in the "Are you sure?" page that will contain the 
> name of the page where you would have to return once the user 
> responds. This is passed to the page when it is activated from the 
> place it is invoked.
>
> Unfortunately this approach is limited and does not work in the 
> general case for the following reasons:
>
>     - The 'unit' may be called recursively. Let's say you call A. It 
> can then call B, which could then call A again. When using the 
> approach above you would know where to go back in the latter 
> transition, but you would lose this information about the first one. A 
> 'stack' is necessary to remember who has been invoked and by whom (cf. 
> functions).
>
>     - The 'unit' may be more complex and contain a set of several 
> pages. You should theoretically be able to easily 'return' from any of 
> these pages.
>
>     - The infamous Back and Refresh buttons that users like to use a 
> lot may cause havoc in the organization of the application. For 
> example, X calls A, which calls B, which calls A again. Instead of 
> responding to what he sees, the user presses 'Back' until he reaches 
> the first A and clicks on a button there. This is a 'check-mate' for 
> simpler schemes. They would perform improper actions unrelated to what 
> the user sees on screen at that point and return you to B rather than 
> X. In most cases even the simplest user actions involving 'call' 
> transitions and the Back button are problematic without a special 
> scheme for handling that.
>
>
> Should the framework support 'call' transitions, essentially allowing 
> the Web UI equivalent of functions?
>
> The big problem is this: whether one likes it or not, 'call' 
> transitions cannot really be avoided in more complex applications. The 
> developers may try to work around them by rearranging the interface, 
> but there are always things like the 'Are you sure?' page above that 
> lend themselves naturally to the 'call' approach and would require a 
> lot of copy-paste (at least) to work around that. Even so, people are 
> rarely fully protected against the Back button issues described above.
>
> Our experience: A long time ago we developed a Stack component 
> (written by Tsvetelin) that allows something like what was described 
> above. We did not intend to use it a lot initially, but nowadays it 
> pops up regularly in the UIs we develop. Basically, when you have a 
> new tool in your toolbox, you start using the actions that this tool 
> allows far more frequently. Over the months this component has 
> improved greatly, adding handling for the Back button, etc. 
> Nevertheless, it is clear that it cannot provide everything necessary 
> -- support from the framework proper is sorely needed. What's more, it 
> is natural to have this support there, in the same way that 
> programming languages have support for functions -- you can do far 
> more complex stuff much more easily. The fact that this could make 
> Tapestry far better and more usable than the competition is just an 
> additional perk :)
>
>
> Before I go further, do you think this needs to be considered?
>
>
> Best regards,
> -mb


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org