I absolutely agree that the components should have as loose coupling
as possible. However, from my testing on simple, non-form related,
nested components the components that render later cannot pass any
information to the components that render sooner.
Perhaps a solid example will better illustrate. I found the
TabComponent wiki tutorial to be too cumbersome. So, I started with
"how I want to use the component". From this I think I want to be able
to do the following:
<t:tabgroup t:id="wizard1">
<t:tabnavigation />
<t:tabpanel t:id="w1_step1">
<p>This is step 1</p>
</t:tabpanel>
<t:tabpanel t:id="w1_step2">
<p>This is step 2</p>
</t:tabpanel>
<t:tabpanel t:id="w1_step3">
<p>This is step 3</p>
</t:tabpanel>
</t:tabgroup>
I was able to easily control which tabpanel gets displayed by passing
a panelActivation status using environmental. That was easy enough.
So, for my next step I wanted the tabnavigation component to
automatically display the links for the tabs. Tabnavigation uses a
loop component to display a number of links from a private list. At
this point id will suffice as the text, etc. until I get comfortable.
Since any number of tabpanels can be added to the tabgroup I needed a
way to pass the information back to the tabnavigation. This is where I
found Environment to be deficient. It seems that no matter what
combination of phases of rendering I use I cannot get the data back to
the tabnavigation before it is finished rendering and therefore cannot
alter it's display.
This is when I decided I'd try to have the tabgroup gather information
about its contained components so that it can pass information between
the tabnavigation and tabpanel components. Alas, I was unable to do so
as (previously stated) tabgroup has no idea what it contains.
Any ideas?
On 7/31/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> The design as it stands exists to remove invisible and unwanted
> dependencies. Component names, ids, types and classes can change ... and
> yet, using Environmental or ASOs to communicate will stand up to many kinds
> of refactorings, large and small.
>
> Introducing the ability to create arbitrary linkages between components, by
> id, will make applications far less maintainable. Worse, you'll change
> component A and some seemingly unrelated component B will break.
>
> If component A is a container of component B, then an Environmental can be a
> bi-directional conduit of communication between them.
>
> The question is: on an action request (rather than during a render), how to
> Environmentals get set up, since Environmentals are typically linked to
> render phases. I've already struggled with this issue (i.e., Form needs to
> establish the FormSupport environmental as the components it encloses invoke
> their submit callbacks).
>
> On 7/31/07, Todd Orr <[EMAIL PROTECTED]> wrote:
> >
> > I've been running my debugger to try to determine what is available to
> > the components at various points during rendering. As far as I can see
> > there is very little information provided regarding what other
> > components exist anywhere else in the page. The only thing I can get
> > for sure is the Page. However, even drilling back down from that level
> > shows that the page doesn't even know what components are in it.
> >
> > I think this would be a valuable addition to T5. Environmental isn't
> > sufficient in many cases because you can only pass data one way using
> > this approach. It would be very useful to be able to traverse the
> > component graph at some point, maybe even before rendering, to setup
> > any objects that might require cooperation.
> >
> > Maybe something already exists and I'm missing it. If so, please fill me
> > in.
> >
> > On 7/30/07, Todd Orr <[EMAIL PROTECTED]> wrote:
> > > BTW _resources.getComponentModel().getEmbeddedComponentIds() would be
> > > really really useful if it didn't return an empty list every time
> > > during my testing. Is there any way for a component to know what it
> > > contains?
> > >
> > > On 7/30/07, Todd Orr <[EMAIL PROTECTED]> wrote:
> > > > I've found out how to pass data between components so long as it's
> > > > downstream. Is there a way to pass data from a component (B) that is
> > > > physically below another component (A) to component A?
> > > >
> > > > I've found that performing any data passing (per situation above)
> > > > during the RenderSetup, etc. methods using either ComponentResources
> > > > or Environment is useless since the previous components have already
> > > > finished rendering.
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
