You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jeromy Evans <je...@blueskyminds.com.au> on 2007/11/07 01:35:00 UTC
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Hi Brian,
There seems to be a small glitch with url mapping in the crud-example
(rev151). It's okay for the standard use-cases but break-downs if I do
something untoward.
Interestingly, the behaviour differs between Firefox and IE6.
Here's the test-case. The URL is what's displayed on the browser.
1. Start the app:
URL: http://localhost:8080/
Shows the index with title Company | Index
2. Click on Add an Company:
URL: http://localhost:8080/add
shows add form with title Company | Add
3. Enter name as "Test Company" and click save
URL: http://localhost:8080/index
shows index with title Company | Index. The list now includes Test
Company.
4. Click on the "Test Company" link
URL: http://localhost:8080/edit?id=0
shows the edit form with title Company | Edit
6. Enter a blank company name and click save
In Firefox:
URL: http://localhost:8080/update
Shows the INDEX page with title Error. The Index is actually
contained within the iframe of 404.jsp
In IE6:
URL: http://localhost:8080/update
Shows the default IE6 404 not found page
7. Continuing on in Firefox, click on the "Test Company" link again
URL: http://localhost:8080/update
Shows the correct edit page within the error iframe
Inspecting the HTTP requests:
update returns a 404 with an iframe referencing "/missing"
the get of /missing returns a 302 containing the index page
subsequent requests are successfully performed within the /missing
namespace
ie.
http://localhost:8080//missing/edit?id=0
Note the double / as well.
Note that Crud-validation.xml uses a RequiredStringValidator but not a
StringLengthvalidator so I think it passes edit. I'm not sure why
update fails though.
As per my prior emails, http://localhost:8080/an/arbitary/url/index also
executes the index action.
Looking at the savant config, my test environment does differ from yours
in that I'm using Struts core 2.0.9 rather than 2.0.6. I'm testing with
Tomcat 5.5.23 from an exploded directory via IntelliJ.
Let me know if there's anything you'd like me to investigate further if
you're unable to reproduce this.
regards,
Jeromy Evans
Brian Pontarelli wrote:
> Okay. The example is in the SmartURLs repository:
>
> http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/
>
> It works pretty well. A few things I think could help reduce the
> overall code bloat:
>
> 1. Support public fields instead of just getters/setters on actions.
> I've never actually done anything interesting in my action property
> accessors, so removing them in all my cases would be fine.
>
> 2. Fix the empty action requirements (the add action is empty for most
> of my apps)
>
> 3. If we add the redirect to index convention, 2 annotations will be
> removed
>
> 4. I could collapse add/save and edit/update using a post check like
> this:
>
> if (ServletActionContext.getRequest().getMethod().equals("GET")) {
>
> }
>
> or I could write a variation on Action that is more knowledgable about
> GETs and POSTs and invokes two different methods depending on the method.
>
> Everything (comments, thoughts, mods, etc) is welcome!
>
> -bp
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
> Thanks Brian, I can't break this version :-)
Excellent!
> I still have the /an/arbitary/url/index issue which is very annoying
> but acknowledge its present in non-smartURLs apps too. Unfortunately
> setting the alwaysSelectFullNamespace flag doesn't entirely avoid it.
> It generates a correct mapping (namespace = /an/arbitary/url,
> name=index) but xwork's
> DefaultConfiguration.getActionConfig(namespace,name) still fails-over
> to the empty namespace and finds the action named index.
>
> Similarly /an/arbitary/url/ maps to namespace = /an/artbitary/url name
> ="" but DefaultConfiguration matches the default action (index) in the
> empty namespace. I'm not sure there's much than can be done about it
> while trying to coexist with non-smarturl configuration in 2.0.x.
Yeah, it is tough since asking the configuration for a runtime mapping
to /anything/index will return /index if it exists and the former
doesn't. We could probably write a separate action mapper or something
along those lines to get rid of that behavior. This is probably lower
priority, but something to think about.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
>>> Brian Pontarelli wrote:
>>>>
>>> Okay. That should be finished. It was somewhat tricky because the
>>> XWork runtime configuration returns a valid ActionConfig for any URL
>>> that ends in a / if you have a index action at the root. This is the
>>> default handling that I'm not very fond of. For now, I turned this
>>> handling off because of the issues I mentioned above. So, SmartURLs
>>> now only handles URLs directly with no default/search behavior. So,
>>> all of Jeromy's issues are resolved.
>>>
>>> -bp
>>>
>>
Thanks Brian, I can't break this version :-)
I still have the /an/arbitary/url/index issue which is very annoying but
acknowledge its present in non-smartURLs apps too. Unfortunately setting
the alwaysSelectFullNamespace flag doesn't entirely avoid it. It
generates a correct mapping (namespace = /an/arbitary/url, name=index)
but xwork's DefaultConfiguration.getActionConfig(namespace,name) still
fails-over to the empty namespace and finds the action named index.
Similarly /an/arbitary/url/ maps to namespace = /an/artbitary/url name
="" but DefaultConfiguration matches the default action (index) in the
empty namespace. I'm not sure there's much than can be done about it
while trying to coexist with non-smarturl configuration in 2.0.x.
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
Sorry, forgot to commit those changes. They are in now.
-bp
Jeromy Evans wrote:
> Brian Pontarelli wrote:
>> Brian Pontarelli wrote:
>>>
>> Okay. That should be finished. It was somewhat tricky because the
>> XWork runtime configuration returns a valid ActionConfig for any URL
>> that ends in a / if you have a index action at the root. This is the
>> default handling that I'm not very fond of. For now, I turned this
>> handling off because of the issues I mentioned above. So, SmartURLs
>> now only handles URLs directly with no default/search behavior. So,
>> all of Jeromy's issues are resolved.
>>
>> -bp
>>
> Thanks Brian, if you're able to commit before heading off-line I'll
> take another look today.
>
> cheers,
> Jeormy Evans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Brian Pontarelli wrote:
> Brian Pontarelli wrote:
>>
> Okay. That should be finished. It was somewhat tricky because the
> XWork runtime configuration returns a valid ActionConfig for any URL
> that ends in a / if you have a index action at the root. This is the
> default handling that I'm not very fond of. For now, I turned this
> handling off because of the issues I mentioned above. So, SmartURLs
> now only handles URLs directly with no default/search behavior. So,
> all of Jeromy's issues are resolved.
>
> -bp
>
Thanks Brian, if you're able to commit before heading off-line I'll take
another look today.
cheers,
Jeormy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
Brian Pontarelli wrote:
>
>>> Okay, I reproduced this pretty easily. The environment differences
>>> didn't matter. The /missing rendering /index is due to the default
>>> handling of missing actions that is performed by Struts/XWork I
>>> think. I'll have to figure out exactly which interceptor does this,
>>> but I'm not a big fan of that behavior. These should be 404s.
>> I'm still tracking this down. I'd like to be able to disable this
>> because it can really become a very nasty situation with relative
>> paths. For example, if /index has a link like this:
>>
>> <a href="support">Get some support dude</a>
>>
>> And you enter a bunk URL like:
>>
>> http://www.example.com/bunk
>>
>> The use will attempt to click on the link and they'll get:
>>
>> http://www.example.com/bunk/support
> Okay, I figured out the double slash issue and the redirect thing.
> SmartURLs is currently and somewhat blindly assuming a redirect when
> it sees an unknown action.
>
> /bad will always redirect to /bad/
>
> I'm going to make a change so that it will only send the redirect if
> /bad/index exists as an action or a result. While I'm in there I'll
> also fix the slash issues. That should clean both problems up nicely.
> Not sure why I did this originally, but it doesn't really make that
> much sense.
Okay. That should be finished. It was somewhat tricky because the XWork
runtime configuration returns a valid ActionConfig for any URL that ends
in a / if you have a index action at the root. This is the default
handling that I'm not very fond of. For now, I turned this handling off
because of the issues I mentioned above. So, SmartURLs now only handles
URLs directly with no default/search behavior. So, all of Jeromy's
issues are resolved.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
>> Okay, I reproduced this pretty easily. The environment differences
>> didn't matter. The /missing rendering /index is due to the default
>> handling of missing actions that is performed by Struts/XWork I
>> think. I'll have to figure out exactly which interceptor does this,
>> but I'm not a big fan of that behavior. These should be 404s.
> I'm still tracking this down. I'd like to be able to disable this
> because it can really become a very nasty situation with relative
> paths. For example, if /index has a link like this:
>
> <a href="support">Get some support dude</a>
>
> And you enter a bunk URL like:
>
> http://www.example.com/bunk
>
> The use will attempt to click on the link and they'll get:
>
> http://www.example.com/bunk/support
Okay, I figured out the double slash issue and the redirect thing.
SmartURLs is currently and somewhat blindly assuming a redirect when it
sees an unknown action.
/bad will always redirect to /bad/
I'm going to make a change so that it will only send the redirect if
/bad/index exists as an action or a result. While I'm in there I'll also
fix the slash issues. That should clean both problems up nicely. Not
sure why I did this originally, but it doesn't really make that much sense.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
>> Inspecting the HTTP requests:
>> update returns a 404 with an iframe referencing "/missing"
>> the get of /missing returns a 302 containing the index page
>> subsequent requests are successfully performed within the /missing
>> namespace
>> ie.
>> http://localhost:8080//missing/edit?id=0
>>
>> Note the double / as well.
>>
>> Note that Crud-validation.xml uses a RequiredStringValidator but not
>> a StringLengthvalidator so I think it passes edit. I'm not sure why
>> update fails though.
>>
>> As per my prior emails, http://localhost:8080/an/arbitary/url/index
>> also executes the index action.
>>
>> Looking at the savant config, my test environment does differ from
>> yours in that I'm using Struts core 2.0.9 rather than 2.0.6. I'm
>> testing with Tomcat 5.5.23 from an exploded directory via IntelliJ.
>>
>> Let me know if there's anything you'd like me to investigate further
>> if you're unable to reproduce this.
> Okay, I reproduced this pretty easily. The environment differences
> didn't matter. The /missing rendering /index is due to the default
> handling of missing actions that is performed by Struts/XWork I think.
> I'll have to figure out exactly which interceptor does this, but I'm
> not a big fan of that behavior. These should be 404s.
I'm still tracking this down. I'd like to be able to disable this
because it can really become a very nasty situation with relative paths.
For example, if /index has a link like this:
<a href="support">Get some support dude</a>
And you enter a bunk URL like:
http://www.example.com/bunk
The use will attempt to click on the link and they'll get:
http://www.example.com/bunk/support
>
> As for the /missing problem, that's because I forgot to set those JSPs
> up and using an iframe was the only way I could get SiteMesh to work
> with 404s and 500s. I'll fix that today.
Fixed this to not use the iframe since this example doesn't use sitemesh.
> Lastly, I have no clue at all why edit is failing validation. The
> Update class extends the Crud action, which has the validation XML. It
> should be validating, but something is not working. I'll step through
> this in a debugger and see what is going on.
Fixed this. The Result annotation in the Update class was referencing
update.jsp, which doesn't exist. It should be edit.jsp. Now everything
works as expected.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SmartURLs crud-example (was [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs
into view-behind specification)
Posted by Brian Pontarelli <br...@pontarelli.com>.
> Inspecting the HTTP requests:
> update returns a 404 with an iframe referencing "/missing"
> the get of /missing returns a 302 containing the index page
> subsequent requests are successfully performed within the /missing
> namespace
> ie.
> http://localhost:8080//missing/edit?id=0
>
> Note the double / as well.
>
> Note that Crud-validation.xml uses a RequiredStringValidator but not a
> StringLengthvalidator so I think it passes edit. I'm not sure why
> update fails though.
>
> As per my prior emails, http://localhost:8080/an/arbitary/url/index
> also executes the index action.
>
> Looking at the savant config, my test environment does differ from
> yours in that I'm using Struts core 2.0.9 rather than 2.0.6. I'm
> testing with Tomcat 5.5.23 from an exploded directory via IntelliJ.
>
> Let me know if there's anything you'd like me to investigate further
> if you're unable to reproduce this.
Okay, I reproduced this pretty easily. The environment differences
didn't matter. The /missing rendering /index is due to the default
handling of missing actions that is performed by Struts/XWork I think.
I'll have to figure out exactly which interceptor does this, but I'm not
a big fan of that behavior. These should be 404s.
As for the /missing problem, that's because I forgot to set those JSPs
up and using an iframe was the only way I could get SiteMesh to work
with 404s and 500s. I'll fix that today.
Lastly, I have no clue at all why edit is failing validation. The Update
class extends the Crud action, which has the validation XML. It should
be validating, but something is not working. I'll step through this in a
debugger and see what is going on.
I'll update in a few with what I find.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org