You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2005/08/17 00:14:10 UTC

[DISCUSS] Deprecate the action service

I just saw another spat of user problems related to use of the action
service. I say "use", not "misuse" because, in my opinion, it can't be
used correctly.  The clever tricks for maintaining client and server
synchronization that have evolved in Tapestry 2.x - 4.0 just aren't
possible with the action service.

I would very much like to deprecate the action service and the
ActionLink component. Who out there is using it and why?

-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


Re: [DISCUSS] Deprecate the action service

Posted by Adam Czysciak <ad...@gmail.com>.
Howard Lewis Ship wrote:

> I would very much like to deprecate the action service and the
> ActionLink component. Who out there is using it and why?

I'm not too familiar with Tapestry yet, but I have over 2 years WebObjects
experience (still using it at work). For me, when I discovered Tapestry,
ActionLinks were quite natural migration step from WO actions.
Unfortunatelly, Tapestry handles the whole 'process' different way, and the
migration wasn't painless (problems with StaleLinkException :-) Afterall,
I'm trying to go for DirectLinks.

IMO the main bonus for ActionLinks are keeping the cursors up to date, so
there's no need to squeeze parameters. The whole thing was more
WebObject-ish to me with ActionLinks. So... "natural". But - this is all a
matter of way you think when you design. Also, the page properties
behaviour has been changed with T4 (it's not so WO-ish now, you have to
make properties persistent).

I think that once beginning the discussion, you should provide all the
differences between ActionLink and other links. Just to make it clear
(althought it's developer's list, so perhaps everyone here shall know it
perfectly). Who else can describe it better than you, Howard?

-- 
Greets,
  Adam Czysciak
  adam.czysciak@gmail.com


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


Re: [DISCUSS] Deprecate the action service

Posted by Harish Krishnaswamy <ha...@gmail.com>.
I have never used it either. So +1 to remove.

-Harish

On 8/18/05, Adam Greene <ag...@professionalopensource.ca> wrote:
> I have never found a use for it, as we can plainly see, it causes a great
> deal of confusion and problems.  I say remove it.
> 
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Tuesday, August 16, 2005 7:14 PM
> Subject: [DISCUSS] Deprecate the action service
> 
> 
> I just saw another spat of user problems related to use of the action
> service. I say "use", not "misuse" because, in my opinion, it can't be
> used correctly.  The clever tricks for maintaining client and server
> synchronization that have evolved in Tapestry 2.x - 4.0 just aren't
> possible with the action service.
> 
> I would very much like to deprecate the action service and the
> ActionLink component. Who out there is using it and why?
> 
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> 
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
>

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


Re: [DISCUSS] Deprecate the action service

Posted by Adam Greene <ag...@professionalopensource.ca>.
I have never found a use for it, as we can plainly see, it causes a great 
deal of confusion and problems.  I say remove it.

----- Original Message ----- 
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Tuesday, August 16, 2005 7:14 PM
Subject: [DISCUSS] Deprecate the action service


I just saw another spat of user problems related to use of the action
service. I say "use", not "misuse" because, in my opinion, it can't be
used correctly.  The clever tricks for maintaining client and server
synchronization that have evolved in Tapestry 2.x - 4.0 just aren't
possible with the action service.

I would very much like to deprecate the action service and the
ActionLink component. Who out there is using it and why?

-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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



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


Re: [DISCUSS] Deprecate the action service

Posted by Jonas Maurus <jo...@gmail.com>.
Howard Lewis Ship <hlship <at> gmail.com> writes:

> 
> Use a DirectLink component, and pass the id of the invoice as a
> listener parameter.
> 

For an invoice that was just created, the Id might not be known at that 
point, as the Invoice bean hasn't been serialized to the database. 
I find this solution (passing the bean to the next page) to be more 
intuitive, especially if the alternative requires me to serialize beans 
between pages.

I guess there are of course multiple work-arounds, these two are just 
the first ones to pop up in my head:

