You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Vjeran Marcinko <vj...@email.t-com.hr> on 2007/11/14 21:03:25 UTC
[T5] Big problem with
Hello.
After years of using Tapestry 4.0, I just started experimenting with T5,
and although it brings much improvement, I noticed a few issues:
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
I don't want to have this "web" package jus becuase I picked that url
pattern. Sometimes I change url patterns rapidly on deployment sites just
because customer told me that URLs would look better to them. I just go to
web.xml, and change it in a matter of few minutes. Now it would be
impossible since it would require refactoring and recompiling many packages.
I always considered that url mapping of both servlets or filters should not
influence application internals, and should be completely transparent thing
if one needs to change it. Similar as one can change name of some .war file
and everything works relative to it.
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.
3. Automatic shortening of page names seems totaly unnecessary to me. (just
my opinion), sicne it can just bring some small confusion sometimes. Anyway,
I don't object so much if it is optiona lfeature, but I think I found a bug
today -
I have a page under
com.mycompany.myapp.pages.users.Users
In other words users/Users page. But when I referenced it, Tapestry rasied
exception saying that page doesn't exist, only "users/" ??!
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?
Regards,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Big problem with
Posted by andyhot <an...@di.uoa.gr>.
Peter Stavrinides wrote:
>
> 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.
Hi, is it possible to elaborate on those 3 points?
What does clumsiness of page navigation and creating subfolders for
pages relate to?
> 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"
>> <km...@servprise.com>
>> To: <us...@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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Big problem with
Posted by Peter Stavrinides <p....@albourne.com>.
>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" <km...@servprise.com>
> To: <us...@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Big problem with
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
----- Original Message -----
From: "Kevin Menard" <km...@servprise.com>
To: <us...@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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Big problem with
Posted by Kevin Menard <km...@servprise.com>.
On 11/14/07 3:03 PM, in article 000d01c826f9$6aa74b40$0100a8c0@vjeran,
"Vjeran Marcinko" <vj...@email.t-com.hr> wrote:
> Hello.
>
> After years of using Tapestry 4.0, I just started experimenting with T5,
> and although it brings much improvement, I noticed a few issues:
>
> 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.
> 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.
> 3. Automatic shortening of page names seems totaly unnecessary to me. (just
> my opinion), sicne it can just bring some small confusion sometimes. Anyway,
> I don't object so much if it is optiona lfeature, but I think I found a bug
> today -
> I have a page under
> com.mycompany.myapp.pages.users.Users
> In other words users/Users page. But when I referenced it, Tapestry rasied
> exception saying that page doesn't exist, only "users/" ??!
There is certainly some cruft around here. E.g., you can't have
com.example.app.pages.Users and com.example.app.pages.users.ListUsers. If
you try to access ListUsers, it'll complain about the context/activation for
the Users page. Likewise, I've yet to figure out how to have "index" pages
for anything other than the root package, where it's named Start by
convention.
> 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.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org