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
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
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
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
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
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
> 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
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
>
> 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
+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
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
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.
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 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
42 matches
Mail list logo
