Any other ideas for 2.3 ?
What about moving Web related classes from XWork to Struts Core ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
-
To
Only a thought, what are you thinking about moving the convention plugin into
core?
Many People don't know the convention plugin and offen i hear that Struts2
is
an old fashion XML configuration MVC Framework.
Johannes
--
View this message in context:
+1
Can we use another json parser like jackson
--Original Message--
From: Johannes Geppert
To: dev@struts.apache.org
ReplyTo: Struts Developers List
Subject: Re: Roadmap for 2.3
Sent: Mar 15, 2011 5:03 PM
Only a thought, what are you thinking about moving the convention plugin into
core
Subject: Re: Roadmap for 2.3
Sent: Mar 15, 2011 5:03 PM
Only a thought, what are you thinking about moving the convention plugin into
core?
Many People don't know the convention plugin and offen i hear that Struts2
is
an old fashion XML configuration MVC Framework.
Johannes
--
View
json parser like jackson
--Original Message--
From: Johannes Geppert
To: dev@struts.apache.org
ReplyTo: Struts Developers List
Subject: Re: Roadmap for 2.3
Sent: Mar 15, 2011 5:03 PM
Only a thought, what are you thinking about moving the convention plugin
into
core
Johannes,
I don't know, I'd prefer to keep the core the more slight as possible
(but my opinion could be biased cause I am an old fashion XML coder :)
)
On 15 March 2011 11:03, Johannes Geppert jo...@apache.org wrote:
Only a thought, what are you thinking about moving the convention plugin into
we find also using old xml is easier thatn @Action/@Result
what happen if we wanna to change the result from velocity to jsp, to jasper
the new one cannot
F
On Tue, Mar 15, 2011 at 6:25 PM, Maurizio Cucchiara
maurizio.cucchi...@gmail.com wrote:
Johannes,
I don't know, I'd prefer to keep
In development mode, using XML, you can also make real-time production
configuration changes without
needing to restart :-)
/Ian
On 03/15/2011 07:27 AM, Frans Thamura wrote:
we find also using old xml is easier thatn @Action/@Result
what happen if we wanna to change the result from velocity
And it's easier to create documentation automatically. (Not way
easier, but still.)
I guess I'd be opposed to making Convention be enabled by default,
but we could certainly make an effort to highlight in a more effective
way.
Dave
On Tue, Mar 15, 2011 at 9:30 AM, Ian Roughley i...@fdar.com
-1. I find programming by religion (or convention or whatever you want to
call it when the computer tries to guess what you mean) to be a very bad
long term decision. For small programs it works out fine, but for anything
with any scale you start to run into unimagined problems because someone
There's a tension between large-scale maintainability and small-scale
hurry! apps.
I think it's important that S2 can do both, and our documentation
should reflect its suitability for each style, and provide insight
and/or mechanisms into transitioning between the two (struts.xml from
I love annotations for a lot of things, but I also prefer the XML based
configuration for actions, interceptors, results, etc.
On Tue, Mar 15, 2011 at 12:16 PM, Dave Newton davelnew...@gmail.com wrote:
There's a tension between large-scale maintainability and small-scale
hurry! apps.
I think
+1
I've actually extended the DTD with additional configuration for security
features. The XML is easier to review for errors and ommissions because it
is centralized.
John
On 3/15/11 9:25 AM, Steven Benitez steven.beni...@gmail.com wrote:
I love annotations for a lot of things, but I also
json parser like jackson
--Original Message--
From: Johannes Geppert
To: dev@struts.apache.org
ReplyTo: Struts Developers List
Subject: Re: Roadmap for 2.3
Sent: Mar 15, 2011 5:03 PM
Only a thought, what are you thinking about moving the convention plugin
into
core?
Many
My intention is not to replace the XML Configuration. Both configurations
ways work well together.
I only like to see the convention configuration as default. Because with
Convention
Plugin it is much more easier for the user to get involved with Struts2.
And this Feature is not so well known
I'm still against having it be the default, though. If it's enabled
with a single switch, I'd be okay with that.
Dave
On Tue, Mar 15, 2011 at 3:08 PM, Johannes Geppert jo...@apache.org wrote:
My intention is not to replace the XML Configuration. Both configurations
ways work well together.
I
I'm with Dave on this one (obviously)
(*Chris*)
On Tue, Mar 15, 2011 at 12:19 PM, Dave Newton davelnew...@gmail.com wrote:
I'm still against having it be the default, though. If it's enabled
with a single switch, I'd be okay with that.
Dave
On Tue, Mar 15, 2011 at 3:08 PM, Johannes
I'm with Dave and Chris... I like the conventions plugin, but I think
it is too big of a change to make it a new default.
It could potentially be the kind of thing that we look at for Struts 3
-Wes
On Tue, Mar 15, 2011 at 3:36 PM, Chris Pratt thechrispr...@gmail.com wrote:
I'm with Dave on
If the conventions plugin allows for no XML and extensionless URLs, I'd like
to see it rolled into the and defaulted. I'm happy to endure the pain of
upgrading for those two features.
On Tue, Mar 15, 2011 at 1:43 PM, Wes Wannemacher w...@wantii.com wrote:
I'm with Dave and Chris... I like the
On Tue, Mar 15, 2011 at 3:48 PM, Matt Raible m...@raibledesigns.com wrote:
If the conventions plugin allows for no XML and extensionless URLs, I'd like
to see it rolled into the and defaulted. I'm happy to endure the pain of
upgrading for those two features.
Or you could use the plugin...
I didn't realize you could setup Struts2 without XML. That sounds fantastic
to me. I'd vote in favor of moving it to the core or at least highlighting
it in the documentation. Having to do configuration in XML is the one thing
I dislike about Struts2 despite being a longtime and happy user of
On Tue, Mar 15, 2011 at 9:13 PM, Ben McCann bmcc...@google.com wrote:
I didn't realize you could setup Struts2 without XML. That sounds fantastic
to me. I'd vote in favor of moving it to the core or at least highlighting
it in the documentation. Having to do configuration in XML is the one
Another thing to keep in mind here... The way the conventions plugin
works is that it hooks in UnknownHandlers. If conventions is to become
the new default, I think a classpath-scanning ConfigurationProvider
should be created (IMHO).
-Wes
On Tue, Mar 15, 2011 at 4:26 PM, Philip Luppens
/
-Original Message-
From: John Lindal lind...@yahoo-inc.com
Date: Tue, 15 Mar 2011 10:12:37
To: Struts Developers Listdev@struts.apache.org
Reply-To: Struts Developers List dev@struts.apache.org
Subject: Re: Roadmap for 2.3
How big is the JSON data that you are parsing?
I have heard good
Listdev@struts.apache.org
Reply-To: Struts Developers List dev@struts.apache.org
Subject: Re: Roadmap for 2.3
How big is the JSON data that you are parsing?
I have heard good reports about Jackson's performance, but we will need to
investigate whether it can support all the hooks provided
Why is JSF looking for help? Because it is superior or because it is
failing? Why there is any *shame* in choices is really beyond me. I
would like someone explain to me what JSF is doing involved with
Struts other than raiding the name and goodwill. Struts and JSF are
inherently incompatible.
Sometimes Martin just hits the nail on the head. The House of Lords
once debated putting up neon FOG signs in London for those that
could not see the obvious. We have Martin to help us. My hats are
off to this bit of very important bit of common sense.
Jack
On Wed, 29 Dec 2004 14:39:27
On Wed, 29 Dec 2004 16:28:32 -0800, Martin Cooper wrote:
Back in the day, it might have been better if we had placed
most of our taglibs with Jakarta Taglibs, rather than keep them
all here. I think this is the same sort of thing.
The problem with this theory relates to a similar issue that
On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted [EMAIL PROTECTED] wrote:
Is there anything someone would like put differently?
I'm somewhat curious when the Struts committers might be willing to
make a conscious choice for a Struts 2.x architecture.
While I'm personally going to continue to
Craig McClanahan wrote:
I believe that Struts will become
gradually less relevant for new application development unless it
adopts JSF strongly;
:-). I don't think so.
and it would be a shame to have to *compete* with
Struts instead of *being* Struts.
Why not have JSF compete with HTML tag
Funny how, every time I raise this issue, I only seem to get responses
from NON committers :-).
On Wed, 29 Dec 2004 13:08:32 -0600, Vic [EMAIL PROTECTED] wrote:
Craig McClanahan wrote:
I believe that Struts will become
gradually less relevant for new application development unless it
Objectively, I think that Shale would be a better fit for Apache MyFaces.
Back in the day, it might have been better if we had placed most of our taglibs
with Jakarta Taglibs, rather than keep them all here. I think this is the same
sort of thing.
Since I'm not doing the work, I can't make the
I'm somewhat curious when the Struts committers might be willing to
make a conscious choice for a Struts 2.x architecture.
While I'm personally going to continue to support the 1.3.x changes
for evolution of existing apps, and use of the Struts-Faces
integration library with it, I believe
Hi Ted and others,
Objectively, I think that Shale would be a better fit for
Apache MyFaces.
Uh, interessting point. I read the Shale proposal and
found it nice. I haven't tried it for now.
Back in the day, it might have been better if we had placed
most of our taglibs with Jakarta
On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted [EMAIL PROTECTED] wrote:
On Wed, 22 Dec 2004 17:21:46 -0600, Joe Germuska wrote:
I haven't felt like there's a clear consensus on how to move such a
thing forward, and I guess I'm still in ask permission mode
instead of ask forgiveness mode.
@struts.apache.org
Subject: Re: RoadMap [was Re: ViewUtils ... ]
Craig McClanahan wrote:
I believe that Struts will become
gradually less relevant for new application development unless it
adopts JSF strongly;
:-). I don't think so.
and it would be a shame to have to *compete* with
Struts
other page oriented technologies as the past. The future, as I see it,
is in highly dynamic apps
What exactly do you mean by highly dynamic? Are you referring to
applications like gmail? Do you mean XAML type applications? (God
willing they won't actually be XAML ;-) ) Or are you referring
On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted [EMAIL PROTECTED] wrote:
Objectively, I think that Shale would be a better fit for Apache MyFaces.
If the scope of the MyFaces proposal were expanded to building a JSF
implementation and value added 'stuff' around it instead of building
a JSF
On Wed, 29 Dec 2004 14:36:19 -0600, Michael Rasmussen
[EMAIL PROTECTED] wrote:
other page oriented technologies as the past. The future, as I see it,
is in highly dynamic apps
What exactly do you mean by highly dynamic? Are you referring to
applications like gmail? Do you mean XAML type
Deadman, Hal wrote:
Webstart has been around for awhile and it has its place but it's not
going to make web applications go away any time soon. I
Clients and users think that good is good looking.
So this is one future path posibility of a dynamic/futuristic
architecture, that should be easier w/
I would classify Gmail as moderately dynamic, but it's heading in
the right direction. I'm talking about things like handling wizard
page changes entirely on the client, up until Apply or OK is clicked;
drag and drop in the browser; master/detail handling within the
browser; real-time updates
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
[EMAIL PROTECTED] wrote:
[snip]
Probably a little bit off topic, but I wanted to respond to your
theory. If your theory is correct, then yes, JSF is a dead-end. I
don't agree with that theory, but I'm not sure that JSF will be the
next step
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
[EMAIL PROTECTED] wrote:
I would classify Gmail as moderately dynamic, but it's heading in
the right direction. I'm talking about things like handling wizard
page changes entirely on the client, up until Apply or OK is clicked;
drag and
Sean Schofield wrote:
I think of the browser as a
crappier version of WebStart.
;-)
Walk towards the light
I try to make my apps look like they are browser based. so people I
show it to say: Nice DHTML. :-). Yah.
This is not the old Swing, Swing Extensions in JDNC are VERY good ...
and
On Wed, 29 Dec 2004 13:59:17 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
[EMAIL PROTECTED] wrote:
[snip]
Probably a little bit off topic, but I wanted to respond to your
theory. If your theory is correct, then yes, JSF is a
On Wed, 29 Dec 2004 12:29:58 -0800, Martin Cooper wrote:
There are a few points that I don't necessarily agree with, but
they're all phrased as Consider X. I can't argue with considering
them, although I might argue against actually doing them. ;-)
Me too. But things get mentioned, so, like a
On Wed, 29 Dec 2004 12:56:35 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted [EMAIL PROTECTED] wrote:
Objectively, I think that Shale would be a better fit for Apache MyFaces.
If the scope of the MyFaces proposal were expanded to building a
On Wed, 29 Dec 2004 14:53:52 -0500, Sean Schofield
[EMAIL PROTECTED] wrote:
I'm somewhat curious when the Struts committers might be willing to
make a conscious choice for a Struts 2.x architecture.
While I'm personally going to continue to support the 1.3.x changes
for evolution of
On Fri, 2004-10-15 at 00:22, Joe Germuska wrote:
Hmmm You may be thinking of HiveMind, which is the refactored
IOC-type container that grew out of Tapestry. HiveMind is similar in
focus to Spring, but follows an approach that is similar to Eclipse.
(separation of configuration, services,
And just to be clear... I have no idea if SiteMesh is
already capable of this type thing. From what I saw it was Filter
focused. Please correct me if I'm wrong.
No, I'm pretty sure you're right there. You make some interesting
points. It seems like it would be hard to get SiteMesh involved in
Struts relies on Jakarta Commons stuff. So I think the pizza base
is only good as the quality of the ingredients on top of it.
Is there a way, for example, to get precise line error when,
say the Digester cant intercept the struts-config.xml file,
or when the underlying SAX XML Parser finds fault.
On Thu, 2004-10-14 at 20:47, Joe Germuska wrote:
Struts relies on Jakarta Commons stuff. So I think the pizza base
is only good as the quality of the ingredients on top of it.
Is there a way, for example, to get precise line error when,
say the Digester cant intercept the struts-config.xml
Hmmm You may be thinking of HiveMind, which is the refactored
IOC-type container that grew out of Tapestry. HiveMind is similar in
focus to Spring, but follows an approach that is similar to Eclipse.
(separation of configuration, services, with extension points).
No, I know about HiveMind,
On Tue, 12 Oct 2004 13:29:40 -0700, Martin Cooper wrote:
* The request may not have come from a form or a link; it may have
been submitted using an XMLHttpRequest object. In such cases, forms
as we talk about them are not relevant. Instead, we may want to
provide the request input in the form
On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote:
One more thing: Could we finally start designing to Java interfaces
into Strutssup2/sup? Ta.
interface IActionRequest { ... }
interface IActionResponse { ... }
interface IActionForward { ... }
interface IActionContext {
On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter
[EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
While I don't disagree with any of Ted's points, I do think that we
need to expand our horizons with Struts Next, rather than just provide
On Tue, 2004-10-12 at 11:27, Joe Germuska wrote:
Note that, at least with ActionConfigs, there is an important
difference between type and className. className refers to
the type of the ActionConfig itself, should you want to use a
subclass (say, for custom properties) while type refers
snip
The other thing I would add is strong debuggability. Is it true that Tapestry's web
debugging is the best of the current crop of web application frameworks?
Line precise error messages - are very useful. This however, is not
as easy with a JSP engine, given the nature of JSP (template -
While I don't disagree with any of Ted's points, I do think that we
need to expand our horizons with Struts Next, rather than just provide
more of the same. We need to move beyond the traditional web app and
embrace the next generation of web apps that have some rather
different characteristics.
On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
Another simple suggstion I would like to make (enhancement request) -
it would be extremely powerful to add the property support that
exists for plugin configuration, to action and request processors.
This can go along way for special
IMO, FWIW ...
Ted Husted [EMAIL PROTECTED] wrote on 09/03/2004 07:11:48 AM:
OK, to sum up what people seem to be saying here:
[Struts 1.2.x]
* The minimums for 1.2.3 will remain Servlet 2.2
* We create a branch at the 1.2.3 tag, in case we need to make
critical fixes to 1.2.x
On Fri, 3 Sep 2004 07:11:48 -0400, Ted Husted [EMAIL PROTECTED] wrote:
OK, to sum up what people seem to be saying here:
[Struts 1.2.x]
* The minimums for 1.2.3 will remain Servlet 2.2
* We create a branch at the 1.2.3 tag, in case we need to make critical fixes to
1.2.x later.
As I
62 matches
Mail list logo
