>BTW, this page navigation stuff is something I still have to examine a
bit since it is quite a different from T4 design. The T5 way seems much
more >complicated at first glance, but I am sure it just looks that way
because it tries to solve back-button problem which T4 didn't try to
tackle etc..
One of the most criticised areas of T4 was the 'uglyness' of urls and
the clumsiness of page navigation, as well as creating subfolders for
pages etc it was a horrible approach, if you ask me, to issues that
should have been seamless. T5 deals with these issues in a simple and
elegant way, one of the best improvements over 4!! okay so we have to
live with some package/class naming restrictions but once you practice
the recommended naming conventions you never have to even think about
these issues again.
Peter
Vjeran Marcinko wrote:
----- Original Message ----- From: "Kevin Menard" <[EMAIL PROTECTED]>
To: <users@tapestry.apache.org>
Sent: Thursday, November 15, 2007 12:21 AM
Subject: Re: [T5] Big problem with <url-pattern>
1. Biggest issue - most of serious web apps out there wil always
have few
servlets/filters defined in their web.xml, and thus using
<url-pattern>/*</url-pattern> mapping for tapestry filter is not
acceptable
since there will be other mappings defined there. But problem is if one
specifies for instance /web/* mapping for tapestry filter, that forces
specific undesirable structure of packaging of tapestry related code:
com.mycompany.myapp.pages.web
T5 is a filter though, so you should be able to chain them together. I
think it was designed to address precisely the point you bring up.
It also
helps with that horrible /app kludge from older versions of the
framework.
My apologies to framework developers ;)
I just noticed in documentation that Tapesty, after catching all web
app requests due to /* matching pattern, passes of all requests that
don't match further to servlet container.
I was also confused at the beginning when I typed some unexisting page
in browser URL, why Tapestry didn't give me some nice exception page
saying that desired page doesn't exist since I assumed that anything
that goes into Tapestry filter isn't dispatched further, but I got
normal 404 error response from tomcat. Now I know why.
2. I know that Tapestry picked convention over configuration, but
there is a
small drawback with it since good packaging should be defined by domain
logic, not by implementing technology.
For instance, it is not advisable to have packages called
"sessionbeans" and
"entitybeans" in your EJB app, it is no good to have "dao", "model"
etc...Similary, it is no good to have "pages", "components" etc...
Domain
packaging by having "users", "messages", "companies" is good. Of
course,
Tapestry allows subpackaging of "pages" and "components" packages,
but thing
is that if one has to define 2 packages when having many components
or pages
related to one domain module - "components.users" and "pages.users".
I admit that this is no big issue, just small dissapointment that I
have to
structure my app now differently from what I believe is optimal.
I'm still new to T5 myself, but I'm pretty sure these are
configurable. At
one level, I do agree with you. It's very odd to me to have to move
abstract pages out to a different package. At the same time though,
it's a
bit relieving to have a common structure for Tapestry apps.
By docs, I am quite sure they are not configurable. But as you said,
there is some value in knowing common structure of all tapestry apps.
4 Most of some special purpose methods can use naming convention or
annotation demarcation to mark their special purpose. Like event
ethods, or
rendering phases. I don't see why onActivate and onPassivate don't
follow
consistency and have annotations to mark them?
Heh. I don't see why bother with the annotations if there's a method
naming
convention. I much prefer the latter. It jives more with the
convention
over configuration method, and I don't find it remarkably better than
XML.
Now I have a JavaDoc page I keep open with all the annotations to
figure out
which one to use when and what parameters each takes. Sure, there's
some
IDE support, but not when you don't know what you need to use anyway.
Well, I still haven't decided wihch aproach to use, but I just noticed
that all other stuff is mostly matter of choice between these 2
aproaches, and with onActivate/onPassivate there is just one.
BTW, this page navigation stuff is something I still have to examine a
bit since it is quite a different from T4 design. The T5 way seems
much more complicated at first glance, but I am sure it just looks
that way because it tries to solve back-button problem which T4 didn't
try to tackle etc..
Regards,
Vjeran
---------------------------------------------------------------------
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]
