gaz jones wrote:
thats not _quite_ what i want though, as its not truly dynamic - thats
including a pre-defined component into the page, not generating a completely
dynamic one... if i have understood your suggestion, i would need to define
every component i ever might need in the jwc or using annotations...
From what get of your posts I can't understand what you mean by "not
truly dynamic".
You suggest substituting:
PageLink pageLink = new PageLink();
pageLink.page = "MyGreatPage";
getPage.addComponent(pageLink); // or something similar
in the renderComponent.
But this looks like an operation to *add* a component to the page, and
not to *render* it.
To add the component, you simply put it in the page template, in the
descriptor or through annotations.
And to me this way is better than adding through java code: it lets you
change the page composition without touching the compiled code.
If you need to create a component to "include" another component than
you do it the same way. If you think that this means not being dynamic,
you better consider what you need for a component to be actually *reusable*.
As I see it there are only in two cases:
1. The component knows its exact internal composition to depend on
expected behaviour, or
2. It should be totally independent of possible subcomponents.
And this is what you get with tapestry.
But maybe I misunderstood your question, and you should consider the
following.
The renderComponent code:
writer.begin("a");
ILink link = getPageService().getLink(true, "MyGreatPage");
writer.attribute("href", link.getURL());
writer.print("Go to my great page");
writer.end("a");
is only written once by the component's developer and the "MyGreatPage"
is actually parameterized.
As a user you only add the component to a page in the .jwc and use it in
the template, passing the destination page as a parameter.
And so you need not write any java code for the page or the component
you're using.
You only need to declare the components that you really make use of, in
the .jwc, and this is related to the considerations I previously made.
As for the rewind, it's just a different perspective from what you
described, and I agree that it takes a little effort to get into. But
the component pooling is a useful mean to reduce the application from
burdening the system, cause you need not create as many resources,
reusing existing ones, and that's what pooling exists for.
The difference is that you don't have a "global" page structure that you
could navigate to find subcomponents. But this too can be an advantage
since you decouple yourself from thinking in terms of how the components
are placed within the page. This really helps when you change the page's
composition in any way, without being forced to change the listener's
code to adapt to the new page layout.
Moreover you don't need to actually manage the iteration code to examine
dynamic lists of components. The framework creates the loop variable and
iterates through the list for you.
Ivano Pagano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
