Ted Husted wrote:
On Nov 5, 2007 1:44 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Okay. The example is in the SmartURLs repository:
http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/
Are you using a modified TLD? When I tried to run it in Eclipse,
Tomcat complained
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
