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
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
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,
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
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
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
Ted Husted wrote:
On Nov 5, 2007 1:44 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Okay. The example is in the SmartURLs repository:
http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/
Are you using a modified TLD? When I tried to run it in Eclipse,
Tomcat complained
On Nov 7, 2007 11:02 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Nov 6, 2007 5:40:25 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet default threw exception
org.apache.jasper.JasperException: /WEB-INF/content/index.jsp(32,12)
According to TLD
Ted Husted wrote:
On Nov 6, 2007 6:58 AM, Ted Husted [EMAIL PROTECTED] wrote:
Of course, for SmartURLs today, in order to use action validation we
have to use the thin approach. The validation annotations for multiple
methods are glommed together in 2.0, and SmartURLs doesn't seem to
pickup
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
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
On Nov 5, 2007 1:44 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Okay. The example is in the SmartURLs repository:
http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/
Are you using a modified TLD? When I tried to run it in Eclipse,
Tomcat complained
Nov 6, 2007 5:40:25 AM
On Nov 6, 2007 6:58 AM, Ted Husted [EMAIL PROTECTED] wrote:
Of course, for SmartURLs today, in order to use action validation we
have to use the thin approach. The validation annotations for multiple
methods are glommed together in 2.0, and SmartURLs doesn't seem to
pickup on the method
If it were me, I'd finish the book using struts.xml, and go to work on
a second edition as soon as SmartURLs goes to 1.0 (even if the first
edition isn't done yet). Getting a couple of solid Struts 2.0 books
out there is the best way to drum up marketshare for a Struts 2.1
edition.
Bummer...
Part of the problem is that the CodeBehind plugin is under-documented,
and I'm not even sure of what it is capable of doing right now.
Perhaps Ian's book will help, or perhaps someone who is using the
CodeBehind will beef up the documentation, or maybe even do a
MailReader implementation.
There's
Ah, another good reason not to kill the codebehind plugin as it
currently exists. I'm still not convinced we need drastic changes
here, more like just filling out functionality.
Don
On 11/7/07, Ian Roughley [EMAIL PROTECTED] wrote:
If it were me, I'd finish the book using struts.xml, and
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
I didn't get very far with the example application. But I should be able
to get that finished today. That application should illustrate exactly
how I've been doing things lately. The situation you brought up is
exactly the same one that we hit and I'm sure everyone else does
eventually. We did
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
The question would be how do we GET add or edit and invoke Prepare,
and then how do we POST to save, update, or delete, and invoke Prepare
if validation fails?
On Nov 2, 2007 3:30 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think my simple CRUD example will shed a lot of light on my methods,
On Nov 1, 2007 10:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I have written ~10 applications to date using it:
Yes, but we also need public example applications that demonstrate a
range of workflows.
If we want to mark something GA, it's important that developers like
Jeromy can build
It may also be something I did to SmartURLs yesterday. I'm going to
try backing some of the changes out.
On Nov 2, 2007 8:08 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Very odd. Might be something Ted added to mailreader, but this shouldn't
be happening and I'd like to figure out why it is.
On Nov 2, 2007 1:52 AM, Jeromy Evans [EMAIL PROTECTED] wrote:
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
The use-case for the default-action-ref is localization. By using a
default-action-ref, it's
And on the subject of extensionless URIs and /index, I'm still haven't
figured out to use a default welcome page with an extensionless URI.
(See SmartURLs Issue 8.)
Past the initial welcome page, extensionless URIs work just fine. But
references to something like
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each of the URLs.
Without extension-mapping, evidentially, it tries to seek /index, and
then falls back to to the
Chris Pratt wrote:
On 11/1/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've also built 3 components using it, a CMS component, News component
and User component. All of these components are being used in the above
sites.
If you don't mind my asking, what CMS system did you use?
Jeromy Evans wrote:
Brian Pontarelli wrote:
Jeromy Evans wrote:
While on the topic, with respect to defaults/exceptions etc, can I
ask the specification addresses how invalid URLs are handled. In
the current implementation (0.18) invalid URL's return (unexpected?)
success results.
They
Hmmm.. Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect or
forward or whatever. Is this something we should handle because there
are cases you
Ted Husted wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each of the URLs.
Without extension-mapping, evidentially, it tries to seek /index, and
then falls back
Ted Husted wrote:
On Nov 2, 2007 1:52 AM, Jeromy Evans [EMAIL PROTECTED] wrote:
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
The use-case for the default-action-ref is localization. By using a
On Nov 2, 2007 1:52 AM, Jeromy Evans [EMAIL PROTECTED] wrote:
Here's the same example in the unmodified MailReader:
Some (or all) of these problems may be a result of some changes I made
yesterday.
You might want to try them again with the 0.18 MailReader that's on the site.
*
On Nov 2, 2007 12:20 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Hmmm.. Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect or
forward or
On Nov 1, 2007 4:44 PM, Don Brown [EMAIL PROTECTED] wrote:
Here is the problem I've having - we are writing a book, and since
this whole issue seems far from resolution, we've been using the XML
configuration throughout the book (it is almost done). What I'd
rather have done is use the
On Nov 2, 2007 12:24 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Ted Husted wrote:
On Nov 2, 2007 1:52 AM, Jeromy Evans [EMAIL PROTECTED] wrote:
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
On Nov 2, 2007 12:09 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Ted Husted wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each of the URLs.
Without
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think there are two changes I'm going to make:
1. Remove smarturls.action.packages and replace this with
smarturls.action.package.identifiers, which is the list of identifiers
that package names must contain. This would
Ted Husted wrote:
On Nov 1, 2007 10:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I have written ~10 applications to date using it:
Yes, but we also need public example applications that demonstrate a
range of workflows.
Definitely.
If we want to mark something GA, it's
Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think there are two changes I'm going to make:
1. Remove smarturls.action.packages and replace this with
smarturls.action.package.identifiers, which is the list of identifiers
that package names must
On Nov 2, 2007 2:50 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've completely moved away from methods and bangs. It makes the code
more readable, and maintainable in my opinion and it reduces the
learning curve considerably.
What do you do about use cases like skipping validation on input
On the topic of properties and localization, I'd like to figure out a
method for handling this stuff without actions but still associating it
with the action or xwork-package.
The struts.custom.i18n.resources setting will find the specified
properties file without an Action class.
But,
Ted Husted wrote:
On Nov 2, 2007 2:50 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've completely moved away from methods and bangs. It makes the code
more readable, and maintainable in my opinion and it reduces the
learning curve considerably.
What do you do about use cases like
Ted Husted wrote:
On Nov 2, 2007 12:20 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Hmmm.. Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect
Ted Husted wrote:
On Nov 2, 2007 12:09 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Ted Husted wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each of the
Oops, wrong saying. Meant I See not Roger Wilco. Too much emailing
today. Almost time for beer!
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Maybe we need the system to look for Action.properties even when there
isn't an Action.class.
On Nov 2, 2007 3:18 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Of course, but I want to localize the messages to the correct package or
the result directory. Really they are associated with that
2007/11/2, Brian Pontarelli [EMAIL PROTECTED]:
Oops, wrong saying. Meant I See not Roger Wilco. Too much emailing
today. Almost time for beer!
It seems that you already had a pint :-P
Antonio
-
To unsubscribe, e-mail: [EMAIL
Seems like a good idea to me. Shouldn't be too difficult if you know the
Java package the action is supposed to be in, which Smart URLs does. So,
it sounds like Smart URLs needs to hook into the localization process in
some fashion Perhaps the action configuration the unknown handler
Antonio Petrelli wrote:
2007/11/2, Brian Pontarelli [EMAIL PROTECTED]:
Oops, wrong saying. Meant I See not Roger Wilco. Too much emailing
today. Almost time for beer!
It seems that you already had a pint :-P
Ah, Struts Ale. Nice hops with a smooth taste. When you add a little
Just to followup, I setup a Google Code site as a place to describe
and design cross-platform technologies that pertain to web application
development and deployment. For some time now, I've spent half my time
working in .NET, which probably won't change for another year or two,
and so working on
Looks good to me. I was going to suggest putting this on the wiki,
but a googlecode project is even better. So would the code for this
new struts2 plugin live here or in the struts codebase?
On 11/1/07, Ted Husted [EMAIL PROTECTED] wrote:
Just to followup, I setup a Google Code site as a place
The notion is that Struts and other projects could build their own
implementations based on the specification, the same way different
groups build components based on the JSON-RPC specification. So, no,
we wouldn't put our own implementation on the Google Code site.
-Ted.
On Nov 1, 2007 9:59 AM,
First, just wanted to cover the plan quick. I was planning on merging
the SmartURLs code into the existing codebehind plugin tomorrow and
ensuring everything is correctly in the new packages and that the old
annotations are correctly deprecated. Is this still how we want to move
forward?
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
First, just wanted to cover the plan quick. I was planning on merging
the SmartURLs code into the existing codebehind plugin tomorrow and
ensuring everything is correctly in the new packages and that the old
annotations are correctly
Don Brown wrote:
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
First, just wanted to cover the plan quick. I was planning on merging
the SmartURLs code into the existing codebehind plugin tomorrow and
ensuring everything is correctly in the new packages and that the old
annotations
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think we might have slightly different ideas, but in general I imagine
everyone is pretty much inline and flexible enough to accept ideas from
others. I'll bang out the spec today and tomorrow and then see where we
are at. I'll put that
Don Brown wrote:
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think we might have slightly different ideas, but in general I imagine
everyone is pretty much inline and flexible enough to accept ideas from
others. I'll bang out the spec today and tomorrow and then see where we
are
Brian Pontarelli wrote:
Besides that, I feel that everything else is fine and all we would be
adding would be features. Nothing else really needs to be completely
changed, but these two changes would impact applications that are
already built on SmartURLs and codebehind.
So, if I bang out
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
So, if I bang out this specification, which would include the existing
functionality with the changes above and a few other things I want to
add in terms of features (i.e. searching / interceptors / defaults /
exceptions / etc),
On Nov 1, 2007 6:34 PM, Jeromy Evans [EMAIL PROTECTED] wrote:
While on the topic, with respect to defaults/exceptions etc, can I ask
the specification addresses how invalid URLs are handled.
The specification implies that the implementation should raise a 404.
In the
current implementation
Ted Husted wrote:
Could you be more specific as to what enhancements would be the most useful?
My smarturl's wishlist:
- perform hierarchical namespace scanning as proposed by Ted
- allow namespace wildcards as per the new REST plugin:
@Namespace(/pets/{type});
- accept URL path
Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
So, if I bang out this specification, which would include the existing
functionality with the changes above and a few other things I want to
add in terms of features (i.e. searching / interceptors / defaults
Jeromy Evans wrote:
Brian Pontarelli wrote:
Besides that, I feel that everything else is fine and all we would be
adding would be features. Nothing else really needs to be completely
changed, but these two changes would impact applications that are
already built on SmartURLs and codebehind.
On 11/1/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've also built 3 components using it, a CMS component, News component
and User component. All of these components are being used in the above
sites.
If you don't mind my asking, what CMS system did you use? (or is it
internally
Brian Pontarelli wrote:
Jeromy Evans wrote:
While on the topic, with respect to defaults/exceptions etc, can I
ask the specification addresses how invalid URLs are handled. In the
current implementation (0.18) invalid URL's return (unexpected?)
success results.
They shouldn't unless it
It appears that Google uses the . character as a word separator.
Therefore, either of the URLs should be fine.
-bp
Brian Pontarelli wrote:
Piero Sartini wrote:
Am Mittwoch, 17. Oktober 2007 23:49:33 schrieb Jim Cushing:
For different renderings/mimetypes, I think it'd make sense, if
Sorry for the late reply. Busy happenings lately.
Don Brown wrote:
Hmm..I'm a bit leary about this component talk. I'd like to keep
Struts 2 simple and I see the goal of this is to define a plugin that:
* Builds configuration based on annotations
* Defines default results when none specified
Piero Sartini wrote:
Am Mittwoch, 17. Oktober 2007 23:49:33 schrieb Jim Cushing:
For different renderings/mimetypes, I think it'd make sense, if
possible, to use a dot-extension (e.g., foo.pdf instead of foo/
pdf), since this is a common and well understood convention.
Is there a
On 10/17/07, Don Brown [EMAIL PROTECTED] wrote:
Hmm..I'm a bit leary about this component talk. I'd like to keep
Struts 2 simple and I see the goal of this is to define a plugin that:
* Builds configuration based on annotations
* Defines default results when none specified
In the
On 10/17/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
Looks good. I like the name and most of the concepts. Here's some
additional thoughts:
1. If no code component exists and a default is not available, the code
invocation can be completely by-passed and processing should proceed
with the
Following up on suggestions made by Don and Brian, I'd like to propose
that we draft a formal specification describing the logic to be used
by the (deep-breath) Able/Code Behind/Zero-Config/SmartURLs plugin
for 2.1. The purpose of the specification would be to better define
what backward
Looks good. I like the name and most of the concepts. Here's some
additional thoughts:
1. If no code component exists and a default is not available, the code
invocation can be completely by-passed and processing should proceed
with the view component handling. The caveat here is that this
First of all, I think Ted did a good job of getting a start on this.
His proposal is a great start that would unify several misc things
that really needed to be unified. (Especially for 2.1.x where it
would be nice to have a unified approach to these things)
Secondly, our company does the exact
I think this is an excellent idea. I also think Stripes has done an
excellent job of implementing this and allowing easy overriding with
Java code (for extensions and such).
Matt
On 10/17/07, Tom Schneider [EMAIL PROTECTED] wrote:
First of all, I think Ted did a good job of getting a start on
This is just so I don't forget to mention it, but at
one point Don was talking about having a built-in
mechanism for handling various mimetype results (csv,
pdf, etc.) via an action extension; I'd like to make
sure that doesn't get lost in the shuffle, either via
an end of the url param (foo/csv,
For different renderings/mimetypes, I think it'd make sense, if
possible, to use a dot-extension (e.g., foo.pdf instead of foo/
pdf), since this is a common and well understood convention.
On Oct 17, 2007, at 5:21 PM, Dave Newton wrote:
This is just so I don't forget to mention it, but at
This gets tricky when handling extensionless URLs, but I think can be
done. I think it will require some filter dispatcher work, but
definitely possible
-bp
Jim Cushing wrote:
For different renderings/mimetypes, I think it'd make sense, if
possible, to use a dot-extension (e.g.,
Am Mittwoch, 17. Oktober 2007 23:49:33 schrieb Jim Cushing:
For different renderings/mimetypes, I think it'd make sense, if
possible, to use a dot-extension (e.g., foo.pdf instead of foo/
pdf), since this is a common and well understood convention.
Is there a problem with search engines if we
Hmm..I'm a bit leary about this component talk. I'd like to keep
Struts 2 simple and I see the goal of this is to define a plugin that:
* Builds configuration based on annotations
* Defines default results when none specified
Things I see out of scope:
* A new component model
* REST support,
78 matches
Mail list logo
