AM
Subject: Re: What's the goal of SAF 2.0? (was Public API first draft )
I always have a question:why we old webwork 2.2 users can't get "maintenance
releases even a fixed release".
Webwork2 wiki,cvs,and iss
I always have a question:why we old webwork 2.2 users can't get "maintenance
releases even a fixed release".
Webwork2 wiki,cvs,and issue (switch to SAF2) are all closed.
-
Posted via Jive Forums
http://forums.opensymphony.com/t
Ted Husted wrote:
On 5/6/06, Don Brown <[EMAIL PROTECTED]> wrote:
Please don't judge until we are done.
Silence can be taken to imply consent, and if people with questions
don't speak up now, then other people might be disappointed later,
when a binding veto lands on the table.
We need to fi
> Please don't judge until we are done. We need to
> first agree on our
> design goals, then we can pick through
> implementations. The proposal is
> about agreeing to the laid out design goals, but it
> is too early to say
> that we are or aren't meeting them. First cuts are
> never put into
On 5/6/06, Don Brown <[EMAIL PROTECTED]> wrote:
Please don't judge until we are done.
Silence can be taken to imply consent, and if people with questions
don't speak up now, then other people might be disappointed later,
when a binding veto lands on the table.
We need to first agree on our
des
Jason Carreira wrote:
If you looked at the Struts Ti proposal, you'd see
that the goal was to start
developing advanced features to dramatically simplify
development. The whole
reason we looked at WebWork in the first place is we
wanted a solid foundation
so that we could focus on features.
> If you looked at the Struts Ti proposal, you'd see
> that the goal was to start
> developing advanced features to dramatically simplify
> development. The whole
> reason we looked at WebWork in the first place is we
> wanted a solid foundation
> so that we could focus on features.
>
> With t
e part that refers to this, I assume.
Gabe
- Original Message
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, May 5, 2006 5:05:29 PM
Subject: Re: What's the goal of SAF 2.0? (was Public API first draft )
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]&g
: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, May 5, 2006 5:05:29 PM
Subject: Re: What's the goal of SAF 2.0? (was Public API first draft )
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> What's the goal of SAF 2.0?
<
> 1) Clean up some
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
What's the goal of SAF 2.0?
<
1) Clean up some of the more annoying points of WebWork and XWork but generally
have a backward compatible framework that WebWork users can easily jump on to
quickly
+1
SAF 2.0 == WW 2.3
I'm still working off
Joe Germuska wrote:
What about a String constant representing a global warning, and then only
warn(String fieldName, String key)
warn(String fieldName, String key, Object...)
i.e.
warn(GLOBAL, "warnings.foo", 42);
Hmm...I'm not generally a fan of constants when a separate method would do, but
Cool :) That jives with what has been said in the past, I just wanted,
as a current SAF1 user, to make sure that message didn't get lost.
Frank
Jason Carreira wrote:
Right, this is very important, but it's always been planned that there would be
a migration kit + some effort to migrate an ex
--- Jason Carreira <[EMAIL PROTECTED]>
wrote:
> It was always assumed until recently that WebWork
> users would find it very simple to move to SAF 2.x
> and would quickly form a community around SAF 2.0.
> If the API is going to be very different, the
> migration path for WebWork users is going
What about a String constant representing a global warning, and then only
warn(String fieldName, String key)
warn(String fieldName, String key, Object...)
i.e.
warn(GLOBAL, "warnings.foo", 42);
Joe
At 12:26 PM -0700 5/5/06, Bob Lee wrote:
There's some potential overloading ambiguity. For exam
Right, this is very important, but it's always been planned that there would be
a migration kit + some effort to migrate an existing Struts 1.x app to SAF 2.0,
but we've always planned for that.
It was always assumed until recently that WebWork users would find it very
simple to move to SAF 2.x
On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Although you don't mention it here, I think it's always been kind of
implied... still, I'd like to see it explicitly stated, and that is,
what about existing Struts users? Will they have a migration path (and
what is it?), or not? The same
On May 5, 2006, at 12:47 PM, Craig McClanahan wrote:
Consider the way the world was before JSR-168 happened ... every
portal
server had their own completely different API for building portlets
Yes, and I am stuck working on one of those (or should I say working
*around* one of those) as w
Although you don't mention it here, I think it's always been kind of
implied... still, I'd like to see it explicitly stated, and that is,
what about existing Struts users? Will they have a migration path (and
what is it?), or not? The same kind of question your asking for Webwork
users in oth
There's some potential overloading ambiguity. For example:
void warn(String key, Object... arguments);
void warn(String fieldName, String key);
Right now, if I want to add a global warning with one String argument,
I'll have to cast the argument to Object:
messages.warn("key", (Object)
So we've gone off on many tangents, but the core question remains unanswered.
What's the goal of SAF 2.0?
Are we looking to:
1) Clean up some of the more annoying points of WebWork and XWork but generally
have a backward compatible framework that WebWork users can easily jump on to
quickly
2
On May 5, 2006, at 9:36 AM, Jason Carreira wrote:
Ugh... I really don't like that... really... seems like using an
ugly hack instead of defining a higher-level abstraction.
The deal breaker for me was that users will be able
to reuse the same
code inside and outside of our framework. They
Addresses my concerns quite nicely and should be easy to refactor code against.
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
> - The attached version supports arbitrary levels. I used an interface
> inste
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish. Should Level extend Comparable?
- It has built in support for I
On 5/5/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> Therefore, I personally consider JSR-168 a big mistake, and I would
> prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> I would think we'd want to support some explicit
> notion of a "setup" phase
> right before rendering, and a "cleanup" phase
> afterwards. That way, you can
> do things like open a Hibernate session and do a
> query that's needed to
> popul
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish. Should Level extend Comparable?
- It has built in support for INFO, WARN, and ERROR along with
respective convenience methods.
- It provides a Map of fi
Craig McClanahan wrote:
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Therefore, I personally consider JSR-168 a big mistake, and I would
prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had their own completely different A
> I would think we'd want to support some explicit
> notion of a "setup" phase
> right before rendering, and a "cleanup" phase
> afterwards. That way, you can
> do things like open a Hibernate session and do a
> query that's needed to
> populate a table, then clean up the session
> afterwards. (J
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Therefore, I personally consider JSR-168 a big mistake, and I would
prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had their own completely different API for building portlets,
>
> If support for a portlet environment is a goal for
> SAF2, remember that there
> is more to it than just papering over the differences
> between the portlet
> and servlet APIs. You also have to deal at the
> functional level with the
> differences in the request processing lifecycle of
> the
>From the discussion there, it looks like they already had something mimicking
>the HttpServletRequest with a lot of the same methods copied over and were
>pretty tightly coupled already to the environment they were in. The WebWork /
>Xwork code is not, so I don't see us as being in the same pos
On 5/5/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
If support for a portlet environment is a goal for SAF2, remember that there
is more to it than just papering over the differences between the portlet
and servlet APIs. You also have to deal at the functional level with the
differences in th
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
These are very good points. How does JSF handle the multiple renders?
For the implementation questions below, my answers are based on the
jsf-portlet bridge code in the RI's java.net project. AFAICT, the
implementations inside MyFaces and the
These are very good points. How does JSF handle the multiple renders? Do you
have to ensure your backing bean is session scoped? Wouldn't a request scope
mean the data would be lost at the end of the processAction()? How would you
expect a portlet lifecycle to be supported with a stateless A
Yeah - you're right - I've been working in declarative validations for
too long
Don Brown wrote:
No, the developers would use .info/warn/error to add messages, but I'm
saying they probably wouldn't need to retrieve them, as tags would
take care of it for them.
Don
Ian Roughley wrote:
So, a
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
That doesn't reference either of those interfaces -- but I think the
JSTL behaves very unpredictably given objects that implement both
interfaces. I can't remember the specifics, but since the syntax for
indexing list elements as well as map k
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
It isn't about using Cocoon or "building another version of it", but
rather
learning from others design choices and consequences. I see Struts Action
2 as
a chance to quit "competing" and start "collaborating". Merging with
WebWork
was the first
No, the developers would use .info/warn/error to add messages, but I'm saying
they probably wouldn't need to retrieve them, as tags would take care of it for
them.
Don
Ian Roughley wrote:
So, adding the msgs.info("key") really isn't going to be used by
developers? The code below, if I am rea
So, adding the msgs.info("key") really isn't going to be used by
developers? The code below, if I am reading it correctly (not too much
experience with JSTL), will call the list or map for the
error/msg/warning directly and iterate over the elements.
So why do we need the additional methods?
Happily XWork has no dependency on web development at all, I use it to
provide a command pattern for autonomous path finding robots for
instance. Anything less than complete abstraction at the action level
would be vetoed by most of the existing developers. (At least I hope
they would vote it down
It isn't about using Cocoon or "building another version of it", but rather
learning from others design choices and consequences. I see Struts Action 2 as
a chance to quit "competing" and start "collaborating". Merging with WebWork
was the first important step, but equally important was Tim fr
I will return to the boards shortly, I hope :-) But I've been
reading and need to address this:
Please be mindful not to buttonhole Struts into a servlet-only API.
One of the large efforts of the Tiles refactoring is to remove all
references of the Servlet API, so that it could be used in a portle
> Jason Carreira wrote:
>
> Either way, I highly recommend reading the two
> threads linked to by this
> Cocoon vote to use the servlet classes directly:
>
> http://www.mail-archive.com/dev@cocoon.apache.org/msg4
> 1132.html
>
> The cocoon folks are very smart and have been
> tackling this probl
>
> Yeah, this is very much like ValidationAware. I
> think it deserves a
> change because:
>
> 1. Messages should be independent of validation,
> however, validation
> hould be dependent on messages
Then this is just a renaming, because ValidationAware is just methods for
gathering errors
Jason Carreira wrote:
Well, I'm of the opinion that the Portlet API
specifically shouldn't have
extended the Servlet API, but I think there is
something to use implementing
Servlet API classes with Portlet implementations. As
I've previously mentioned,
this is the approach Cocoon is either l
Joe Germuska wrote:
At 7:34 AM -0700 5/5/06, Don Brown wrote:
But since this class implements List and Map, it is very obvious how
to retrieve messages:
${msg}
or
${msg}
Which class implements List and Map? org.apache.struts.action2.Messages
http://people.apache.org/~mrdon/action
Jason Carreira wrote:
Here is what I'm talking about:
http://people.apache.org/~mrdon/action2-api-don/org/ap
ache/struts/action2/Messages.html
I'm not sure I see enough of an advantage to this over say
ValidationAware from XWork to make it worth doing... I liked the
original idea on the "Roug
At 7:34 AM -0700 5/5/06, Don Brown wrote:
But since this class implements List and Map, it is very obvious how
to retrieve messages:
${msg}
or
${msg}
Which class implements List and Map? org.apache.struts.action2.Messages
http://people.apache.org/~mrdon/action2-api/org/apache/stru
Jason Carreira wrote:
For example, the Messages object, rather than
leverage the familiar Log
interface we all use every day. Messages are
collected, much like logging
messages and their levels are similar. Therefore,
we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error(
> Here is what I'm talking about:
> http://people.apache.org/~mrdon/action2-api-don/org/ap
> ache/struts/action2/Messages.html
>
I'm not sure I see enough of an advantage to this over say ValidationAware from
XWork to make it worth doing... I liked the original idea on the "Rough Spots"
page a
> 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 goo
Leon Rosenberg wrote:
On 5/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> ValidationAware, ErrrorAware, RequestAware, ResponseAware,
> SomeOtherStuffAware... Are you kidding? I might not understand
> something (heck, I haven't started with W
>
> It is generally possible to do both, perhaps through
> a configuration switch that
> controls whether to report errors on missing message
> keys or to treat them as
> the message.
I guess I don't really care about this one... Using keys all the time would
actually be easier for me, since w
Robert Leland wrote:
Eric Molitor wrote:
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.ke
But since this class implements List and Map, it is very obvious how to
retrieve messages:
${msg}
or
${msg}
And of course we'd also provide the simpler JSP messages tags to make
that even easier. In fact, users of the UI tags won't ever have to
display messages, as they are genera
Eric Molitor wrote:
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");
Why not just:
I think this is ambiguous. In logging, you are always setting the
message. User farmiliar with log4j might think the methods below are
for setting error/messages/warnings and not obtaining them. I think the
getters and setters make more sense here.
/Ian
Eric Molitor wrote:
The new Messag
On 5/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> ValidationAware, ErrrorAware, RequestAware, ResponseAware,
> SomeOtherStuffAware... Are you kidding? I might not understand
> something (heck, I haven't started with WW yet), but if all thes
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
ValidationAware, ErrrorAware, RequestAware, ResponseAware,
SomeOtherStuffAware... Are you kidding? I might not understand
something (heck, I haven't started with WW yet), but if all these
interfaces are only meant to implement a callback met
+1 for what Don is saying.
I've been heads-down updating the new wiki, so that when the code is
ready, the documentation will be too. The material on the wiki is
generally excellent, but there are "rough spots" there too, that I've
been trying to smooth over. Accordingly, I haven't been following
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
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
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
Sent: Thursday, May 4, 2006 4:52:48 PM
Subject: Re: [action2] Public API first draft
I think this is the core decision that needs to be made right now. I'm not sure
which way I'm leaning on this, but we need to pick a direction. If we're going
to redesign the API and get things r
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
dev@struts.apache.org
Sent: Thursday, May 4, 2006 4:52:48 PM
Subject: Re: [action2] Public API first draft
I think this is the core decision that needs to be made right now. I'm not sure
which way I'm leaning on this, but we need to pick a direction. If we're going
to redesign the
> 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
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...
ly supports proposal #2, we should
discuss that proposal instead first before creating an API that supports it.
Gabe
- Original Message
From: Patrick Lightbody <[EMAIL PROTECTED]>
To: dev@struts.apache.org
Sent: Wednesday, May 3, 2006 10:01:58 PM
Subject: [action2] Public API firs
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
API that supports it.
Gabe
- Original Message
From: Patrick Lightbody <[EMAIL PROTECTED]>
To: dev@struts.apache.org
Sent: Wednesday, May 3, 2006 10:01:58 PM
Subject: [action2] Public API first draft
Bob and I have been going over the new public API proposal. It has been
designe
> 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
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&
Very cool! For the lazy, I put the Javadocs up on my space on the
apache server:
http://people.apache.org/~mrdon/action2-api/
Don
Patrick Lightbody wrote:
Bob and I have been going over the new public API proposal. It has been
designed to simplify Struts and abstract away XWork complexities
Bob and I have been going over the new public API proposal. It has been
designed to simplify Struts and abstract away XWork complexities that aren't
needed. It is far from complete, but we wanted to get some early feedback.
We'll likely be talking about this stuff a lot more during JavaOne, but
91 matches
Mail list logo
