I found that setting default-action-ref to the base support class for a package solves several problems. It brings in the message resources, and gives us a way to reference shared properties and other shared code. So just by adding
<package name="support" extends="smarturls-default">
<default-action-ref name="support"></default-action-ref>
<action name="support" class="actions.Support"></action>
</package>
I was able to eliminate the empty classes and obvious @ActionName
annotations from MailReader Zero (see r186).
This brings SmartURLs father from beta for me, and closer to a GA feature set.
-Ted.
On 10/8/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/8/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> > I think it would also be useful to take a swing at having message bundles
> > that don't require classes (as it sounds like is the current case - although
> > I haven't looked into it). I don't think empty classes should be required at
> > all.
>
> One work-around would be to specify actions/package.properties as the
> struts.custom.i18n.resources.
>
> For now, I'll go ahead and do that and scuttle the empty MRZ classes,
> so that we can be closer to the ideal.
>
> -Ted.
---------- Forwarded message ----------
From: Brian Pontarelli <[EMAIL PROTECTED]>
Date: Oct 8, 2007 3:04 PM
Subject: Re: [s2] Goal - no experimental code in core for 2.1
To: Struts Developers List <dev@struts.apache.org>
I think it would also be useful to take a swing at having message
bundles that don't require classes (as it sounds like is the current
case - although I haven't looked into it). I don't think empty classes
should be required at all.
Also, one of my other troubles with things is that handling most CRUD
operations requires a lot of duplication or a single class with two
actions, the insert and update, so that validation and relational id
handling (either single or multiple) are consistent. I think there is
a way to fix this, just need to think about it for a while and
brain-storm on the lists.
-bp
Ted Husted wrote:
I like where SmartURLs is going, but, as it stands, I'd still call it
incomplete and experimental. For an approach like SmartURLs (or
ZeroConfiguration/CodeBehind) to be truly useful, we should be able to
at least write something like the MailReader with a bare number of
ActionName annotations (ideally, 0). I'd also like to try a
zero-config ShowCase application.
I'm trying to find time to review the source code and come up with
some patches. I think if the current list of issues were resolved, I
think it would be a great idea to merge SmartURLs with the new
ZeroConfig/CodeBehind plugin.
Here's a summary list of the missing features I came across trying to
implement MailReader:
SU-5 Support ReST-style parameters
* hello-world/save?message=Howdy == hello-world/save/message/Howdy
SU-6 Extend result-type search scope
* /foo/bar/hello-error.jsp, /foo/bar/error.jsp, /error.jsp, and then
fall back to /foo/bar/hello.jsp
SU-7 Automatically chain action (if any) when branching to other pages
* If Foo.execute returns "bar", we check for FooBar.class
SU-16 Heuristic alias matching
* for hello-input, (1) HelloInput.execute, (2) Hello.input
I'd also like to review the validation annotations tickets, since
there were some glitches there too (especially with Skip). (Has anyone
compared the XWork validation annotations with the Hibernate
annotations? Are we compatible?)
-Ted.
On 10/8/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
So, should I go ahead and start promoting SmartURLs or should we
continue to attempt to collapse the zero-conf/codebehind stuff into
SmartURLs?
-bp
smime.p7s
Description: S/MIME cryptographic signature
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
