You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2007/11/01 15:26:43 UTC
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
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 cross-platform technologies is of great interest to
me.
I've extended the initial draft posted here to include the action URI
to Action Class mappings. While based on SmartURLs and CodeBehind, the
description goes beyond what either can do right now.
* http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001
Before doing any more work on the description, I'd be very interested
on feedback as to whether I'm making any sense, or whether the draft
has turned into opaque gibberish :)
-Ted.
On Oct 17, 2007 2:24 AM, Ted Husted <hu...@apache.org> wrote:
> 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 compatibility" means, and also to encourage
> implementation of this pattern by other frameworks.
>
> Following is the beginning of an early draft of a proposed
> "view-behind" specification. (In case anyone is interested, I'm using
> the JSON-RPC specification format as a model.) If there is interest in
> this proposal, I'd suggest we decide whether to complete the
> specification as part of our documentation, or at some other location.
> Of course, people working with other frameworks
> (<cough>stripes</cough>) would be welcome to join in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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, Tom Schneider <sc...@gmail.com> wrote:
> 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 <hu...@apache.org> wrote:
> > 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 cross-platform technologies is of great interest to
> > me.
> >
> > I've extended the initial draft posted here to include the action URI
> > to Action Class mappings. While based on SmartURLs and CodeBehind, the
> > description goes beyond what either can do right now.
> >
> > * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001
> >
> > Before doing any more work on the description, I'd be very interested
> > on feedback as to whether I'm making any sense, or whether the draft
> > has turned into opaque gibberish :)
> >
> > -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Tom Schneider <sc...@gmail.com>.
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 <hu...@apache.org> wrote:
> 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 cross-platform technologies is of great interest to
> me.
>
> I've extended the initial draft posted here to include the action URI
> to Action Class mappings. While based on SmartURLs and CodeBehind, the
> description goes beyond what either can do right now.
>
> * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001
>
> Before doing any more work on the description, I'd be very interested
> on feedback as to whether I'm making any sense, or whether the draft
> has turned into opaque gibberish :)
>
> -Ted.
>
>
> On Oct 17, 2007 2:24 AM, Ted Husted <hu...@apache.org> wrote:
> > 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 compatibility" means, and also to encourage
> > implementation of this pattern by other frameworks.
> >
> > Following is the beginning of an early draft of a proposed
> > "view-behind" specification. (In case anyone is interested, I'm using
> > the JSON-RPC specification format as a model.) If there is interest in
> > this proposal, I'd suggest we decide whether to complete the
> > specification as part of our documentation, or at some other location.
> > Of course, people working with other frameworks
> > (<cough>stripes</cough>) would be welcome to join in.
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 a simple implementation of a SmartURLs MailReader here, that
just uses one method per Action, and no ActionName annotations
* http://sq1-struts2.googlecode.com/svn/trunk/articles/smart-urls/
My question would be what changes would we need to make for this to be
a CodeBehind MailReader, as it currently exists. (I'd try it myself,
but I've already burned through the R&D budget for November!)
-Ted.
On Nov 6, 2007 4:27 PM, Don Brown <mr...@twdata.org> wrote:
> 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 <ia...@fdar.com> wrote:
> >
> > >
> > > 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... mine already went to press (available Nov 26th), and I used
> > XML and the basic annotations/code-behind.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Don Brown <mr...@twdata.org>.
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 <ia...@fdar.com> wrote:
>
> >
> > 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... mine already went to press (available Nov 26th), and I used
> XML and the basic annotations/code-behind.
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Ian Roughley <ia...@fdar.com>.
>
> 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... mine already went to press (available Nov 26th), and I used
XML and the basic annotations/code-behind.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 1, 2007 4:44 PM, Don Brown <mr...@twdata.org> 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 convention stuff to cut the code size and
> complexity of the examples down, which, IMO, would have made it easier
> to learn. Therefore, I'd like to get this resolved asap.
I'd suggest that convention-over-configuration might be an easier
learning curve for people new to Struts 1 or 2. But, I'd wager that
people who have been using Struts 1 for several years will find Struts
2 easier to learn using the tried-and-true struts.xml.
I'd expect that the first wave of Struts 2 adopters are going to be
people with a Struts 1 background. After that, we will start to see
more newcomers, and more people who would be ready for
convention-based development.
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.
In my experience, there are huge discrepancies between the developers
who subscribe to lists like this one, and frequent blogs, and attend
seminars, and try new platforms, like Ruby on Rails, and the other 95%
of developers, who just work for a living :)
When I'm training out in the field, many of the people in the room
haven't even visited the Struts website. Most have never even heard of
Ruby on Rails, and, of those that have, maybe one person has actually
tried it or even read a book about it. Everyone here is very aware of
the pain-points of XML and non-POJO Actions, but the rest of the
world: not so much.
Out in the field, people tell me that the biggest problem they have
with Struts 1 is that it's so easy and so reliable that the developers
are bored! I think a lot of product managers are happy to have that
problem! (As the curse goes: "May you live through interesting
times!")
Of course, the silent majority is only silent when they are bored.
There are a lot of war stories out there about teams who tried
frameworks like JSF and went screaming back to Struts, because JSF was
too different.
Despite Suns' best efforts, today more job posting cite Struts
experience that all other frameworks combined. Heck, Rick Hightower is
afraid to even put Struts on an "absolute"
chart. Why? Because in absolute terms it dwarfs all the others.
* http://www.indeed.com/jobtrends?q=ejb+java%2C+hibernate+java%2C+spring+java%2C+struts+java%2C+jsf+java
In absolute terms, Hibernate and Spring are converging with Struts,
and JSF is trailing behind (way behind).
The lesson of JSF is that when there is a dominant paradigm, evolution
trumps revolution. In terms of the first Struts 2 books, I'd be
careful to present S2 as the same thing only better, rather than as a
brave new way to develop.
-Ted.
<http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 1, 2007 5:02 PM, Brian Pontarelli <br...@pontarelli.com> 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 default to
>> "action,actions,struts,struts2". This would require two annotations and
>> two properties to turn specific packages on and off.
>>
>
> What's the motivation for this change? What's wrong with a list of one
> or more base packages?
>
This is verbose and honestly annoying. We are planning on having a large
number of components (~30), so including each component's action
packages by hand in each applications struts.properties file is
something I am currently avoiding using component.xml and any change
will have to retain that concept. This is why I prefer the identifiers
method. It provides even more convention and less configuration.
> I think in practice, people either setup a specific package for Struts
> Actions, or mix them in with other classes and use an "Action" suffix
> to distinguish them from other similar classes. (For example a Person
> entity class and a PersonAction class.)
>
I would say that entities in the same package as actions is something I
wouldn't ever do, but is something others might go for. I find that my
best practices dictate a clean separation of domain, services, and
actions. My packages are like:
com.example.action
com.example.domain
com.example.service
Vertigo will have crud scaffolding that defaults to this layout as well.
> If people are using some other strange organizational scheme, I think
> it's all right to encourage people to use a more common scheme
> instead. I know a lot of people who refactored their database schemas
> to use Hibernate (and ended up with a better schema in the end).
>
Agreed.
>> 2. Remove the component.xml file handling for components and rely on
>> the changes in #1 to find actions and result locations for components.
>>
>
> +1
>
+1 as well. Now if we can just get JPA to allow EntityManagerFactory to
load multiple persistence.xml files with the same persistence-unit and
JNDI datasource value I'd be set. Unfortunately I still need to put my
component's entity classes into the component.xml file because of JPA.
>> This would make it simpler to start working and create java-packages
>> that contain actions. Plus, it would support all the component
>> infrastructure that I need in a completely standard fashion.
>>
>
> Could you explain what "component infrastructure" is needed?
>
I've built a component infrastructure that allows me to create a
component that contains services, entities, actions and views
(FreeMarker). I can drop that component into the classpath (using
Savant) of any application and I immediately have new admin CRUD and all
of the entities available with no configuration changes. This is very
powerful in the consulting world because it means I can add features to
applications without any coding.
So, whenever I'm talking about components I'm referring mostly to a JAR
file in WEB-INF/lib that contains Struts2 action classes and FreeMarker
results that are accessible via HTTP or AJAX.
Before I was using component.xml to manage all of the component stuff
like action packages and result locations within the JAR files. However,
if I change the action package resolution to use identifiers and package
level annotations for result locations than I don't need the
component.xml file at all. If we stick with the other solution and drop
component.xml I'll have to start adding in the component's action
packages to my applications by hand or via some tool.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 1, 2007 5:02 PM, Brian Pontarelli <br...@pontarelli.com> 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 default to
> "action,actions,struts,struts2". This would require two annotations and
> two properties to turn specific packages on and off.
What's the motivation for this change? What's wrong with a list of one
or more base packages?
I think in practice, people either setup a specific package for Struts
Actions, or mix them in with other classes and use an "Action" suffix
to distinguish them from other similar classes. (For example a Person
entity class and a PersonAction class.)
If people are using some other strange organizational scheme, I think
it's all right to encourage people to use a more common scheme
instead. I know a lot of people who refactored their database schemas
to use Hibernate (and ended up with a better schema in the end).
> 2. Remove the component.xml file handling for components and rely on
> the changes in #1 to find actions and result locations for components.
+1
> This would make it simpler to start working and create java-packages
> that contain actions. Plus, it would support all the component
> infrastructure that I need in a completely standard fashion.
Could you explain what "component infrastructure" is needed?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 7, 2007 11:02 AM, Brian Pontarelli <br...@pontarelli.com> 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 or attribute directive in tag file, attribute
> > fieldValue does not accept any expressions
> > at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> >
> No, but it could be a Struts compatibility issue. I'm using JSTL
> expressions in a number of Struts tags. I recall that someone was
> talking about removing expression support in some of the Struts tags for
> 2.1 and that could be an issue for this application, depending on which
> version of Struts you are using with it.
Struts 2.0.11 with Java 6.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 5, 2007 1:44 PM, Brian Pontarelli <br...@pontarelli.com> 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 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 or attribute directive in tag file, attribute
> fieldValue does not accept any expressions
> at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
>
No, but it could be a Struts compatibility issue. I'm using JSTL
expressions in a number of Struts tags. I recall that someone was
talking about removing expression support in some of the Struts tags for
2.1 and that could be an issue for this application, depending on which
version of Struts you are using with it.
> Using an inline Action to run a Prepare method is an interesting idea,
> as is flexing the form target with an expression. I also note good use
> of the HTTP error handlers (404.jsp and 500.jsp). We should make sure
> those are mentioned in the Cookbook :)
>
I like this prepare approach the best. It ensures that prepare is only
run when it should be (i.e. when the form is rendering). My 404 and 500
handling isn't quite perfect yet, but getting there. When I have time
I'm going to ensure it all is working properly.
>> 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.
>>
>
> Oooh, that's a good one too!
>
> In working with this myself, I've started to create "more knowlegable"
> Actions and methods, to help automate the workflow in the SmartURLs
> spirit. One notion is to have a CRUD action sniff for an ID. If
> there's a non-empty ID, we can deem it an update, otherwise it's a
> create. Of course, for delete and read, we have to use some type of
> hidden field, and/or sniff the HTTP method (as shown by that
> expression). (What happens here if a web service or Ajax request hits
> an Action using PUT or DELETE?)
>
I usually do ID checking down in my persistence service and usually just
share a single persist method between save and update. This example is
more explicit, but a number of things can be combined, including some
more logic between the Save and Update action.
I would think a modified WorkflowInterceptor could handle the various
HTTP methods better. I would think that execute<Method>() signatures
would work and then falling back to execute().
> Having ascertained what kind of CRUD request is being made, a "smart"
> input method can return $crud-input instead of plain-old "input". In
> this way, from the same Action, we can easily map back to a
> create-input, read-input, update-input, or delete-input page. (Which
> may just be wrappers around an include tag.)
>
That might work. I don't really use JSPs to handle responses, but it is
definitely another pattern instead of using the Result annotations.
> Strategies like this help to simplify the page logic, so that they
> only need to worry about submitting to simple actions like "create" or
> "cancel", without knowing anything about the overall workflow. (It may
> be a fetish, but I'm a fan of low-maintenance pages.)
>
Right now I use ${params['action']} to submit to different locations.
I'm up for other methods that help reduce the code in the CRUD example.
> Of course, whether or not to use "aliases" has been a longstanding
> discussion point (alongside of whether to expose actual domain objects
> to an Action). There are pros and cons either way, and I'm not sure if
> there is any one right answer.
>
Probably not. I would expect organizations to decide their standard and
just use that. The Vertigo standard will definitely be a single action
per URL.
> 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 mappings for the validation.xml.
>
It should work since validation is based on the ActionMapping and
SmartURLs follows the standard Class#Method for ActionConfig. If this
isn't working, we should fix it.
> Though, while working on the multiple-methods prototype, I found that
> the SmartURLs index page handling clarifies the "rich" paradigm. I
> setup a package and result-folder for each rich Action , which
> SmartURLs automatically puts together into a namespac, and named the
> Action "Index". The Index model avoids ugly notations like /user/user
> to access the UserAction.
>
Yeah, that's the big reason I added the extra index handling
ActionConfig instances.
> The head prototype uses a bunch of ActionName annotations to map the
> "doMethods" to top-level actions. So "/user/index!create" becomes
> "/user/create". Of course, this would be better handled by an
> convention that automatically mapped doMethods on an Index Action to
> action names. Or maybe even #action-names.
>
> I note that that the latest GMail URIs are using a style like
>
> * http://mail.google.com/mail/#inbox
> * http://mail.google.com/mail/#compose
>
> This looks a lot like, say,
>
> * http://apache.org/licenses/#clas
>
> where we are linking to an anchor target in an index.html file.
>
Everything after the # isn't sent to the server using standard HTTP
compliant user-agents, so it will need to be handled in JavaScript. This
is how most AJAX and flash applications provide single URL/page
applications that are still SEO-able.
> So for the SmartURLs/CodeBehind plugin, I'd suggest that we
>
> * Fix the method-level action validations (or support -validation.xml
> for methods).
>
Definitely!
> * Automatically map "doMethods" on an Index Action to "method" .
>
I'll have to look at your examples to grok this better. But if it
reduces code, I'm all for it.
> * For access to methods on other Actions, fall back to the !-bang syntax.
>
We should support this for sure since S2 does, but I tend to favor a
more RESTful/SEO URL model and don't really use !-bang syntax much.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 6, 2007 6:58 AM, Ted Husted <hu...@apache.org> 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 mappings for the validation.xml.
>>
>
> My mistake. Adding an Index-update-validation.xml file does annotation
> the update alias, at least when the ActionName annotation is used.
>
That's good. Ignore my comments in the last email about that ;)
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 6, 2007 6:58 AM, Ted Husted <hu...@apache.org> 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 mappings for the validation.xml.
My mistake. Adding an Index-update-validation.xml file does annotation
the update alias, at least when the ActionName annotation is used.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 5, 2007 1:44 PM, Brian Pontarelli <br...@pontarelli.com> 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 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 or attribute directive in tag file, attribute
fieldValue does not accept any expressions
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
Using an inline Action to run a Prepare method is an interesting idea,
as is flexing the form target with an expression. I also note good use
of the HTTP error handlers (404.jsp and 500.jsp). We should make sure
those are mentioned in the Cookbook :)
> 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.
Oooh, that's a good one too!
In working with this myself, I've started to create "more knowlegable"
Actions and methods, to help automate the workflow in the SmartURLs
spirit. One notion is to have a CRUD action sniff for an ID. If
there's a non-empty ID, we can deem it an update, otherwise it's a
create. Of course, for delete and read, we have to use some type of
hidden field, and/or sniff the HTTP method (as shown by that
expression). (What happens here if a web service or Ajax request hits
an Action using PUT or DELETE?)
Having ascertained what kind of CRUD request is being made, a "smart"
input method can return $crud-input instead of plain-old "input". In
this way, from the same Action, we can easily map back to a
create-input, read-input, update-input, or delete-input page. (Which
may just be wrappers around an include tag.)
This strategy also works well for cancel. A smart cancel method can do
things like "exit" to "higher" workflow if a create is canceled, but
return to the local index page if an update is canceled.
Strategies like this help to simplify the page logic, so that they
only need to worry about submitting to simple actions like "create" or
"cancel", without knowing anything about the overall workflow. (It may
be a fetish, but I'm a fan of low-maintenance pages.)
Anyway, over the weekend, I put together a couple of MailReader
implementations. One uses a single execute method per Action (thin
Actions), and the other uses multiple methods per Action (rich
Actions).
* (thin) http://smarturls-s2.googlecode.com/svn/tags/mail-reader-input-support-2/java/actions/
* (thin) http://smarturls-s2.googlecode.com/svn/tags/mail-reader-input-support-2/webapp/WEB-INF/results/
* (rich) http://smarturls-s2.googlecode.com/svn/tags/mail-reader-input-support-2/java/action/
* (rich) http://smarturls-s2.googlecode.com/svn/tags/mail-reader-input-support-2/webapp/WEB-INF/result/
Of course, whether or not to use "aliases" has been a longstanding
discussion point (alongside of whether to expose actual domain objects
to an Action). There are pros and cons either way, and I'm not sure if
there is any one right answer.
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 mappings for the validation.xml.
Though, while working on the multiple-methods prototype, I found that
the SmartURLs index page handling clarifies the "rich" paradigm. I
setup a package and result-folder for each rich Action , which
SmartURLs automatically puts together into a namespac, and named the
Action "Index". The Index model avoids ugly notations like /user/user
to access the UserAction.
Using method invocation, the Index-package strategy leads to a style
where the forms kept submitting back to the Index action, but used a
different method for different buttons. Of course, since S2 supports
post-back forms, we don't actually have to specify the action, just
the method.
Taking it a step farther, I refined the rich Action implementation to
give action names to the alias methods. Along the way, I rediscovered
using "doMethods". A keen benefit of doMethods is that a GUI will sort
all the Action aliases together, clarifying the API. The doMethod form
might also make for a better convention than blindly exposing any old
public method with zero parameters.
This "prototype" approach is the head right now.
* http://smarturls-s2.googlecode.com/svn/trunk/apps/mail-reader/java/action/
* http://smarturls-s2.googlecode.com/svn/trunk/apps/mail-reader/webapp/WEB-INF/result/
The head prototype uses a bunch of ActionName annotations to map the
"doMethods" to top-level actions. So "/user/index!create" becomes
"/user/create". Of course, this would be better handled by an
convention that automatically mapped doMethods on an Index Action to
action names. Or maybe even #action-names.
I note that that the latest GMail URIs are using a style like
* http://mail.google.com/mail/#inbox
* http://mail.google.com/mail/#compose
This looks a lot like, say,
* http://apache.org/licenses/#clas
where we are linking to an anchor target in an index.html file.
I don't know what motivates GMail to use this convention, but, in our
case, it would help avoid collisions between automatically mapped
Index aliases and other actions developers might map. But, when I
tried it with the ActionName annotation, it didn't seem to work :(
So for the SmartURLs/CodeBehind plugin, I'd suggest that we
* Fix the method-level action validations (or support -validation.xml
for methods).
* Automatically map "doMethods" on an Index Action to "method" .
* For access to methods on other Actions, fall back to the !-bang syntax.
-Ted.
---------------------------------------------------------------------
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
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>.
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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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
Brian Pontarelli wrote:
> 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 about 5 different variations on it and finally
> settled on one approach we thought made the most sense.
>
> To keep the discussion going, here's the overview:
>
> Preparation is only do on the CRUD form using the action tag. This
> removes the hit of preparing if the submission is successful. This
> allows the application to GET add/edit and POST save/update while
> still preparing the form whenever is required since the form controls
> preparation rather than the actions.
>
> I should have the application into the smart URLs repository pretty soon.
>
> -bp
>
> Ted Husted wrote:
>> 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 <br...@pontarelli.com> wrote:
>>
>>> I think my simple CRUD example will shed a lot of light on my methods,
>>> but here's a rough run down:
>>>
>>> Actions
>>> ------------
>>> Add - Empty
>>> Edit - Fetch entity by id
>>> Prepare - Prepares selects and other associations for the form
>>> Save - Validates and inserts
>>> Update - Validates and updates
>>> Delete - Deletes entity or multiple entities
>>> Index - Displays the list of entities
>>>
>>> Views
>>> ----------
>>> add.jsp - Header block and includes form.jsp
>>> edit.jsp - Header block and includes form.jsp
>>> form.jsp - The form (uses the Prepare action)
>>> index.jsp - The list page
>>>
>>> The form has a cancel button that uses the "redirect-action:index"
>>> syntax. The edit form also has a delete button that uses the action
>>> syntax.
>>>
>>> The only place I use the input result is in the Save and Update classes
>>> for results that go back to the add and edit JSPs. These two classes
>>> can
>>> also be collapsed into a single class or use a parent class to reduce
>>> overhead. Those two and delete are the only ones with annotations for
>>> different results and redirects.
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 about 5 different variations on it and finally
settled on one approach we thought made the most sense.
To keep the discussion going, here's the overview:
Preparation is only do on the CRUD form using the action tag. This
removes the hit of preparing if the submission is successful. This
allows the application to GET add/edit and POST save/update while still
preparing the form whenever is required since the form controls
preparation rather than the actions.
I should have the application into the smart URLs repository pretty soon.
-bp
Ted Husted wrote:
> 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 <br...@pontarelli.com> wrote:
>
>> I think my simple CRUD example will shed a lot of light on my methods,
>> but here's a rough run down:
>>
>> Actions
>> ------------
>> Add - Empty
>> Edit - Fetch entity by id
>> Prepare - Prepares selects and other associations for the form
>> Save - Validates and inserts
>> Update - Validates and updates
>> Delete - Deletes entity or multiple entities
>> Index - Displays the list of entities
>>
>> Views
>> ----------
>> add.jsp - Header block and includes form.jsp
>> edit.jsp - Header block and includes form.jsp
>> form.jsp - The form (uses the Prepare action)
>> index.jsp - The list page
>>
>> The form has a cancel button that uses the "redirect-action:index"
>> syntax. The edit form also has a delete button that uses the action syntax.
>>
>> The only place I use the input result is in the Save and Update classes
>> for results that go back to the add and edit JSPs. These two classes can
>> also be collapsed into a single class or use a parent class to reduce
>> overhead. Those two and delete are the only ones with annotations for
>> different results and redirects.
>>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 <br...@pontarelli.com> wrote:
> I think my simple CRUD example will shed a lot of light on my methods,
> but here's a rough run down:
>
> Actions
> ------------
> Add - Empty
> Edit - Fetch entity by id
> Prepare - Prepares selects and other associations for the form
> Save - Validates and inserts
> Update - Validates and updates
> Delete - Deletes entity or multiple entities
> Index - Displays the list of entities
>
> Views
> ----------
> add.jsp - Header block and includes form.jsp
> edit.jsp - Header block and includes form.jsp
> form.jsp - The form (uses the Prepare action)
> index.jsp - The list page
>
> The form has a cancel button that uses the "redirect-action:index"
> syntax. The edit form also has a delete button that uses the action syntax.
>
> The only place I use the input result is in the Save and Update classes
> for results that go back to the add and edit JSPs. These two classes can
> also be collapsed into a single class or use a parent class to reduce
> overhead. Those two and delete are the only ones with annotations for
> different results and redirects.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 2, 2007 2:50 PM, Brian Pontarelli <br...@pontarelli.com> 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 or
> going elsewhere on cancel?
>
I think my simple CRUD example will shed a lot of light on my methods,
but here's a rough run down:
Actions
------------
Add - Empty
Edit - Fetch entity by id
Prepare - Prepares selects and other associations for the form
Save - Validates and inserts
Update - Validates and updates
Delete - Deletes entity or multiple entities
Index - Displays the list of entities
Views
----------
add.jsp - Header block and includes form.jsp
edit.jsp - Header block and includes form.jsp
form.jsp - The form (uses the Prepare action)
index.jsp - The list page
The form has a cancel button that uses the "redirect-action:index"
syntax. The edit form also has a delete button that uses the action syntax.
The only place I use the input result is in the Save and Update classes
for results that go back to the add and edit JSPs. These two classes can
also be collapsed into a single class or use a parent class to reduce
overhead. Those two and delete are the only ones with annotations for
different results and redirects.
I was planning on attempting a different validation and handling path
that condensed this all some more using rails like POST only handling
for validation and processing. That would remove a few annotations, but
might not be worth it.
Anyways, I'll get that application up and running as soon as I can.
Hopefully have it working over the weekend.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 2:50 PM, Brian Pontarelli <br...@pontarelli.com> 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 or
going elsewhere on cancel?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 1, 2007 10:21 PM, Brian Pontarelli <br...@pontarelli.com> 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 important that developers like
> Jeromy can build applications with it too. To learn another lesson
> from Rails and .NET, we should not only release the code but a set of
> best practices as to how to use the code.
>
Agreed.
> For example, right now, the MailReader is using the bang (!) alias
> syntax, so there are URIs like "update!input" that lead to a
> update-input page. Is there a way to get rid of that inconsistency, so
> all the URIs look the same, or do we need to implement a way for
> update-input to resolve to Update.input()?
>
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.
> * http://code.google.com/p/smarturls-s2/issues/detail?id=16
>
> The "bang" inconsistency already confused me. (Admittedly, not
> difficult to do!) I wondered why I couldn't redirect to another
> namespace. When I came back to the application a few weeks later, I
> realized I was trying to redirect to "update-input" instead of
> "update!input". These are the little pain-points that cost us hours
> and days of head-scratching.
>
I'm pretty sure that's because you are, like I am, deeply involved in
Struts2 and WebWork and had that mindset. Which will be something we'll
need to address with other folks coming on board with this stuff.
>
>> I think my point is that although it has some downsides, it is live in
>> production sites and is working. It obviously can use improvements, but
>> I tend to feel that it works and makes things simpler than using XML. I
>> don't see gaping holes that need to be addressed and from my
>> perspective, anything we might add would be niceties and enhancements,
>> not fundamental changes of direction.
>>
>
> Agreed. Everything I've found is already on the SmartURLs issue list,
> and it's a very short list.
>
> What's missing is usage examples, and especially an test-suite
> application that exercises the key features. I nervously applied some
> patches yesterday, and the reason I was nervous is that I didn't have
> a good way to QA the changes.
>
> Though, I do think that changing the way the Action packages are
> specified, or adopting a hierarchal view of namespaces are still
> significant changes. If this code were already released, those are
> changes that would take us from 1.0 to 2.0. Likewise, a solution to
> the redirect-after-successful-POST could also force a major version
> change, even if it is not a "fundamental" change.
>
Some these would be backwards compatible. Searching a hierarchy is only
used when actions are missing. Therefore, if a production application is
using an older version you can upgrade and the only time hierarchies
will be used is if that application was missing an action or the user
typed in an invalid URL. So, the change would be a 200 instead of a 404.
Likewise, the redirect after post, depending on how it works, would only
kick in if you didn't have a result for an action. If the application is
using an older version and bug free in this area, it will never kick in.
Not too mention older apps use the annotations for redirects, which will
still be available.
The action package resolution change would be rather major, but that's
the only one I can see as an incompatible change.
>> I'm scared to sit on it too long.
>>
>
> IIt doesn't have to be long. How about just long enough to consider
> the short-list of SmartURLs issues, add a test-suite application, and
> see if we can lure guys like Jeromy on board? :)
>
> Honestly, I feel we could have a 1.0 SmartURLs plugin for Struts 2.0
> much sooner than we will ever have a Struts 2.1 release. And, I also
> feel that we would have a Struts 2.1 sooner if we do the right thing
> with SmartURLs now.
>
Okay, sounds good. I can bust out a full app with my best practices
pretty quickly. I'll add it to the project.
> You know, in terms of moving this along, a test-suite application
> might be even more important that a formal specification, since a
> test-suite application could be used to demonstrate
> backward-compatibility. I'm thinking of something like the taglib
> "Exercise" application we have for Struts 1. It's not a cookbook or a
> showcase, it's straight-up bare-bones tests that prove the tags work
> as expected. Of course, the application is also defining our
> expectations :)
>
I've stopped writing the specification, but I still think we should
eventually finish that. I'll switch to the application and go back to
the spec later.
> Meanwhile, the very next thing on my list is a JPA SmartURLs
> MailReader. If we really want to do ourselves a favor, we will be very
> sure that our conventions mesh hand-in-glove with the JPA :)
>
Sounds good. My example will contain a CRUD or two as well. I'll might
use JPA, depending.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 1, 2007 10:21 PM, Brian Pontarelli <br...@pontarelli.com> 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 applications with it too. To learn another lesson
from Rails and .NET, we should not only release the code but a set of
best practices as to how to use the code.
For example, right now, the MailReader is using the bang (!) alias
syntax, so there are URIs like "update!input" that lead to a
update-input page. Is there a way to get rid of that inconsistency, so
all the URIs look the same, or do we need to implement a way for
update-input to resolve to Update.input()?
* http://code.google.com/p/smarturls-s2/issues/detail?id=16
The "bang" inconsistency already confused me. (Admittedly, not
difficult to do!) I wondered why I couldn't redirect to another
namespace. When I came back to the application a few weeks later, I
realized I was trying to redirect to "update-input" instead of
"update!input". These are the little pain-points that cost us hours
and days of head-scratching.
> I think my point is that although it has some downsides, it is live in
> production sites and is working. It obviously can use improvements, but
> I tend to feel that it works and makes things simpler than using XML. I
> don't see gaping holes that need to be addressed and from my
> perspective, anything we might add would be niceties and enhancements,
> not fundamental changes of direction.
Agreed. Everything I've found is already on the SmartURLs issue list,
and it's a very short list.
What's missing is usage examples, and especially an test-suite
application that exercises the key features. I nervously applied some
patches yesterday, and the reason I was nervous is that I didn't have
a good way to QA the changes.
Though, I do think that changing the way the Action packages are
specified, or adopting a hierarchal view of namespaces are still
significant changes. If this code were already released, those are
changes that would take us from 1.0 to 2.0. Likewise, a solution to
the redirect-after-successful-POST could also force a major version
change, even if it is not a "fundamental" change.
> I'm scared to sit on it too long.
IIt doesn't have to be long. How about just long enough to consider
the short-list of SmartURLs issues, add a test-suite application, and
see if we can lure guys like Jeromy on board? :)
Honestly, I feel we could have a 1.0 SmartURLs plugin for Struts 2.0
much sooner than we will ever have a Struts 2.1 release. And, I also
feel that we would have a Struts 2.1 sooner if we do the right thing
with SmartURLs now.
You know, in terms of moving this along, a test-suite application
might be even more important that a formal specification, since a
test-suite application could be used to demonstrate
backward-compatibility. I'm thinking of something like the taglib
"Exercise" application we have for Struts 1. It's not a cookbook or a
showcase, it's straight-up bare-bones tests that prove the tags work
as expected. Of course, the application is also defining our
expectations :)
Meanwhile, the very next thing on my list is a JPA SmartURLs
MailReader. If we really want to do ourselves a favor, we will be very
sure that our conventions mesh hand-in-glove with the JPA :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Chris Pratt wrote:
> On 11/1/07, Brian Pontarelli <br...@pontarelli.com> 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 developed). We're in the process of trying to integrate
> Magnolia into Struts 2, which wasn't really designed for the task.
> Thanks.
>
I don't mind at all because we ran into that exact same issue. We really
wanted a CMS framework and look at 5 or so different open source CMS
tools, including Magnolia, and all of them were applications and none
were really frameworks. We also looked at the JCR implementations and
decided that they were overkill of 95% of our clients. So, instead I
just wrote a JDBC backed CMS that supports simple workflow and
versioning. Took a few weeks, but it works nicely and has a good WYSIWYG
inline editing with previews and a few other features.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Chris Pratt <th...@gmail.com>.
On 11/1/07, Brian Pontarelli <br...@pontarelli.com> 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 developed). We're in the process of trying to integrate
Magnolia into Struts 2, which wasn't really designed for the task.
Thanks.
(*Chris*)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 1, 2007 5:02 PM, Brian Pontarelli <br...@pontarelli.com> 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), would you feel comfortable writing the book against that?
>>
>
> Personally, I'd like to see three different applications written
> entirely with the conventions, before I'd be comfortable calling
> anything like this stable. Good examples might be the MailReader, the
> ShowCase, and a Struts Petstore.
>
I have written ~10 applications to date using it:
http://www.inversoft.com (to be launched with Vertigo in the next few weeks)
http://www.mocapay.com
http://www.ireland-stapleton.com (to be launched next week)
http://www.pentaxian.com
http://www.texturemedia.com
and a few other public applications that I can't recall off the top of
my head and 3 or so internal applications.
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.
> The point of the exercise is to make it easier to write applications.
> The one and only way for anyone to know if this stuff actually works
> is to eat our own dog food, and put it to work. Not just on what we
> are doing in-house, but on public examples, that we ourselves did not
> contrive, and that other people can review and dissect.
>
I think my point is that although it has some downsides, it is live in
production sites and is working. It obviously can use improvements, but
I tend to feel that it works and makes things simpler than using XML. I
don't see gaping holes that need to be addressed and from my
perspective, anything we might add would be niceties and enhancements,
not fundamental changes of direction.
> Looking at the latest SmartURLs MailReader (r119),
>
> * http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war
>
> the biggest pain-point is redirects, and nothing we've done so far is
> addressing that concern.
>
Agreed. This one could use some thought, but there is currently a
solution that is still less headache than XML. Once we have a better
solution it will simply make things even easier.
> I'm sure we won't be able to solve the problem of when and where to
> redirect 100% of the time, but if we can use conventions even 80% of
> the time, we're starting to save actual effort.
>
Perhaps, but this might be understating the number of possibilities.
> The common use case for redirecting is to redirect after a
> (successful) POST, mostly because we don't want them to resubmit
> again, and also because it usually signals the end of a workflow, and
> implies it's time to return to a menu or some other parent workflow.
>
> The POST part we could trap one way or another. The hinky part is
> where the redirect should go (at least by default).
>
Yeah, that's the trick. I need to think on it, but I'm sure we could
come up with something.
> Now, as Brian mentioned, something else we haven't been doing is
> considering the namespaces an actual heirarchy. In both Struts 1 and
> Struts 2, the slashes are just characters, and the namespace is just a
> string. But, what if we adopting the convention of nesting namespaces
> to represent parent/child hierarchies. For example, in the MailReader,
> that would mean that instead of "register" and "subscribe" namespaces,
> we should have "register" and "register/subscribe", or even
> "/menu/register/subscribe".
>
> If we consider namespaces a hierarchy, and we adopt the convention of
> honoring Index pages, then a likely default behavior after a
> successful POST might be to redirect to "../Index", or to the first
> "higher" Index we find.
>
> Again, "redirecting up after post" won't eliminate the need to
> annotate redirects, but it may decimate the need.
>
Could work, but I have a feeling there might be something even better.
Just need to have it pop into someone's head at some point.
> Of course, there are other pain-points in the MailReader, and I'm sure
> we'd find others in new implementations of the ShowCase and Petstore.
> But, the point of the plugin and the spec should be to identify what
> actually helps us write various applications ... and trying to lower
> our tolerance to pain :)
>
I'm not sure I think that it is as much pain as you. I see XML as like a
10 and what we have currently as like a 3. I've gotten used to thinking
in actions and results. I've gotten away from things like using the
action-input urls and worked on more rails like standards. I've tried to
ignore result codes whenever possible and use action names for results.
Things like that. I find that my pain points are less SmartURLs, but
more tricky HTTP/web situations that arise no matter what you are using.
> Overall, my own preference would be to first finish what we've started
> with the SmartURLs plugin for Struts 2.0.x. When we can use it to
> write the simplest possible MailReader, ShowCase, and Petstore, then
> let's make bring it onboard as the new CodeBehind for Struts 2.1.x. If
> there's something that the CodeBehind does that SmartURLs doesn't do,
> then let's port that functionality over.
>
I'm scared to sit on it too long. I'm using it in so many places
already. The more I want to start frameworking around Struts2 the more
I'd like a permanent place for this code. Vertigo (Struts2, Guice,
Hibernate, JPA, scaffolding, emailing, security, ecommerce, file
management, AJAX, etc) is nearing public release point and I'd hate to
have a huge API change after I start doing releases for that and start
evangelizing it. On that note, I'm fine just continuing to develop
SmartURLs and keep things where they are, but I don't really want to
have two competing code bases and dead project situations.
> As to the generic specification, for the last two years, I've spent
> half my time working in .NET, and it looks like that will be the
> status quo for at least a couple of years more. I'm really liking the
> heuristic mappings strategy, and, regardless of what else is
> happening, I'll be implementing a .NET version that we can use at
> work.
>
I'm in a very similar situation and have a number of ideas for making
.Net frameworks like Struts, if I ever get sometime. I think a generic
approach is fine, but I'd rather go generic after we solidify the
Java/Struts version and iron out the last of the decisions.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 1, 2007 5:02 PM, Brian Pontarelli <br...@pontarelli.com> 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), would you feel comfortable writing the book against that?
Personally, I'd like to see three different applications written
entirely with the conventions, before I'd be comfortable calling
anything like this stable. Good examples might be the MailReader, the
ShowCase, and a Struts Petstore.
The point of the exercise is to make it easier to write applications.
The one and only way for anyone to know if this stuff actually works
is to eat our own dog food, and put it to work. Not just on what we
are doing in-house, but on public examples, that we ourselves did not
contrive, and that other people can review and dissect.
Looking at the latest SmartURLs MailReader (r119),
* http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war
the biggest pain-point is redirects, and nothing we've done so far is
addressing that concern.
I'm sure we won't be able to solve the problem of when and where to
redirect 100% of the time, but if we can use conventions even 80% of
the time, we're starting to save actual effort.
The common use case for redirecting is to redirect after a
(successful) POST, mostly because we don't want them to resubmit
again, and also because it usually signals the end of a workflow, and
implies it's time to return to a menu or some other parent workflow.
The POST part we could trap one way or another. The hinky part is
where the redirect should go (at least by default).
Now, as Brian mentioned, something else we haven't been doing is
considering the namespaces an actual heirarchy. In both Struts 1 and
Struts 2, the slashes are just characters, and the namespace is just a
string. But, what if we adopting the convention of nesting namespaces
to represent parent/child hierarchies. For example, in the MailReader,
that would mean that instead of "register" and "subscribe" namespaces,
we should have "register" and "register/subscribe", or even
"/menu/register/subscribe".
If we consider namespaces a hierarchy, and we adopt the convention of
honoring Index pages, then a likely default behavior after a
successful POST might be to redirect to "../Index", or to the first
"higher" Index we find.
Again, "redirecting up after post" won't eliminate the need to
annotate redirects, but it may decimate the need.
Of course, there are other pain-points in the MailReader, and I'm sure
we'd find others in new implementations of the ShowCase and Petstore.
But, the point of the plugin and the spec should be to identify what
actually helps us write various applications ... and trying to lower
our tolerance to pain :)
Overall, my own preference would be to first finish what we've started
with the SmartURLs plugin for Struts 2.0.x. When we can use it to
write the simplest possible MailReader, ShowCase, and Petstore, then
let's make bring it onboard as the new CodeBehind for Struts 2.1.x. If
there's something that the CodeBehind does that SmartURLs doesn't do,
then let's port that functionality over.
As to the generic specification, for the last two years, I've spent
half my time working in .NET, and it looks like that will be the
status quo for at least a couple of years more. I'm really liking the
heuristic mappings strategy, and, regardless of what else is
happening, I'll be implementing a .NET version that we can use at
work.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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
returns....
Ted Husted wrote:
> 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 <br...@pontarelli.com> wrote:
>
>> Of course, but I want to localize the messages to the correct package or
>> the result directory. Really they are associated with that result and
>> not global. As for the trivial case, most CRUDs that I've built always
>> have an empty Add action just for labels. I have a number of other cases
>> that are the same where the form has no preparation but needs to be i18n'd.
>>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 <br...@pontarelli.com> wrote:
> Of course, but I want to localize the messages to the correct package or
> the result directory. Really they are associated with that result and
> not global. As for the trivial case, most CRUDs that I've built always
> have an empty Add action just for labels. I have a number of other cases
> that are the same where the form has no preparation but needs to be i18n'd.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
>> 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, in practice, it's hard to imagine very many non-trivial
> applications that won't need some type of a base action.
>
Of course, but I want to localize the messages to the correct package or
the result directory. Really they are associated with that result and
not global. As for the trivial case, most CRUDs that I've built always
have an empty Add action just for labels. I have a number of other cases
that are the same where the form has no preparation but needs to be i18n'd.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 12:24 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> Ted Husted wrote:
> > On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> 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 easy to provide a package.properties file
> > that the actions can share.
> >
> Isn't package.properties is shared even if there isn't a default action?
Not unless the struts.custom.i18n.resources is set.
<constant name="struts.custom.i18n.resources" value="actions.package" />
> 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, in practice, it's hard to imagine very many non-trivial
applications that won't need some type of a base action.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> 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 easy to provide a package.properties file
> that the actions can share.
>
Isn't package.properties is shared even if there isn't a default action?
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 alternative is to set
>
> <constant name="struts.custom.i18n.resources" value="actions.package" />
>
> I'm just not sure which is the best practice :(
>
Hmmmm, I would say it would be better to localize everything, support
URLs with no action-classes and all the other cases where you need text.
>> After making this change:
>>
>> http://localhost:8080/index shows the index
>> http://localhost:8080/an/arbitary/url also shows the root index
>>
>
> One reason for this is that SmartURLs might be hooking into the
> unknown Action feature, and so any "unknown" action is reverting to
> the index for the document root.
>
SmartURLs has an unknown handler, but if there isn't an action defined,
it just returns null, which should generate an exception in the ActionProxy.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> 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 easy to provide a package.properties file
that the actions can share.
The alternative is to set
<constant name="struts.custom.i18n.resources" value="actions.package" />
I'm just not sure which is the best practice :(
> After making this change:
>
> http://localhost:8080/index shows the index
> http://localhost:8080/an/arbitary/url also shows the root index
One reason for this is that SmartURLs might be hooking into the
unknown Action feature, and so any "unknown" action is reverting to
the index for the document root.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 2, 2007 12:20 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> Hmmmmmmm.......... 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 must have a different welcome page? Or is this something
>> that is no longer necessary because of the smarturls/struts2 conventions?
>>
>
> I updated the ticket since the mailing list post. What I find now is
> that we can omit the welcome-file stanza completely, because as you
> say, the filter does the work.
>
> What didn't work was trying to redirect to the action mapping from a
> JSP or HTML, as we usually have to do with Struts applications. In
> that case, we get some unexpected behavior. Basically, instead of
> opening index.jsp, the system tries to find a index page under
> index.jsp/
>
Yeah, you need to put the index.jsp inside WEB-INF otherwise it is a
"servlet" and Struts filter (I think) thinks it is executable and
redirects to it. I'll find the line of code. I got tripped up on that
for a long time as well.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 12:20 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> Hmmmmmmm.......... 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 must have a different welcome page? Or is this something
> that is no longer necessary because of the smarturls/struts2 conventions?
I updated the ticket since the mailing list post. What I find now is
that we can omit the welcome-file stanza completely, because as you
say, the filter does the work.
What didn't work was trying to redirect to the action mapping from a
JSP or HTML, as we usually have to do with Struts applications. In
that case, we get some unexpected behavior. Basically, instead of
opening index.jsp, the system tries to find a index page under
index.jsp/
But, if you don't do that, then it works fine. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Hmmmmmmm.......... 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 must have a different welcome page? Or is this something
that is no longer necessary because of the smarturls/struts2 conventions?
-bp
Ted Husted wrote:
> 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 http://mailreader:8080/mailreader/ never
> seems to work, unless we use an action extension, and don't use the
> SmartURLs filter.
>
> -Ted.
>
> On Nov 2, 2007 10:04 AM, Ted Husted <hu...@apache.org> 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 to to the document-root /index when it isn't found in
>> the current directory.
>>
>> -Ted.
>>
>> On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
>>
>>
>>> Here's the same example in the unmodified MailReader:
>>>
>>> Register a user and login:
>>> GET http://localhost:8080/register/update!input allows you to edit your
>>> current profile (okay)
>>> GET http://localhost:8080/register/ shows the root index page (the one
>>> at /index) (not okay)
>>> GET
>>> http://localhost:8080/register/login-input/register/login-input/register/login-input/
>>> shows the root index page (not okay)
>>> GET http://localhost:8080/register/update!input/login redirects to GET
>>> http://localhost:8080/register/update!input/menu (not okay)
>>> GET http://localhost:8080/subscribe/update!input/logout redirects to GET
>>> http://localhost:8080/subscribe/update!input/index (not okay)
>>>
>>> It seems to be a bit too eager matching actions in the root namespace.
>>>
>>> Anyway, I wasn't intending to raise bugs. As I mentioned already, I
>>> think this is going to be a great change, but the exception handling and
>>> defaults need to be examined a little closer.
>>>
>>> Hope that helps,
>>> Jeromy Evans
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> HTH, Ted <http://www.husted.com/ted/blog/>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 http://mailreader:8080/mailreader/ never
seems to work, unless we use an action extension, and don't use the
SmartURLs filter.
-Ted.
On Nov 2, 2007 10:04 AM, Ted Husted <hu...@apache.org> 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 to to the document-root /index when it isn't found in
> the current directory.
>
> -Ted.
>
> On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
>
> > Here's the same example in the unmodified MailReader:
> >
> > Register a user and login:
> > GET http://localhost:8080/register/update!input allows you to edit your
> > current profile (okay)
> > GET http://localhost:8080/register/ shows the root index page (the one
> > at /index) (not okay)
> > GET
> > http://localhost:8080/register/login-input/register/login-input/register/login-input/
> > shows the root index page (not okay)
> > GET http://localhost:8080/register/update!input/login redirects to GET
> > http://localhost:8080/register/update!input/menu (not okay)
> > GET http://localhost:8080/subscribe/update!input/logout redirects to GET
> > http://localhost:8080/subscribe/update!input/index (not okay)
> >
> > It seems to be a bit too eager matching actions in the root namespace.
> >
> > Anyway, I wasn't intending to raise bugs. As I mentioned already, I
> > think this is going to be a great change, but the exception handling and
> > defaults need to be examined a little closer.
> >
> > Hope that helps,
> > Jeromy Evans
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> HTH, Ted <http://www.husted.com/ted/blog/>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Antonio Petrelli wrote:
> 2007/11/2, Brian Pontarelli <br...@pontarelli.com>:
>
>> 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
>
Ahhhhh, Struts Ale. Nice hops with a smooth taste. When you add a little
slice of convention it's like heaven. ;)
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Antonio Petrelli <an...@gmail.com>.
2007/11/2, Brian Pontarelli <br...@pontarelli.com>:
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Oops, wrong saying. Meant "I See" not "Roger Wilco". Too much emailing
today. Almost time for beer!
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On Nov 2, 2007 12:09 PM, Brian Pontarelli <br...@pontarelli.com> 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 extension-mapping, evidentially, it tries to seek /index, and
>>> then falls back to to the document-root /index when it isn't found in
>>> the current directory.
>>>
>>>
>> Okay. That sounds like a bug, even though it might be nice to add that
>> functionality in there later. I'll look into that.
>>
>
> Kinda. The default Struts 2/XWork 2 behavior for results is that they
> are suppose to try both the current namespace and then the default
> empty namespace.
>
> * http://www.opensymphony.com/xwork/wikidocs/Namespace%20Configuration.html
>
> That might not be what SmartURLs expects, but that's the documented
> XWork behavior, which makes me thing the underlying framework might be
> doing it somewhere.
>
Roger wilco. Makes sense. I'll look into the hierarchy thing when I get
some time and see what it will take. Should be easy to pull off in the
configuration provider and would bring the handling back into SmartURLs,
which makes me more comfortable. ;)
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 12:09 PM, Brian Pontarelli <br...@pontarelli.com> 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 extension-mapping, evidentially, it tries to seek /index, and
> > then falls back to to the document-root /index when it isn't found in
> > the current directory.
> >
> Okay. That sounds like a bug, even though it might be nice to add that
> functionality in there later. I'll look into that.
Kinda. The default Struts 2/XWork 2 behavior for results is that they
are suppose to try both the current namespace and then the default
empty namespace.
* http://www.opensymphony.com/xwork/wikidocs/Namespace%20Configuration.html
That might not be what SmartURLs expects, but that's the documented
XWork behavior, which makes me thing the underlying framework might be
doing it somewhere.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 to to the document-root /index when it isn't found in
> the current directory.
>
Okay. That sounds like a bug, even though it might be nice to add that
functionality in there later. I'll look into that.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 document-root /index when it isn't found in
the current directory.
-Ted.
On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
> Here's the same example in the unmodified MailReader:
>
> Register a user and login:
> GET http://localhost:8080/register/update!input allows you to edit your
> current profile (okay)
> GET http://localhost:8080/register/ shows the root index page (the one
> at /index) (not okay)
> GET
> http://localhost:8080/register/login-input/register/login-input/register/login-input/
> shows the root index page (not okay)
> GET http://localhost:8080/register/update!input/login redirects to GET
> http://localhost:8080/register/update!input/menu (not okay)
> GET http://localhost:8080/subscribe/update!input/logout redirects to GET
> http://localhost:8080/subscribe/update!input/index (not okay)
>
> It seems to be a bit too eager matching actions in the root namespace.
>
> Anyway, I wasn't intending to raise bugs. As I mentioned already, I
> think this is going to be a great change, but the exception handling and
> defaults need to be examined a little closer.
>
> Hope that helps,
> Jeromy Evans
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
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 <br...@pontarelli.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 shouldn't unless it finds a result that will handle the URL. If
>> it can't find one it will throw the standard exception, which should
>> be processed as it currently is. I've tested default actions/results
>> as well as exception and 404/500 handling and it all works fine. If
>> you could give an example that is not working for you, I can look
>> into it.
>>
> I see. In my case as I had an IndexAction in the base package and a
> result for the success result (/index.jsp) and no default action,
> instead of generating a 404 when entering an arbitrary path, it
> executes the root IndexAction (the index action in the default package).
That is really strange. Smart URLs isn't involved in that process at
all. It simply creates actions for very specific mappings. I would guess
that this is something else handling execution of the root action. Send
me the configuration or create an issue with the configuration because
it definitely shouldn't be happening that way.
> In the case of MailReader, if you enter
> http://localhost:8080/an/arbitary/url it will attempt execute the
> default action (Support) but returns a 404 because no result
> corresponds to SUCCESS. This case seems okay as a default action was
> defined and subsequently executed.
Yeah, that makes sense.
>
> My case can be replicated in the MailReader however by adding a no-op
> IndexAction in root namespace and removing the default-action-ref.
> After making this change:
>
> http://localhost:8080/index shows the index
> http://localhost:8080/an/arbitary/url also shows the root index
> and after showing the index for an arbitrary URL, all relative links
> become invalid:
> ie. clicking on "Log into MailReader" successfully performs a GET to
> http://localhost:8080/an/arbitary/url/login-input/ and shows the index
> again
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.
>>>
>>> Namespace precedence also seems to be an issue when handling invalid
>>> paths and needs to be specified:
>>>
>>> ie.
>>> Assuming pets.IndexAction exists:
>>> http://www.example.com/pets maps to pets.IndexAction (as
>>> expected); but the URL:
>>> http://www.example.com/pets/dogs maps to /IndexAction if
>>> pets.dogs.IndexAction does not exist rather than pets.IndexAction or
>>> an exception (which is expected?)
>> This is a bit confusing. So, /pets should redirect /pets/ and that
>> should render the /pets/index action. However, /pets/dogs should
>> error out unless there is an action named dogs in /pets or an index
>> action in /pets/dogs. If that isn't working it seems like a bug.
>>
> Here's the same example in the unmodified MailReader:
>
> Register a user and login:
> GET http://localhost:8080/register/update!input allows you to edit
> your current profile (okay)
> GET http://localhost:8080/register/ shows the root index page (the one
> at /index) (not okay)
> GET
> http://localhost:8080/register/login-input/register/login-input/register/login-input/
> shows the root index page (not okay)
> GET http://localhost:8080/register/update!input/login redirects to GET
> http://localhost:8080/register/update!input/menu (not okay)
> GET http://localhost:8080/subscribe/update!input/logout redirects to
> GET http://localhost:8080/subscribe/update!input/index (not okay)
>
> It seems to be a bit too eager matching actions in the root namespace.
Yes it does seem very eager. I know that this doesn't occur in
applications that I've written that use only SmartURLs conventions with
no other configuration, so I'm starting to think this is a configuration
thing. But I'll definitely look at the mailreader and see if I can
figure this out.
>
> Anyway, I wasn't intending to raise bugs. As I mentioned already, I
> think this is going to be a great change, but the exception handling
> and defaults need to be examined a little closer.
I'm intending to raise some bugs! ;) I definitely want to ensure that
things work as expected and right now SmartURLs shouldn't be doing any
type of root index handling at all.
>
> Hope that helps,
It does! Thanks.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 2, 2007 1:52 AM, Jeromy Evans <je...@blueskyminds.com.au> 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.
* http://code.google.com/p/smarturls-s2/downloads/list
This one uses the .do extension, since I had trouble with HTML
redirects in 0.18.
Of course, this soft of thing does point out the need for a test-suite
application against which we can test proposed changes.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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 finds a result that will handle the URL. If
> it can't find one it will throw the standard exception, which should
> be processed as it currently is. I've tested default actions/results
> as well as exception and 404/500 handling and it all works fine. If
> you could give an example that is not working for you, I can look into
> it.
>
I see. In my case as I had an IndexAction in the base package and a
result for the success result (/index.jsp) and no default action,
instead of generating a 404 when entering an arbitrary path, it executes
the root IndexAction (the index action in the default package).
In the case of MailReader, if you enter
http://localhost:8080/an/arbitary/url it will attempt execute the
default action (Support) but returns a 404 because no result corresponds
to SUCCESS. This case seems okay as a default action was defined and
subsequently executed.
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
After making this change:
http://localhost:8080/index shows the index
http://localhost:8080/an/arbitary/url also shows the root index
and after showing the index for an arbitrary URL, all relative links
become invalid:
ie. clicking on "Log into MailReader" successfully performs a GET to
http://localhost:8080/an/arbitary/url/login-input/ and shows the index again
>>
>> Namespace precedence also seems to be an issue when handling invalid
>> paths and needs to be specified:
>>
>> ie.
>> Assuming pets.IndexAction exists:
>> http://www.example.com/pets maps to pets.IndexAction (as
>> expected); but the URL:
>> http://www.example.com/pets/dogs maps to /IndexAction if
>> pets.dogs.IndexAction does not exist rather than pets.IndexAction or
>> an exception (which is expected?)
> This is a bit confusing. So, /pets should redirect /pets/ and that
> should render the /pets/index action. However, /pets/dogs should error
> out unless there is an action named dogs in /pets or an index action
> in /pets/dogs. If that isn't working it seems like a bug.
>
Here's the same example in the unmodified MailReader:
Register a user and login:
GET http://localhost:8080/register/update!input allows you to edit your
current profile (okay)
GET http://localhost:8080/register/ shows the root index page (the one
at /index) (not okay)
GET
http://localhost:8080/register/login-input/register/login-input/register/login-input/
shows the root index page (not okay)
GET http://localhost:8080/register/update!input/login redirects to GET
http://localhost:8080/register/update!input/menu (not okay)
GET http://localhost:8080/subscribe/update!input/logout redirects to GET
http://localhost:8080/subscribe/update!input/index (not okay)
It seems to be a bit too eager matching actions in the root namespace.
Anyway, I wasn't intending to raise bugs. As I mentioned already, I
think this is going to be a great change, but the exception handling and
defaults need to be examined a little closer.
Hope that helps,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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.
>>
>> 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), would you feel comfortable writing the
>> book against that?
>>
> 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 finds a result that will handle the URL. If it
can't find one it will throw the standard exception, which should be
processed as it currently is. I've tested default actions/results as
well as exception and 404/500 handling and it all works fine. If you
could give an example that is not working for you, I can look into it.
>
> ie. http:///www.example.com/invalid/path/to/resource currently maps
> to the IndexAction at / (incorrectly?)
Yeah, that shouldn't happen because it doesn't currently look up the
hierarchy of packages. Not sure why this is happening, but it
definitely seems strange. Here's a not so great handling of missing actions:
http://www.texturemedia.com/invalid/index.action
It is a 500, which is due to the exception thrown from the ActionProxy.
>
> Namespace precedence also seems to be an issue when handling invalid
> paths and needs to be specified:
>
> ie.
> Assuming pets.IndexAction exists:
> http://www.example.com/pets maps to pets.IndexAction (as expected);
> but the URL:
> http://www.example.com/pets/dogs maps to /IndexAction if
> pets.dogs.IndexAction does not exist rather than pets.IndexAction or
> an exception (which is expected?)
This is a bit confusing. So, /pets should redirect /pets/ and that
should render the /pets/index action. However, /pets/dogs should error
out unless there is an action named dogs in /pets or an index action in
/pets/dogs. If that isn't working it seems like a bug.
>
> My point is, it's currently ambiguous how these exceptions should be
> handled. Between these and the issues already in the issuelist, my
> experience with SmartURLs 0.18 hasn't yet been positive except in the
> simplest of use-cases. I do feel the approach is great and needed
> though and I'm looking forward to the enhancements.
I'm somewhat surprised, but definitely willing to fix this stuff if we
can reproduce it. All of the cases you have mentioned work fine in all
of the applications I've built to
date so any code examples would be helpful.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Ted Husted <hu...@apache.org>.
On Nov 1, 2007 6:34 PM, Jeromy Evans <je...@blueskyminds.com.au> 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 (0.18) invalid URL's return (unexpected?) success
> results.
>
> ie. http:///www.example.com/invalid/path/to/resource currently maps to
> the IndexAction at / (incorrectly?)
>
> Namespace precedence also seems to be an issue when handling invalid
> paths and needs to be specified:
>
> ie.
> Assuming pets.IndexAction exists:
> http://www.example.com/pets maps to pets.IndexAction (as expected);
> but the URL:
> http://www.example.com/pets/dogs maps to /IndexAction if
> pets.dogs.IndexAction does not exist rather than pets.IndexAction or an
> exception (which is expected?)
So far, treating the namespaces as a hierarchy has not been the
expected behavior. Struts 2 checks the current namespace for a result,
and then the default (empty) namespace. So the behavior you describe
is consistent with the rest of Struts 2.
Although, as mentioned elsewhere, viewing the namespaces as a
hierarchy may be more useful.
> My point is, it's currently ambiguous how these exceptions should be
> handled. Between these and the issues already in the issuelist, my
> experience with SmartURLs 0.18 hasn't yet been positive except in the
> simplest of use-cases. I do feel the approach is great and needed
> though and I'm looking forward to the enhancements.
Could you be more specific as to what enhancements would be the most useful?
I find that making the best use of SmartURLs does mean taking a fresh
look at the application, and sometimes refactoring the layout, much
the same way we sometimes refactor a database schema to work better
with ORM systems, like Hibernate or JPA.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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 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), would you feel comfortable writing the book against
> that?
>
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.
ie. http:///www.example.com/invalid/path/to/resource currently maps to
the IndexAction at / (incorrectly?)
Namespace precedence also seems to be an issue when handling invalid
paths and needs to be specified:
ie.
Assuming pets.IndexAction exists:
http://www.example.com/pets maps to pets.IndexAction (as expected);
but the URL:
http://www.example.com/pets/dogs maps to /IndexAction if
pets.dogs.IndexAction does not exist rather than pets.IndexAction or an
exception (which is expected?)
My point is, it's currently ambiguous how these exceptions should be
handled. Between these and the issues already in the issuelist, my
experience with SmartURLs 0.18 hasn't yet been positive except in the
simplest of use-cases. I do feel the approach is great and needed
though and I'm looking forward to the enhancements.
regards,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Don Brown wrote:
> On 11/2/07, Brian Pontarelli <br...@pontarelli.com> 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 in a wiki page over at the SmartURLs and build on
>> the abstraction that Ted started.
>>
>
> That's the trick of writing against an evolving interface spec - your
> implementation is never done until the spec is finished. In this case,
> it is a spec against a spec :)
>
Yeah, tricky. hehe
> 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 convention stuff to cut the code size and
> complexity of the examples down, which, IMO, would have made it easier
> to learn. Therefore, I'd like to get this resolved asap.
>
Okay, let's do it. I should be able to have a good grasp on the exact
requirements and proposals for the new plugin tomorrow morning. Here's
what I've started:
http://code.google.com/p/smarturls-s2/wiki/TechnicalSpecification
> I'll try to find some time to review Ted's proposal, but if he is
> aiming to get other frameworks involved, it might be a while till it
> is done. In the meantime, do you feel SmartURLs is exactly what you'd
> want the new plugin (or updated codebehind plugin) to look like, or
> are there features you would change/cut? If you want it the way it
> is, we can use its docs as the spec and start the discussion there.
> Having used SmartURLs for a while now, having read Ted's spec, having
> spend some time thinking about the topic, I'd be curious to see how
> you think it should be done, as if starting from scratch.
>
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 default to
"action,actions,struts,struts2". This would require two annotations and
two properties to turn specific packages on and off.
2. Remove the component.xml file handling for components and rely on
the changes in #1 to find actions and result locations for components.
This would make it simpler to start working and create java-packages
that contain actions. Plus, it would support all the component
infrastructure that I need in a completely standard fashion.
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 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), would you feel comfortable writing the book against that?
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Don Brown <mr...@twdata.org>.
On 11/2/07, Brian Pontarelli <br...@pontarelli.com> 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 in a wiki page over at the SmartURLs and build on
> the abstraction that Ted started.
That's the trick of writing against an evolving interface spec - your
implementation is never done until the spec is finished. In this case,
it is a spec against a spec :)
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 convention stuff to cut the code size and
complexity of the examples down, which, IMO, would have made it easier
to learn. Therefore, I'd like to get this resolved asap.
I'll try to find some time to review Ted's proposal, but if he is
aiming to get other frameworks involved, it might be a while till it
is done. In the meantime, do you feel SmartURLs is exactly what you'd
want the new plugin (or updated codebehind plugin) to look like, or
are there features you would change/cut? If you want it the way it
is, we can use its docs as the spec and start the discussion there.
Having used SmartURLs for a while now, having read Ted's spec, having
spend some time thinking about the topic, I'd be curious to see how
you think it should be done, as if starting from scratch.
Don
>
> > Don
> >
> -bp
> > Don
> >
> -bp ;)
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
Don Brown wrote:
> On 11/2/07, Brian Pontarelli <br...@pontarelli.com> 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 deprecated. Is this still how we want to move
>> forward?
>>
>
> I think this is a great case where we need a tech spec before merging
> the code. The spec should cover the problem, use cases, proposed
> solution, and implementation details. The document ted put together
> is a good start for the general approach, but this spec would be more
> focused on exactly how the codebehind plugin would change and why.
>
I can start working on the specifics with respect to the current
functionality in SmartURLs and the proposals that are on the table and
gear it specifically at the new plugin.
> We all have different ideas how the codebehind plugin will work and
> why, and a tech spec will help focus this discussion, and serve as
> useful documentation later.
>
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 in a wiki page over at the SmartURLs and build on
the abstraction that Ted started.
> Don
>
-bp
> Don
>
-bp ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Posted by Don Brown <mr...@twdata.org>.
On 11/2/07, Brian Pontarelli <br...@pontarelli.com> 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 deprecated. Is this still how we want to move
> forward?
I think this is a great case where we need a tech spec before merging
the code. The spec should cover the problem, use cases, proposed
solution, and implementation details. The document ted put together
is a good start for the general approach, but this spec would be more
focused on exactly how the codebehind plugin would change and why.
We all have different ideas how the codebehind plugin will work and
why, and a tech spec will help focus this discussion, and serve as
useful documentation later.
Don
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into
view-behind specification
Posted by Brian Pontarelli <br...@pontarelli.com>.
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?
Second, some thoughts on the specification:
Section 5 was somewhat confusing. I had difficulty determining the
meanings of terms used in section 5 during my first read. Some of them
were later defined in the examples in section 5.1. Particularly
code-suffix, was defined and then not used again until the examples. It
was replaced with 'Code Component Suffix', which isn't in the
definitions section. However, 'Code Suffix' was defined.
I would start off with detailed descriptions of the three strategies for
action matching in section 5. These descriptions should use the
definitions in section 4.
The examples are somewhat confusing because there isn't any definition
about non-code-suffixed actions, which in the Struts case are determined
via implementation of the Action interface. This should probably be
spelled out is some type of action-type matching. #2 , #4 and #5 fall
into this category.
Also, #5 needs an code-suffix variant. And #6 needs an action-type variant.
I would think that a scanning methodology would be best rather than just
a fall back. Something like
/my/namespace/action
/my/action
/action
Also, transform-code-prefix and transform-code-name aren't defined
anywhere and the only workflow that is spelled out is the Mapping Name
transformation.
It seems like there is a change between capitalized definitions and
their dash/lowercase versions, and sometimes they aren't consistent. I
would define everything once using the dash version and ensure that all
capital usages are replace accordingly. This will make it simpler to
reference through out. You could also go with the capital versions and
replace the dash versions. Either way should work, but the dash versions
look better in the BNF.
Also, using the code blocks that Google Code provides colorizes
strangely. It would probably be better to outline workflows as numbered
lists. The BNF looks good in the code blocks but some are colorized and
some aren't. This makes it difficult to pull out the BNF when scanning.
I'd also put in some mention that the heuristic can be handled on demand
or pre-loaded. The way that the current workflows are presented it
sounds like the code and results are only found on demand and not
pre-configured to speed things up.
-bp
Ted Husted wrote:
> 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 cross-platform technologies is of great interest to
> me.
>
> I've extended the initial draft posted here to include the action URI
> to Action Class mappings. While based on SmartURLs and CodeBehind, the
> description goes beyond what either can do right now.
>
> * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001
>
> Before doing any more work on the description, I'd be very interested
> on feedback as to whether I'm making any sense, or whether the draft
> has turned into opaque gibberish :)
>
> -Ted.
>
>
> On Oct 17, 2007 2:24 AM, Ted Husted <hu...@apache.org> wrote:
>
>> 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 compatibility" means, and also to encourage
>> implementation of this pattern by other frameworks.
>>
>> Following is the beginning of an early draft of a proposed
>> "view-behind" specification. (In case anyone is interested, I'm using
>> the JSON-RPC specification format as a model.) If there is interest in
>> this proposal, I'd suggest we decide whether to complete the
>> specification as part of our documentation, or at some other location.
>> Of course, people working with other frameworks
>> (<cough>stripes</cough>) would be welcome to join in.
>>
>
> ---------------------------------------------------------------------
> 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