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 _sometimes_. For example:
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
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
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
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
Dakota
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
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 you
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
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 and
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
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 _sometimes_. For
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
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
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 user who
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
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 as Struts
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 Apache
In OpenSymhpony's maven repository for pell-multipart, the pom.xml is missing a
modelVersion4.0.0/modelVersion
This causes some problem when trying to run some of maven2 'lifecycle'. Is it
possible for someone to have a look at it.
Thx.
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... ;-)
Yeah,
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
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
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
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 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
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
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:
In
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
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.
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)
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,
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.
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
extended with
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
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
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
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
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'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
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
resonated
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
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 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
+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
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 methods but
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
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
46 matches
Mail list logo
