Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by AndrewKuzmin:
http://wiki.apache.org/struts/Shale
--
*
+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
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
On 5/4/06, Martin Cooper [EMAIL PROTECTED] wrote:
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
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 these
My understanding was that we may vote a relase as beta initially if,
for example, it has alot of new functionality and then if no issues
come up vote again to upgrade the quality to GA.
Whats happened so far since this was introduced was that either
releases have been voted GA straight away
Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in the
future. Wouldn't it be more correct to deprecate all the protected
methods (e.g. processActionCreate(), processActionForm etc.)?
Perhaps we should consider what the
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
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:
-- Forwarded message --
From: Niall Pemberton [EMAIL PROTECTED]
Date: May 5, 2006 2:36 PM
Subject: Re: SAF 1.3.x and legacy RequestProcessor
To: Joe Germuska [EMAIL PROTECTED]
On 5/5/06, Joe Germuska [EMAIL PROTECTED] wrote:
Its probably academic, but since CRP extends RP then
At 3:03 PM +0100 5/5/06, Niall Pemberton wrote:
On 5/5/06, Joe Germuska [EMAIL PROTECTED] wrote:
Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in the
future. Wouldn't it be more correct to deprecate all the
But since this class implements List and Map, it is very obvious how to
retrieve messages:
c:forEach var=msg items=${msgs}
li${msg}/li
/c:forEach
or
c:forEach var=msg items=${msgs['fooField']
li${msg}/li
/c:forEach
And of course we'd also provide the simpler JSP messages tags to make
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.key);
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 we
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 WW
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
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 about
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);
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:
c:forEach var=msg items=${msgs}
li${msg}/li
/c:forEach
or
c:forEach var=msg items=${msgs['fooField']
li${msg}/li
/c:forEach
Which class implements List
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
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:
c:forEach var=msg items=${msgs}
li${msg}/li
/c:forEach
or
c:forEach var=msg items=${msgs['fooField']
li${msg}/li
/c:forEach
Which
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
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 and
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 problem for
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
Hello all,
My name is Brian Dittmer. I'm a third year Computer Science and
Engineering student at The Ohio State University and plan on applying
for the Google Summer of Code project and work on the Struts Ti
project. I've already talked with Patrick about some of my ideas but he
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 from
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
From: Niall Pemberton [EMAIL PROTECTED]
Date: May 5, 2006 2:36 PM
Subject: Re: SAF 1.3.x and legacy RequestProcessor
On 5/5/06, Joe Germuska [EMAIL PROTECTED] wrote:
Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in
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
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
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
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,
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
Struts Action 1.3.2 has received the following votes:
Beta - Don Brown, Wendy Smoak, Martin Cooper, James Mitchell
Alpha - Ted Husted
Therefore, Struts Action 1.3.2 will be designated Beta quality. If
I have a chance, I'll sign the releases and make it available on the
web page to prompt more
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
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 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
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
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,
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. (JSF makes
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
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
populate a table,
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 their
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
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
instead
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.
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier (to
me).
- The attached version supports arbitrary levels. I
used an interface
instead of an enum so the user can define additional
levels if
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
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)
I'm cool with that. Sticking with verbs, there's also err(), warn(),
inform(). ;)
Bob
On 5/5/06, Jason Carreira [EMAIL PROTECTED] wrote:
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier (to
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
On 5/5/06, Jason Carreira [EMAIL PROTECTED] wrote:
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier
(to me).
I can see how verbs make the code easier to *read*, but not sharing a common
prefix
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
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
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
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/Shale/UserDocs
The comment on the change is:
Added a link for Clay
To err is human... do not lightly give this power to web applications ;-)
I'm cool with that. Sticking with verbs, there's also
err(), warn(),
inform(). ;)
-
Posted via Jive Forums
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
--- 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 to be
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
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2. Backwards-compatibility support for WebWork 2 and Struts 1.x
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
New page:
Describe ShaleClay here.
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2.
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
The comment on the change is:
Adding Debugging Tips
Michael Jouravlev wrote:
SAF1 could have future if migration to SAF2 were impossible or too
complicated. But according to your plan, migration from SAF1 to SAF2
should take days. What is the point of keeping Action 1.x to be
developed actively?
I am not objecting, I am just asking. Trying to
Just as some people continue to use WebWork 1.xx (JIRA) I imagine
people will continue to use SAF1 regardless of how easy the migration
path is.
I always assume it would take a day or two to convert existing WW code
to SAF2 so at the end of the day just picking a direction is progress.
:)
I'm OK with this, from an end user perspective certainly, and from a
(sort of I guess) framework developer as well.
However, you raise an interesting point in my mind...
Struts Action 1.x will continue to be developed actively
Ok... I personally like that. However, why wouldn't it also be
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
New page:
== Incorrect public id ==
=== Problem ===
When running a web application
Don,
Thanks for drawing up a proposal. I suggest allow ample discussion time before
this is called to a vote.
Where XWork is in this proposal is a little vague. Would this proposal break
the traditional division of roles between XWork and Webwork (Where SAF 2 is
where webwork was)? If so, how
If the WebWork committers make the decision to continue developing WebWork 2.x,
they are entirely free to do so. If Struts Action 1 committers decide to
continue developing Action 1, they are also free to do so. However, if WebWork
2 developers decide to stop work and focus completely on
Gabe wrote:
Where XWork is in this proposal is a little vague. Would this proposal break
the traditional division of roles between XWork and Webwork (Where SAF 2 is
where webwork was)? If so, how so? Is this proposing that there be an adapter
layer in SAF 2 to access XWork APIs? Would we be
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
--
+
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
--
- Describe
My company, Autoriginate (http://www.autoriginate.com), has donated a free
HostedQA account to all Struts developers who request one. The account is
available at https://struts.hostedqa.com. Just speak up if you want an account
and I'll set you up.
So what does this get us? I've already
Don Brown wrote:
The purpose of this merger is not to create yet another framework or
kill off competition, but to start collaborating as framework developers
for the greater good of the general community. By focusing on who can
do what or why can't a project release something, you are
I am all for simplifying the API to the end developer, but I wonder if those
changes could be pushed to XWork in the form of an XWork 2.0, with, of course,
the Web specific portions being added to SAF 2. I see the reasoning behind
creating a layer to hide XWork (everything the user uses is
Gabe wrote:
I am all for simplifying the API to the end developer, but I wonder if those
changes could be pushed to XWork in the form of an XWork 2.0, with, of course,
the Web specific portions being added to SAF 2.
Agreed, and with my XWork developer hat on, XWork 2.0 will be required to
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
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
This sounds fine to me, Don.
I'd suggest annexing this to the original Ti proposal as a clarification.
-Ted.
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
But that's precisely my point... isn't the best way to combine the
talents to take the cuffs off, so to speak, and not worry about
backwards-compatibility?
Yes, and this is why the Ti proposal talks about two phases.
In the first phase,
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will probably
want to migrate despite
Michael Jouravlev wrote:
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community
is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will
On 5/5/06, Phil Zoio [EMAIL PROTECTED] wrote:
Michael Jouravlev wrote:
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community
is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a
Ted, I think that your statement is one of the things that needs to be
discussed. There is the camp that says The first SAF 2.0 release should have
a solid API that will be usable for a long time. The second group says that
The first SAF 2.0 release should basically be WW 2.2 with some minor
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 the merger comes
On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
The current versioning/naming system will force them, because it does
not make distinction between Classic and WebWork. Most users and/or
their managers know that higher version number means newer and better
product. Which is why I preferred
I am a struts user who has recently began programming in webwork, to get
a head start for action 2. Having just spent many hours researching,
reading about and experimenting with webwork, I personally hope that you
start with a version of action 2 that resembles webwork pretty closely.
I wonder
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/WhyChain
The comment on the change is:
Added some pictures (will need to refactor the chain docs)
Our JIRA instance is showing a stack trace on the dashboard.
I opened a ticket for it: http://issues.apache.org/jira/browse/INFRA-789
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
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
RESULT
+1 - 6 (binding)
I'm publishing it now...
Thanks,
Wendy
92 matches
Mail list logo
