2007/10/8, rangasys [EMAIL PROTECTED]:
I m tring to understand a struts code
i have found this
s:select name=somename list=@[EMAIL PROTECTED]
key=
headerKey=0 headerValue=
i deleted name and other thigs ti highligt wht i want..U can c
list=@[EMAIL PROTECTED] can not
I noticed that
you had a empty Hello action and a number of actions inside classes that
didn't do anything (i.e. login-input inside Login).
In the case of Hello, the purpose of the class is to access the
message resources, which are tied to the actions package. Of course,
we could change from
+1 - Having to explain the exception or the configuration voodoo is
always difficult.
Don Brown wrote:
With the latest refactorings in XWork that allow plugins to provide
code that load Packages, I'd like to suggest that we make it a key
design feature of Struts 2.1 that Core includes no code
My apologies, I've located
https://issues.apache.org/struts/browse/WW-2028 which addresses this
issue, please disregard my original email. I'll take a look at this
issue today since I've setup builds that have included source.
Tom
On 10/7/07, Tom Schneider [EMAIL PROTECTED] wrote:
Is there
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
Don Brown wrote:
With the latest refactorings in XWork that allow plugins to provide
code that load Packages, I'd like to suggest that we
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
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
Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
plugin that is beta. So, I'm voting that we collapse SU and the code
from struts2 core and the current codebehind plugin into a single
location. This would move all the experimental stuff out of core and
still allow users
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
Am Montag, 8. Oktober 2007 21:06:10 schrieb Brian Pontarelli:
Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
plugin that is beta. So, I'm voting that we collapse SU and the code
from struts2 core and the current codebehind plugin into a single
location. This would move
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
On 10/8/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
plugin that is beta. So, I'm voting that we collapse SU and the code from
struts2 core and the current codebehind plugin into a single location. This
would move all the
On 10/9/07, Ted Husted [EMAIL PROTECTED] wrote:
So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
become CodeBehind 2.1.
I'm fine with this on one condition: 100% backwards compatibility.
Backwards compatibility is so crucial for convention-based designs,
because there is
13 matches
Mail list logo
