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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
