Title: RE: [Tapestry-developer] multi-value contexts for Direct components

Thanks. I guess I'm looking for the context-binding that allows multiple values in-place which you mentioned.

The reason I wanted this is because we have trying been to minimize the amount of java code needed to do things. Our framework works with List and Maps that are generated dynamically so we don't need to write much java code for specific pages. It goes against the grain to have to write a method that packages two parameters together since it means we need to 'hard-code' property names into the java class. Up until now we have been able to keep property name information exclusively in the component specifications.

No problem though, we can just bite the bullet and write some java.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 11:29 AM
To: Phil Surette
Cc: Tapestry Developer (E-mail)
Subject: Re: [Tapestry-developer] multi-value contexts for Direct
components


The Direct component is pretty flexible with its context
parameter.  The value bound to the parameter can be a
single String, and array of Strings, a Collection of
Strings or an Iterator (of Strings).  Please check the
class documentation.

In my code, when I need to put multiple values into the
context (which is fairly rare ... see note at end), I
create a method that assembles the values as a list. 
This is a common Tapestry pattern ... the controller
object (the Java object for the component) massaging or
otherwise brokering data for the components it contains.

I have thought about creating a <context-binding> that
would allow you to build the context in-place (it would
be a list of bindings).  Haven't gone anywhere with
that, as yet .. it hasn't been a priority.

Why You Rarely Need Multiple Values

Most of the time, the need to encode lots and lots of
parameters into the URL is caused by the necessity of
encoding dispatch infomation with the actual parameter
information.  In some ways, a URL is like a method
invocation; part of the URL identifies an object or
component, part identifies an operation, the rest are
parameters to that operation.

In Tapestry terms, the URL identifies a service and
service context ... that effectively identifies the
component and operation.  The context becomes the
parameters to that operation.  Tapestry does all the
work of encoding the service and service context.

For example, say you have a page with three links.  Each
links should trigger a different bit of behavior, i.e.,
a different method.

In Struts/JSP, you have to create a servlet or action
and define parameters to identify which of the three
behaviors to trigger.  Your servlet has to extract a
parameter and dispatch to the correct method based on
its value.


In Tapestry, you define three listener methods, and
create three instance of Direct, each bound to the
appropriate listener method.  That's it.

A Side Note About Robustness

Tapestry will detect if you reference an unknown
component (not likely, since it builds the URL) or an
unknown listener method ... you'll get a screenful of
exception page to help you understand what you, the
developer, have done wrong.  In a Struts/JSP solution,
error cases are your reponsibility ... not just to
correct, but to identify and report.



--
[EMAIL PROTECTED]

http://tapestry.sf.net
> How do you pass multiple values to a Direct's context?
>
> I've tried each of the following but in both cases the corresponding
> editFile method gets only one value.
>
>   <component id="editFile" type="Direct">
>     <binding name="listener" property-path="listeners.editFile"/>
>     <binding name="context" property-path="components.files.value.id"/>
>     <binding name="context" property-path="profile.id"/>
>   </component>
>
>   <component id="editFile" type="Direct">
>     <binding name="listener" property-path="listeners.editFile"/>
>     <binding name="context"
> property-path="components.files.value.id,profile.id"/>
>   </component>
>
> re: brief description of how we're using tapestry, I'm not sure how much I
> can say, will get back to you when possible.

Reply via email to