Robert has embodied alot of what I was talking about. Your intution
from experience may often
be wrong, sincce you expected an include to work the same exact way in
JSP. Tapestry
may not be just like JSP but it also avoids almost all of its problems.
You must make a commitment
to get past these hurdles. With that said the Tapestry mailing list is
a fine community to turn to for help
while learning as there are many in your shoes. We would much rather
you ask your questions honestly
and openly and without screaming for a direct answer from HLS(Howard)
than to clog up the list
with banter about superiority of .NET and other frameworks. It will
take a fair bit of commitment on your
part to suffer past the impedence between what you know and what others
have reffered to as the "Tapestry" way.
To the opposite point I think this thread raises a great point, we must
not let Tapestry become too esoteric
that it is self defeating. Tapestry needs to choose a balance between
ease of adoption and technical wizardry.
I have successfully sold Tapestry to clients with the help of feedback
garnered on this list from folks like Erik Hatcher.
The number one complaint they have is "Ease of adoption", however once
they have bitten the bullet,
the payback in productivity is tremendous. At one client designers and
developers now have a common dialog, something
they could never achieve with a framework like struts, they are reusing
components form project to project. They
are starting to develop their own custom components. This is what
folks did with WebObjects, its sad there is almost
10 years in between generations in the products. 4.0 needs to lay a
foundation for things like AJAX and other very
technical concepts, if these concepts immediately influence fist time
developers, then indeed we have a problem.
If your struggling, come to this list ask a question and don't hesitate
since there are many people who were in your
shoes and we don't know your struggling until you ask. But please don't
struggle endlessly and blame the framework,
you must be committed to learning any new technology and that process is
always expited by talking to folks who
have been there and done that. I for one don't want to see people who
barely understand Tapestry criticizing it.
I want to see Tapestry become a compelling replacement for "Struts" and
JSF. I want this to happen
much the same way that Subervsion is now a "Compelling" replacement for
CVS. I am not alone
in this sentiment and we hope that once you get over your initial
learning curve that you feel the same.
Roberts reply is a good testament to all I have babbled on about. Good
luck! and on with your next
questions eh?
Robert Zeigler wrote:
Preston CRAWFORD wrote:
I agree that the community is great and that the idea of Tapestry is
great. But often times you just need to get stuff done. And right now we
can't figure out how to get an include into a page (like you'd do with a
SSI in JSP) where any code gets pre-processed just like the rest of the
page. And we can't figure out how to restart the Tapestry engine in
order to see changes to the spec and template files quickly.
Q: Have you tried starting tomcat, or your tomcat-plugin, or jetty, or
resin, or whatever other servlet container you use with the
-Dorg.apache.tapestry.disable-caching=true option? If what you want is
to be able to see template/spec changes immediately, this will do the trick.
Regarding preprocessing: as Kevin pointed out... what is it,
specifically, that you are trying to accomplish? In what manner should
the stuff be "processed"? And does the "included" file need to be chosen
dynamically? Generally speaking, in tapestry, rather than having a
single page and including content, you write a border component, which
is included on the content pages. But, if what you want is to
dynamically include blocks of html which are processed by tapestry, then
you really need to look at block/renderblock.
As an example, suppose you had a page with an area for "properties". The
"properties" page/content to be used depends on what type of object is
being edited by the page. You need the properties portion to be
fully-functional "tapestry" stuff, but the properties of the various
objects are so different as to render making a single component to
handle all of them difficult, messy, etc. So, you might do something
like define a "getPropertiesPageName" method in each of the object-types
to edit. This returns the name of a page to edit. Additionally, you
could define a "getPropertiesBlockName" method, which gets the name of
the block to edit. Then, in the java class of the page to edit, you can
do something like:
public IComponent getBlock() {
IPage page =
getRequestCycle().getPage(getObject().getPropertiesPageName());
return page.getComponent(getObject().getPropertiesBlockName());
}
And in the html file, you could then do:
<div jwcid="@RenderBlock" block="ognl:block"/>
voila... you've just included arbitrary content.
There is a caveat to this approach. Since "activate"
is never called on the page with the block, methods like
"pageBeginRender", "pageValidate", etc. are /not/ called by tapestry.
So, you'll have to exercise a bit of care in how/where you initialize
things. But, it does work. :)
Robert
---------------------------------------------------------------------
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]
