Hi Todd.
The documentation is not exactly clear on this topic, so I'm not sure
whether that or the implementation is incomplete ...
The docs say:
"Components inside another components template are called embedded components."
Whereas the implementation WRT getEmbeddedComponentIds() is:
"Components DECLARED in component's CLASS are called embedded components."
You can get the list of "embedded components" if:
1- the TabGroup component has a separate HTML template
TabGroup.html:
<t:tabnavigation />
<t:tabpanel t:id="step1">
...
2- the TabGroup component Java file uses @Component to "embed" them
TabGroup.java:
...
@Component
private TabPanel step1;
I realize this is not quite what you want, but I hope it helps.
Cheers,
Nick.
Todd Orr wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
