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 unsubscribe,
> Date: Tue, 15 Mar 2011 10:12:37
> To: Struts Developers List
> Reply-To: "Struts Developers List"
> 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
&g
/
-Original Message-
From: John Lindal
Date: Tue, 15 Mar 2011 10:12:37
To: Struts Developers List
Reply-To: "Struts Developers List"
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
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
wrote:
>
On Tue, Mar 15, 2011 at 9:13 PM, Ben McCann 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 thing
> I dislike
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 th
On Tue, Mar 15, 2011 at 3:48 PM, Matt Raible 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...
The way I see it, the
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 wrote:
> I'm with Dave and Chris... I like the conventions plug
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 wrote:
> I'm with Dave on this one (obviously)
> (*
I'm with Dave on this one (obviously)
(*Chris*)
On Tue, Mar 15, 2011 at 12:19 PM, Dave Newton 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 Geppert
> 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 Geppert wrote:
> My intention is not to replace the XML Configuration. Both configurations
> ways work well together.
>
> I only like to
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 by
both?
>>
>> On 15 March 2011 11:47, wrote:
>>> +1
>>> Can we use another json parser like jackson
>>>
>>>
>>> --Original Message--
>>> From: Johannes Geppert
>>> To: dev@struts.apache.org
>>> Reply
+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" wrote:
> I love annotations for a lot of things, but I also prefer the XML based
>
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 wrote:
> There's a tension between large-scale maintainability and small-scale
> "hurry!" apps.
>
> I think it's important
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
annotation
-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
na
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 wrote:
> In dev
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 velocit
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
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 wrote:
> Only a thought, what are you thinking about moving the convention plugin into
> core?
>
> Man
; > 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
&g
When you talk about jackson parser you mean serialize, deserialize, both?
On 15 March 2011 11:47, wrote:
> +1
> Can we use another json parser like jackson
>
>
> --Original Message--
> From: Johannes Geppert
> To: dev@struts.apache.org
> ReplyTo: Struts Devel
+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
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:
http://struts.1045723.n5.nabble.com/Road
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 i
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 -080
How can Struts which is inherenlty incompatible with JSF be a "better
fit" than MyFaces which is a JSF implementation? I would prefer
Darwin rather than Machievelli resolve the Struts v. JSF choice and
think that Ted as usual is right on the mark.
Jack
On Wed, 29 Dec 2004 12:56:35 -0800, Craig
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.
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 evolut
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 "bu
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, lik
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
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 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;
> >
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
> 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 u
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
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
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
> 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 referri
gt; Sent: Wednesday, December 29, 2004 2:09 PM
> To: dev@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
> >adopt
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 forgivene
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 Ta
> 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 beli
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
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 i
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 libs?
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
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
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, se
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, alt
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
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.
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 13. oktober 2004 16:13
> To: Struts Developers List
> Subject: RE: Roadmap
>
> On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote:
> > I think we need to define a feature common de
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 13. oktober 2004 16:13
> To: Struts Developers List
> Subject: RE: Roadmap
>
> On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote:
> > I think we need to define a feature common de
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 ju
On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote:
> One more thing: Could we finally start designing to Java interfaces
> into Struts2? Ta.
>
> interface IActionRequest { ... }
> interface IActionResponse { ... }
> interface IActionForward { ... }
>
> interface IActionContext {
> IAc
> -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
> more of the same. We need to move beyond the traditional web app and
> emb
> -Original Message-
> From: Mike Stanley [mailto:[EMAIL PROTECTED]
>
>
> > 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 u
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 fo
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. Fo
> 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 ->
Ted Husted wrote:
To follow up some other threads about the "architectural vision" for Struts Next, I'd
like to
offer the following:
Most of us are torn whether to create Struts Next by evolution or revolution. I think
what
most of us revolutionaries really want to to create Struts Next by m
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) wh
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 to the
type of the Action which will be created
Joe Germuska wrote:
At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
Ted Husted wrote:
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 confi
At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
Ted Husted wrote:
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
Ted Husted wrote:
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
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 speci
quick thoughts/suggestion - my pizza just came ;-)
* Action Form - Form Context
How about adopting XForms (http://www.w3.org/MarkUp/Forms/) as the model
for all Action Forms? This contains a model for representing everything
you spoke about in your email - basically the seperation of purpose
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
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
73 matches
Mail list logo
