Hi Ákos, Try to think of a listener not as the target of a link, but as the "behavior behind" the link. Likewise a page's class is not a layer between a template and a another view, think of it as part of the template. The point I'm trying to make is that within Tapestry, the typical semantics of a HTML link do not apply (well, they do, but only "at and below" the level of a Tapestry-service).
How do you avoid duplication of behavior (like form validation) then? You either develop a component that adds the desired behavior (by combining existing components, if possible), or you create a generalized abstraction and put it into the framework itself. Validation, for example, can and should be handled by Tapestry's validation framework as a "behavior" of the Form component. Some additional observations: 1. Disclaimer: I could be totally wrong in how I understand this ;-) 2. the typical HTML semantics of a link are split up into the *Link components. The only thing that's not available out-of-the-box is a link-component that passes parameters to another page like you would in a PHP-application using the query string. Using the POV described above, passing the parameters is part of the behavior of the link. putting it all together: In my opinion, in typical Tapestry-fashion, you could easily develop a component that uses a bit of introspection to pass a list of parameters to a page and then activate a target page, thus abstracting the behavior into a component (and getting the listener implementation out of your page class). I hope this helps... best regards from Germany, Jonas PS: I find that the more we apply dependency injection and component-based development, the less OOP-principles apply, because there's not a real inheritance tree. Instead, behavior is "composed" by assembling different components/services. The bad thing with Tapestry 4.x is that it still depends a bit too much on using base classes to add "framework behavior" to *your* code. As far as I know, Howard is working on solving this with Tapestry 5.0. In principle, a shared base class for your pages would be another possible way of solving the problem, but it doesn't fit philosophically. PSS: You might know that already, but implementation-wise you can forgo the injection of the page and look it up using IRequestCycle.getPage(...). On 12/2/06, Ákos Maróy <[EMAIL PROTECTED]> wrote:
Hi, I have a question about listener semantics in Tapestry, about how one could achieve a simple usage semantics, when the target of a link or a form is a different page / component, than the invoker. The current typical usage for listeners in Tapestry is that the listener would be in the same page / component, as source of invocation (the form, link, etc.) This pattern in encouraged by the listener: binding as well.
[...] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