a) do a form submit instead of an ActionLink, possibly using Picasso's
LinkSubmit: This would work but feel like a kludge as it requires 
a Form component.
b) store the current invoice in the session by injecting a WebRequest 
instance: This would not work for stateless applications.

The current DirectLink documentation states: "This is used in cases where 
the ActionLink component can't be used (or is too inefficient)".

I'd go with -1 on removing ActionLink, but changing the documentation 
somewhat to make clear for what it can be used and what not (especially 
removing the above paragraph and make that the other way round, because 
I'd guess that the mentioned paragraph is a prime source of confusion).

What do you think?

Best regards from Regensburg, Germany,
Jonas

> On 8/18/05, Jonas Maurus <jonas.maurus <at> gmail.com> wrote:
> > Howard Lewis Ship <hlship <at> gmail.com> writes:
> > 
> > >
> > > I just saw another spat of user problems related to use of the 
> > > action service. I say "use", not "misuse" because, in my opinion,
> > > it can't be used correctly.  The clever tricks for maintaining 
> > > client and server synchronization that have evolved in 
> > > Tapestry 2.x - 4.0 just aren't possible with the action service.
> > >
> > > I would very much like to deprecate the action service and the
> > > ActionLink component. Who out there is using it and why?
> > >
> > 
> > I'm currently using the ActionLink component a lot in all my 
> > projects together with contrib:Table.
> > 
> > The typical use-case looks something like this:
> > 
> > Invoices.html
> > [...]
> > <td jwcid="viewLinkColumnValue">
> >   <a jwcid="view" href="../viewers/InvoiceViewer.html">
> >     <span key="list.viewinvoice">details</span>
> >   </a>
> > </td>
> > [...]
> > 
> > Invoices.page
> > [...]
> > <component id="invoiceTable" type="contrib:Table">
> >   <binding name="source" value="invoiceList" />
> >   <binding name="columns" value="literal:id,subject,total,
> >   viewLink,editLink" />
> >   <binding name="row" value="currentInvoice" />
> > </component>
> > 
> > <component id="view" type="ActionLink">
> >   <binding name="listener" value="listener:viewInvoice" />
> > </component>
> > [...]
> > 
> > Usually the ActionLink's listener then does something like this 
> > (Invoice being a persistent property of InvoiceViewer):
> > public IPage viewInvoice(IRequestCycle cycle) {
> >   InvoiceViewer iv = (InvoiceViewer)
> >                        cycle.getPage("viewers/InvoiceViewer");
> >   iv.setInvoice(getCurrentInvoice());
> >   return iv;
> > }
> > 
> > This pattern comes from contrib:Table's documentation. At least, 
> > should ActionLink be removed, alternatives have to be documented 
> > well before we're doing it, especially in places like contrib:Table, 
> > where the documentation makes explicit use of this component.
> > 
> > Still, I don't know enough about Tapestry's internals to know if it 
> > would be a good decision, but in any way, if it happens, it should 
> > happen now. As I've said before, it's better to make porting to 4.0 
> > a major pain and support 3.0 a little bit longer than making big 
> > changes between 4.0 and 4.1.
> > 
> > How would you solve the above problem without using ActionLink?
> > 
> > cheers,
> > Jonas
> > 



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


Re: [DISCUSS] Deprecate the action service

Posted by Howard Lewis Ship <hl...@gmail.com>.
Use a DirectLink component, and pass the id of the invoice as a
listener parameter.

On 8/18/05, Jonas Maurus <jo...@gmail.com> wrote:
> Howard Lewis Ship <hlship <at> gmail.com> writes:
> 
> >
> > I just saw another spat of user problems related to use of the action
> > service. I say "use", not "misuse" because, in my opinion, it can't be
> > used correctly.  The clever tricks for maintaining client and server
> > synchronization that have evolved in Tapestry 2.x - 4.0 just aren't
> > possible with the action service.
> >
> > I would very much like to deprecate the action service and the
> > ActionLink component. Who out there is using it and why?
> >
> 
> I'm currently using the ActionLink component a lot in all my projects together
> with contrib:Table.
> 
> The typical use-case looks something like this:
> 
> Invoices.html
> [...]
> <td jwcid="viewLinkColumnValue">
>   <a jwcid="view" href="../viewers/InvoiceViewer.html">
>     <span key="list.viewinvoice">details</span>
>   </a>
> </td>
> [...]
> 
> Invoices.page
> [...]
> <component id="invoiceTable" type="contrib:Table">
>   <binding name="source" value="invoiceList" />
>   <binding name="columns" value="literal:id,subject,total,viewLink,editLink" />
>   <binding name="row" value="currentInvoice" />
> </component>
> 
> <component id="view" type="ActionLink">
>   <binding name="listener" value="listener:viewInvoice" />
> </component>
> [...]
> 
> Usually the ActionLink's listener then does something like this (Invoice being a
> persistent property of InvoiceViewer):
> public IPage viewInvoice(IRequestCycle cycle) {
>   InvoiceViewer iv = (InvoiceViewer)cycle.getPage("viewers/InvoiceViewer");
>   iv.setInvoice(getCurrentInvoice());
>   return iv;
> }
> 
> This pattern comes from contrib:Table's documentation. At least, should
> ActionLink be removed, alternatives have to be documented well before we're
> doing it, especially in places like contrib:Table, where the documentation makes
> explicit use of this component.
> 
> Still, I don't know enough about Tapestry's internals to know if it would be a
> good decision, but in any way, if it happens, it should happen now. As I've said
> before, it's better to make porting to 4.0 a major pain and support 3.0 a little
> bit longer than making big changes between 4.0 and 4.1.
> 
> How would you solve the above problem without using ActionLink?
> 
> cheers,
> Jonas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


