Here is what I'm talking about:
http://people.apache.org/~mrdon/action2-api-don/org/apache/struts/action2/Messages.html
This approach has the advantages of closely following the familiar Log
interface, and by leveraging the List and Map interfaces, makes it easy
to manipulate and access data f
Looks as though the velocity template isn't quite finished, so I'm
going to help out the friendly folks at spikesource and make the
changes myself.
I'll post back with an update as soon as its ready. Oh, and thanks
for trying this.
--
James Mitchell
On May 4, 2006, at 8:00 PM, Wendy
The new Messages API could easily be mapped onto an implementation
similar to that of Log4J. Why not embrace that idea and utilize
familiar methods to provide access.
such as...
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
It does increase the number of method
+1
On 5/3/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
We need to release version 2 of the struts-parent pom:
* http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml
This is the parent pom from which struts-action-parent inherits, and
it needs to be released prior to the Struts Action
I think the (B) vote is a copy-and-paste error. The form element was
introduced between 1.25 and 1.26, but its never been used. The (B)
lists are tasks that we only need to do after the quality is
determined to be GA, so the one-and-only vote comes in the middle.
-Ted.
On 5/4/06, Don Brown <[EMA
On 5/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I still need to provide detailed instructions (ya, it's on my todo list :) ),
but basically, just do this:
- build and deploy the struts-blank.war sample app
~/svn/struts/current/action/apps/blank
$ mvn package cargo:start
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote:
Don Brown wrote:
> re-education of developers. I want Struts Action Framework 2 to be
Don Brown wrote:
re-education of developers. I want Struts Action Framework 2 to be seen
as easy and powerful, not just from a feature standpoint, but also
migration, education, and "conceptual space" one.
I was talking to Eric on the ww dev chat, and he brought up a good point that
resonate
I'm not quite ready for a vote on the API, because I think what we'd be voting
on is still under active discussion.
We could decide under what criteria we will be evaluating these API changes. I
propose they be:
1. Can we get a GA release out by August?
2. Will at least WebWork 2 apps have
Bob Lee wrote:
o.a.s.action2 - I'd like to hear the design reasoning behind the
Messages changes. I liked the use of Maps in the XWork design as it
made it easier to work with. On the other hand, encapsulating message
operations in the Messages object does reduce the number of
message-handling
I agree both that this is the core decision that has to be made now and that we
should push some of this stuff into XWork.
I won't vote though, because I've learned we're discussing not voting :-D
- Original Message
From: Jason Carreira <[EMAIL PROTECTED]>
To: dev@struts.apache.org
Sen
> We're using WebWork 2.2 heavily on a handful of
> projects (OK, a big
> handful of big projects), so I definitely understand
> the concerns.
>
> I didn't mean to shock anyone. I thought my point of
> view was clear
> based on the introduction to the "Rough Spots" page
> (http://wiki.apache.org/s
Actually my point was the Servlet*Aware interfaces should be isolated
as their use is generally a bad practice. There was some confusion as
to what RequestAware was doing.
If you have to implement 35 interfaces to implement an action then
obviously this would not be a viable framework. In most ca
On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote:
- Passing in keys vs. actual messages - I think always passing in keys
is one thing Struts got right.
I presume you meant Struts Action Framework 1 ;-)
Even if you only support one language,
abstracting messages out of your code is still a good pr
>
> How do you envision that working? Would individual
> messages have an
> optional "severity" property? (i.e. "error",
> "warning", possibly
> others) Or would there be one bundle of messages for
> each severity?
>
> I've taken to using a generic BusinessProcessResult
> object (sometimes
>
>
> Ok, what about passing in an instance of Messages,
> MessagesAware, or something
> similar?
>
Well, currently the validators are passes a ValidatorContext when they are
created. The ValidatorContext includes methods for adding messages as well as
methods for getting localized texts, etc.
On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote:
I definitely agree that they should be isolated, but glancing through
the api I saw RequestAware but not ResponseAware. (I`m reading the
copy Don posted and not the version under source control.)
ValidationAware, ErrrorAware, RequestAware, Resp
We're using WebWork 2.2 heavily on a handful of projects (OK, a big
handful of big projects), so I definitely understand the concerns.
I didn't mean to shock anyone. I thought my point of view was clear
based on the introduction to the "Rough Spots" page
(http://wiki.apache.org/struts/RoughSpots)
How to implement this is a good question. When I use warnings in my
application, they aren't displayed on the very next page, but rather collected
as the user goes through the wizard. Then, on the last page, the user is asked
to confirm the information, and it is here we display the warnings.
Also, I forgot to mention, I'd like to avoid the use of "Error" when
referring to messages, because many times there are errors,
warnings, and information messages. I like the ability for
validation to raise warnings that don't result in a failure, but
allows me to warn the user the value migh
Jason Carreira wrote:
I agree with Don on almost everything... scary!
The exception is the validate() method returning messages... we need a
central
place where messages are added, not passing them in and out of methods.
Ok, what about passing in an instance of Messages, MessagesAware, or some
I definitely agree that they should be isolated, but glancing through
the api I saw RequestAware but not ResponseAware. (I`m reading the
copy Don posted and not the version under source control.)
On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote:
On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote:
>
I agree with Don on almost everything... scary!
The exception is the validate() method returning messages... we need a central
place where messages are added, not passing them in and out of methods.
I was also confused by the Request interface... I thought / expected it was
going to be a way to
I'm ok if you want to just remove the copyright. BTW - the copyright
assignment form was faxed monday (5/1).
/Ian
--
From Down & Around, Inc.
Innovative IT Solutions
Software Architecture * Design * Development
~
web: www.fdar.com
email
So long as this statement...
"...the proposed feature changes nothing for regular Action users, it
changes nothing for old DispatchAction users, but it makes things a lot
simpler for those who want to switch to event-based paradigm with as
little efforts as possible."
...is true, count me +1. As
I'm preparing to draw the Struts Action 1.3.2 release quality vote to a close,
but as I look at the release plan, I see it has us voting twice on the same
release for the same quality vote (vote a and b). Why is this? Seems to me one
vote should be plenty.
Don
--
On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote:
In regards to the implementation of the API where did ResponseAware
go?
org.apache.struts.action2.servlet.ServletResponseAware
I put these interfaces in a sub package because users should avoid
creating dependencies on the servlet API in their
According to the roadmap (or at least the one in my head :)), Struts
Action 2 will be implemented in two phases:
Phase 1 - Rename WebWork 2 code, implement Struts 1.x support, minor changes
Phase 2 - Annotations, Zero XML configuration, new easy development modes, etc
The goal of Phase 1 is to g
On 5/4/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 5/4/06, Claus Ibsen <[EMAIL PROTECTED]> wrote:
>
> The JDK1.5 api looks really great.
>
> I'm not native english but is this interface name correct?
>
> Validatable
>
> Should it not be?
> Validateable
Neither of these is an English word...
In OpenSymhpony's maven repository for pell-multipart, the pom.xml is missing a
4.0.0
This causes some problem when trying to run some of maven2 'lifecycle'. Is it
possible for someone to have a look at it.
Thx.
Martin Cooper wrote:
On 4/30/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
Martin Cooper wrote:
> On 4/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
>>
>> I call a vote that the Struts PMC accept the WebWork 2 podling as
having
>> met the incubation requirements and thereby be
>> accepted by the
On 4/30/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
Martin Cooper wrote:
> On 4/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
>>
>> I call a vote that the Struts PMC accept the WebWork 2 podling as
having
>> met the incubation requirements and thereby be
>> accepted by the Apache Struts project
I guess I'm a bit confused but is this API the only supported route or
are their plans to support existing WebWork/Xwork code? I'll be honest
and say that I need to go through the API and consider each point
before I make a complete judgement. However, at first glance, this
deviates far enough fro
On 5/4/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote:
>Looking at 1.3 internals (at last) I've found that it contains both
>ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is
>this duality really needed?
>
>For a regular Struts us
At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote:
Looking at 1.3 internals (at last) I've found that it contains both
ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is
this duality really needed?
For a regular Struts user who does not extend RP, the new CRP should
work just l
Looking at 1.3 internals (at last) I've found that it contains both
ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is
this duality really needed?
For a regular Struts user who does not extend RP, the new CRP should
work just like the old one. The only difference is the config
On 5/3/06, Jeff Turner <[EMAIL PROTECTED]> wrote:
On Wed, May 03, 2006 at 08:00:43PM -0700, Martin Cooper wrote:
> On 5/3/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >
> > The Subversion plugin for JIRA seems to be installed, but it's not
> > working.
>
>
> Weird. It seems to be working _someti
On 5/4/06, Claus Ibsen <[EMAIL PROTECTED]> wrote:
The JDK1.5 api looks really great.
I'm not native english but is this interface name correct?
Validatable
Should it not be?
Validateable
Neither of these is an English word... ;-)
--
Martin Cooper
/Claus
I'm -1 on the draft proposal.
The vast majority of the API as I read it is to support Bob's proposal of how
to deal with XWork. As Patrick stated before (paraphrase) the three proposals
are:
1) Move XWork over as a seperate project under the umbrella of Struts Action 2
(Webwork=>Struts "web" a
> Jason brings up a great point. Is Struts2 meant to
> be a "mostly" compatible upgrade from webwork 2.2.2,
> or is it to be similar to the upgrade from Struts?
> We have spoken about correcting the API, but I do
> not think this question has ever been asked. I
> think we have also been saying th
Jason brings up a great point. Is Struts2 meant to be a "mostly" compatible
upgrade from webwork 2.2.2, or is it to be similar to the upgrade from Struts?
We have spoken about correcting the API, but I do not think this question has
ever been asked. I think we have also been saying that if yo
Ok, I remember us saying we wanted to clean up a lot of things that weren't
right in the old codebase, but why are we changing everything just for the sake
of change?
Instead of having a pretty good sized community who can easily switch over with
a few tweaks (the WebWork community) and a huge
I am not sure if I want you to walk up to me and say: "Would you sign my
copy of Catcher in the Rye please?"
You do have it, don't you?
.V
Dakota Jack wrote:
This is silly, whomever you are.
On 5/3/06, netsql <[EMAIL PROTECTED]> wrote:
"and that is why you will kill me last"?
:-0
.V
Dak
Then you are saying that a different approach would not be popular?
So to restate it, what is going here is popular. Oh good. Last thing I
want is something strange.
Life just anint' fair, is it now.
Maybe you are imagining that you hired some of the people on this list,
and that they wo
The JDK1.5 api looks really great.
I'm not native english but is this interface name correct?
Validatable
Should it not be?
Validateable
/Claus
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=29317&
Greg Reddin ha scritto:
I've added a preliminary version of a TilesContext interface and
refactored the core API to use it. .
Note that I ran out of time before I had a chance to look at these
other examples, so if you look at what I just committed and inherently
see a better way, please
46 matches
Mail list logo
