+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
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
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
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
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
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
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
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
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.
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
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
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
[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
designed to simplify Struts and abstract away XWork complexities that aren't
needed. It is far
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
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
designed to simplify
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 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
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)
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
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
: 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 right, then lets
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
] 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 right, then lets decide to do that and
re-open WebWork to bug fixes and more
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
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
41 matches
Mail list logo