Re: [DISCUSS] Deprecate the action service

Posted by Jonas Maurus <jo...@gmail.com>.
Howard Lewis Ship <hlship <at> gmail.com> writes:

> 
> I just saw another spat of user problems related to use of the action
> service. I say "use", not "misuse" because, in my opinion, it can't be
> used correctly.  The clever tricks for maintaining client and server
> synchronization that have evolved in Tapestry 2.x - 4.0 just aren't
> possible with the action service.
> 
> I would very much like to deprecate the action service and the
> ActionLink component. Who out there is using it and why?
> 

I'm currently using the ActionLink component a lot in all my projects together
with contrib:Table.

The typical use-case looks something like this:

Invoices.html
[...]
<td jwcid="viewLinkColumnValue">
  <a jwcid="view" href="../viewers/InvoiceViewer.html">
    <span key="list.viewinvoice">details</span>
  </a>
</td>
[...]

Invoices.page
[...]
<component id="invoiceTable" type="contrib:Table">
  <binding name="source" value="invoiceList" />
  <binding name="columns" value="literal:id,subject,total,viewLink,editLink" />
  <binding name="row" value="currentInvoice" />
</component>

<component id="view" type="ActionLink">
  <binding name="listener" value="listener:viewInvoice" />
</component>
[...]

Usually the ActionLink's listener then does something like this (Invoice being a
persistent property of InvoiceViewer):
public IPage viewInvoice(IRequestCycle cycle) {
  InvoiceViewer iv = (InvoiceViewer)cycle.getPage("viewers/InvoiceViewer");
  iv.setInvoice(getCurrentInvoice());
  return iv;
}

This pattern comes from contrib:Table's documentation. At least, should
ActionLink be removed, alternatives have to be documented well before we're
doing it, especially in places like contrib:Table, where the documentation makes
explicit use of this component.

Still, I don't know enough about Tapestry's internals to know if it would be a
good decision, but in any way, if it happens, it should happen now. As I've said
before, it's better to make porting to 4.0 a major pain and support 3.0 a little
bit longer than making big changes between 4.0 and 4.1.

How would you solve the above problem without using ActionLink?

cheers,
Jonas


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