Since I'd like the number of panels to be configurable by the page
building programmer, having a set number of @Components in my TabGroup
will not work. I've found a workaround for now:
<t:tabgroup>
<div t:type="tabnavigation" t:id="nav" t:panels="stuff1, stuff2,
stuff3" />
<t:tabpanel t:id="stuff1" elementName="div">
<p>This is stuff 1</p>
</t:tabpanel>
<div t:type="tabpanel" t:id="stuff2">
<p>This is stuff 2</p>
</div>
<t:tabpanel t:id="stuff3">
<p>This is stuff 3</p>
</t:tabpanel>
</t:tabgroup>
I've got the navigation working. It's functional. It's just way uglier
than I had hoped. If only there was a way to get those ids dynamically
instead of hardwiring them in the t:panels attribute...
As imperfect as it is, I'll probably post the code after I've tinkered
with the capabilities a little bit.
Thanks all.
On 7/31/07, Nick Westgate <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
