I'm going over some documentation and I realized one of
the basic differences between Tapestry and "ordinary"
web development.
In the servlet/Struts world, the servlet or Action is,
effectively the page (and the JSP is just used to render
a response). The page becomes the focus of all activity
on the page. In some cases, these responsibilities are
split across several servlets or actions, but the
logical level is still true.
The servlet/action is actively involved in any behavior
on the page. This has two ramifications.
First: because the concept of "page" is mixed with the
concept of "request responder", it makes sense to talk
about "invoking a page" and passing "parameters" as
query parameters.
Second: it makes the creation and use of components
difficult because they compete with the page to be
the "request responder". The end result is some form of
kludge: either the page servlet/action must be extended
with specific knowledge of the "component", or
the "component" must be extended with some knowledge of
the page that contains it, either as a JSP or as
servlet/action.
By contrast, in Tapestry, a page is (largely) a passive
container of components, and it is the components that
are active.
This is why Tapestry pages don't have parameters; the
page isn't a "request responder", but some of the
components contained within it are. Thus it doesn't
make sense to talk about a page's parameters, since the
page can't really be referenced from another page in
that way.
And, since pages are also black box components, whose
internal construction is private, it doesn't make sense
for one page to directly reference components within
another page.
Intead, Tapestry follows a model where each page is
largely self contained. A URL may reference a component
on the page, and this will (via a listener) lead to end-
developer written, application-specific code. It is
only here where the barriers between pages are actually
broken down ... but that code is strongly typed and
developed inside an IDE.
.........................
That being said, you could simulate such a relationship
between pages as well.
Imagine creating a Direct on page A whose listener did
the following:
public void activateB(IRequestCycle cycle)
{
String[] parameters = cycle.getServiceParameters();
PageB pageB = (PageB)cycle.getPage("B");
// Use the parameters to set a bunch of JavaBean
// properties on pageB.
cycle.setPage(pageB);
}
This construct accomplishes pretty much what a JSP
developer means when they say "invokes a page with
parameters".
Now, if you do something like this a lot, the next step
is to create a component out of it. What if, instead of
specifically PageB, it could be any page. And what if a
list of properties and values (lets assume all the
properties to be set are strings) are passed in.
Now the listener looks like:
public void activate(IRequestCycle cycle)
{
String[] parameters = cycle.getServiceParameters();
String pageName = parameters[0];
IPage targetPage = cycle.getPage(pageName);
PropertyHelper helper = PropertyHelper.forInstance
(targetPage);
for (int i = 1; i < parameters.length;. i+= 2)
{
String propertyName = parameters[i];
String value = parameters[i + 1];
helper.set(targetPage, propertyName, value);
}
cycle.setPage(targetPage);
}
What's interesting is that this listener doesn't have to
go in PageA anymore, it could go anywhere.
So that means you could create a reusable component that
uses a Direct, and provides its own listener. The
component would be responsible for creating the Direct's
context (which eventually becomes the service
parameters).
This context would be based on component parameters; one
formal parameter to specify the name of the target page,
and some number of informal parameters that specify the
property/value pairs to be encoded into the URL.
I'm not going to try and spew all that out of the top of
my head ... I just want to put it out there that
Tapestry doesn't wall you in; in some ways, what
Tapestry provides is still just a foundation for
building even more sophisticated services (just as
Tapestry itself is built upon the servlet API).
--
[EMAIL PROTECTED]
http://tapestry.sf.net
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
