Re: [Stripes-users] Clean URLs failing on form post

2011-02-03 Thread Nikolaos Giannopoulos

William,

Sure, you could definitely come up with many ways to hit this particular 
issue... and I won't refute that... . In fact, I wasn't even aware of it 
in the 1st place and I Thank You for sharing it with the community.


But, again I would never see it because any web app I build 
essentially has WebRoot that looks like this:

/css
/img
/js
/WEB-INF

Not sure if this is explicit best practice but if it isn't it sure might 
be implicit best practice as many a web app are built this way.


ASIDE: I say essentially b/c we in fact have a structure that starts 
with /static/__ID/[css|img|js] and when we release __ID is the release 
version and we set the expires for everything under /static to 1 year 
and we will run it through a CDN... but that is all another story 
altogether and I guess the only worry I could have is if I had a URL 
binding that started with /static/ so thanks for the heads up... .


So in your case I would have:

/images
/jobs
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
  /jsp
  /jobs
   /edit.jsp
   /list.jsp


And there are NUMEROUS intrinsic design benefits here as:
- you get fewer top level folders... easier to manage... yes you could 
make the argument that having things dissected by business area / 
ActionBean is easier to manage but I think if you try this you might see 
what I am talking about... .
- all your images, css and js are rooted under 1 respective folder and 
easily zipped, replaced, scanned, etc...
- do you really have a different edit.css file for different business 
areas / ActionBeans?
- when / if you add JS do you really have a different JS file for 
different business areas / ActionBeans?
- having fewer css / JS files takes advantage of web browser caching, 
limits the cost of the network trip hit, etc...
- and I can go on and on... but now we are talking about Application 
Design... and grey areas... and are off topic... .


Does this not address your problem / the bug you found?

--Nikolaos



Rose William wrote:

Hi Nikolaos,

It probably is!

In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.

More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's action
beans appearing to share the same folders as their resources (e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there too.

Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:

/jobs
 /images
/add-icon.png
/del-icon.png
 /css
 /edit.css

/WEB-INF
   /jsp
   /jobs
/edit.jsp
/list.jsp

I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.

Kind regards,
 
William Rose

Business Intelligence Team Leader
Information Management
 
+61 3 9656 5231   |   Level 8, St Andrews Place, East Melbourne VIC 3002


-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] 
Sent: Thursday, 3 February 2011 2:11 PM

To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post

William,

Isn't it best practice to place ones JSPs rooted under /WEB-INF.  This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.

If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.

Or am I missing something...?

--Nikoloas




Rose William wrote:
  

Hi there,
 
I found the recent discussion on the mailing list about clean URLs 
seemingly failing to find the right event handler when a form is 
POSTed, and saw a variety of solutions to creating the URL oneself.


After trying to debug the same issue myself, I think the reason for 
this behaviour is tied up in Tomcat bug 32424 (see 
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).



My web app is set up with DynamicMappingFilter applied to /*.

I have a WEB directory structure like this:

   /jobs
/edit.jsp
/list.jsp

I have an action bean annotated like this:

   @UrlBinding(/jobs/{$event}/{fullName})

There is a list event, new event and save event:

//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());

return new ForwardResolution(/jobs/list.jsp);
}

@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());

return new ForwardResolution(/jobs/edit.jsp);
}

@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
 

Re: [Stripes-users] Clean URLs failing on form post

2011-02-03 Thread Rose William
Hi Nikolaos,

Adopting your approach for organising your web resources does work well
as a workaround for this issue, and is presumably why it's not a more
common problem.

I structure my web apps more like you than my last example (except for
the placement of JSPs), and I've now popped my JSPs under WEB-INF too,
so this issue really isn't hurting me any more either.

I also took of the @HandleEvent calls as suggested by Sam (I renamed
new to create).

Things are much smoother now!

Kind regards,
 
William Rose
 



From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] 
Sent: Friday, 4 February 2011 2:23 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post


William,

Sure, you could definitely come up with many ways to hit this particular
issue... and I won't refute that... .  In fact, I wasn't even aware of
it in the 1st place and I Thank You for sharing it with the community.

But, again I would never see it because any web app I build
essentially has WebRoot that looks like this:
/css
/img
/js
/WEB-INF

Not sure if this is explicit best practice but if it isn't it sure might
be implicit best practice as many a web app are built this way.

ASIDE:  I say essentially b/c we in fact have a structure that starts
with   /static/__ID/[css|img|js]   and when we release __ID is the
release version and we set the expires for everything under /static to 1
year and we will run it through a CDN... but that is all another story
altogether and I guess the only worry I could have is if I had a URL
binding that started with /static/ so thanks for the heads up... .

So in your case I would have:

/images
 /jobs
 /add-icon.png
 /del-icon.png
/css
 /edit.css
/WEB-INF
   /jsp
   /jobs
/edit.jsp
/list.jsp

And there are NUMEROUS intrinsic design benefits here as:
- you get fewer top level folders... easier to manage... yes you could
make the argument that having things dissected by business area /
ActionBean is easier to manage but I think if you try this you might see
what I am talking about... .
- all your images, css and js are rooted under 1 respective folder and
easily zipped, replaced, scanned, etc... 
- do you really have a different   edit.css   file for different
business areas / ActionBeans?
- when / if you add JS do you really have a different   JS   file for
different business areas / ActionBeans?
- having fewer css / JS files takes advantage of web browser caching,
limits the cost of the network trip hit, etc...
- and I can go on and on... but now we are talking about Application
Design... and grey areas... and are off topic... .

Does this not address your problem / the bug you found?

--Nikolaos



Rose William wrote: 

Hi Nikolaos,

It probably is!

In my case, the only thing in my folder structure was JSPs, so
moving
them to some other folder structure would fix the issue.

More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have
one's action
beans appearing to share the same folders as their resources
(e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there
too.

Let's say I rearranged my JSPs, but also added some extra
graphics and
stylesheets:

/jobs
 /images
/add-icon.png
/del-icon.png
 /css
 /edit.css

/WEB-INF
   /jsp
   /jobs
/edit.jsp
/list.jsp

I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement
of
JSPs.

Kind regards,
 
William Rose
Business Intelligence Team Leader
Information Management
 
+61 3 9656 5231   |   Level 8, St Andrews Place, East Melbourne
VIC 3002

-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] 
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post

William,

Isn't it best practice to place ones JSPs rooted under /WEB-INF.
This
ensures that your JSPs are never directly accessible from the
outside
while still allowing your ActionBean's to forward to them.

If you followed this then Tomcat nor any other Web Container
would
succeed in placing a slash and matching your JSP structure.

Or am I missing something...?

--Nikoloas




Rose William wrote:
  

Hi there,