I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Niall Pemberton <[EMAIL PROTECTED]> wrote: On 6/29/06, Don Brown wrote:
>
> I like struts1/struts2.
+1
Niall
> Don
-
On 6/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like struts1/struts2.
+1
Niall
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi
Great news :)
Hermod
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Martin Cooper
Sent: Thursday, June 29, 2006 12:11 AM
To: announcements@struts.apache.org; user@struts.apache.org; Struts
Developers List
Subject: [ANNOUNCEMENT] Shale to Become Top-Leve
On 6/28/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Ted Husted wrote:
> > Though, there's no reason why we couldn't use
> >
> >> repos/asf/struts/struts1
> >> repos/asf/struts/struts2
> >
> > Or
> >
> >> repos/asf/struts/framework
> >>
Hi ,
Iam developing application in struts which has login page and
when username and password are given it should be authenticated and
the page should be switched to https
I had made necessary changes to include
and login-config to include the user properties
but the
/display.jsp
/error.jsp
i
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ted Husted wrote:
> Though, there's no reason why we couldn't use
>
>> repos/asf/struts/struts1
>> repos/asf/struts/struts2
>
> Or
>
>> repos/asf/struts/framework
>> repos/asf/struts/framework2
I like struts1/struts2.
Yep, I do too. It
Michael Jouravlev wrote:
If this "not caring about any of that" is anything like ASP.NET
coding, that this is not exactly true. Like, in ASP.NET there is a
well-defined lifecycle. But if you (well, me) wants to get rid of
POSTDATA situation, you need to call Response.redirect explicitly from
even
On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Michael Jouravlev wrote:
> From webapp
> point of view, Command is as bad as Action. Meaning that HttpServlet
> has doGet() and doPost() and therefore forces people to think what
> kind of request they are processing and what method is bett
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
Why does having the departure of Shale instigate nomenclature madness? :-)
Struts Action Framework is actually a very professional title and I prefer we
keep it as is.
When Shale arrived, we tried various ways to differentiate the
original
Paul Benedict wrote:
I have two concerns on the 1.3.x line. What do you think?
1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular,
the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into
the actions as they are created. This su
Paul, not related to your issues (and I do not have answer/opinion on
them), but more related to the message header: see more 1.3
issues/features/questions here:
http://wiki.apache.org/struts/SAF1RoughSpots
I don't know what is the best place to discuss all this stuff, here or
in Wiki. I am ok wi
That's a good point Michael. My answer to it would be that it's just
something we have to live with.
Paul used the term "generation" to differentiate Struts 1.x from 2.x...
to me though, "generation" has the same connotation as does "classic".
I don't think there's any real contradiction tho
My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me. I
look at them in terms of generations; different people who can live together in
one family (webapp).
Michael Jouravlev <[EMAIL PROTECTED]> wrote: In this case we are returning to a
half-year old situation, that is,
Stru
In this case we are returning to a half-year old situation, that is,
Struts 2 is a new crown holder of a single unified project. Consider
the announcements like this:
"Struts team is proud to announce immediate availability of Struts 2.0
as a next version of popular Struts framework. New features
I have two concerns on the 1.3.x line. What do you think?
1) Spring 2.0 has fabulous support for dependency injection for Struts. In
particular, the great Autowiring(Tiles)RequestProcessor will automatically
inject dependencies into the actions as they are created. This supports the
"legacy" Re
I temporarly withdrawl the proposal. It cannot be well represented until there
is a component like view of the action classes, which you are proposing. If
your stuff gets accepted, then perhaps I can add onto it. But until then...
Paul
Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/27/06, Mi
Michael Jouravlev wrote:
Command is only better because it does not throw HTTP stuff right in
one's face.
Precisely the point :)
> Is it really better? Maybe just for testing.
Not just for testing... wouldn't it be great if you could take that same
controller code, the code that really form
I am very much against naming 1.x "Classic" . I think it's a horrible name. I
think of classical music, classic cars, and anything that smells of belonging
in a museum (stationary, old, idle, doesn't move, better looked at than used).
Why do we need it? I am totally fond of action and action2. W
I propose code names Velvet and Rubert. Any objections?
Michael Jouravlev <[EMAIL PROTECTED]> wrote: Mua-ha-ha :-))
+1 on renaming back.
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases. This had been suggested and
discussed long ago but
Niall's response has softened my position on the built-in action dispatching.
In my own projects, I went ahead and created a common BaseAction which all my
other actions extend from. The BaseAction uses EventDispatcherAction with a
pre-written execute method for the dispatching; subclasses just
Did I miss something? :-) Perhaps the deliberations went on in private, because
it's news to me!!! Congrats on Shale blossoming into its own project.
Don Brown <[EMAIL PROTECTED]> wrote: With the departure of Struts Shale, I
think it is time we return to the idea of
Struts as a single, unified
I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1,
etc... The whole point of this proposal is to unify Struts as a single project,
getting away from this concept of separately versioned "subprojects". There
will be Struts 1.x releases, and there will be Struts 2.x rele
You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts
2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version
4.0
:-)
2.0 is a version number, while we are choosing project names (Are we?)
Do we treat Struts2 as the next version, or do we treat Struts and
Struts2 as
Ted Husted wrote:
Though, there's no reason why we couldn't use
repos/asf/struts/struts1
repos/asf/struts/struts2
Or
repos/asf/struts/framework
repos/asf/struts/framework2
I like struts1/struts2.
Don
-Ted.
-
Big +1. I just wish we could have done it months ago when I (and
others) said exactly the same thing. Oh well, better late then never.
Frank
Don Brown wrote:
With the departure of Struts Shale, I think it is time we return to the
idea of Struts as a single, unified framework. While I had ho
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> What do you think of...
>
> repos/asf/struts/struts
> repos/asf/struts/struts2
Very true, I forgot that we have different directories for SAF1 and SAF2. The
struts/struts is redundant, but I could live with that.
But ViewVC might not :)
+1 for Struts 2.0
Bob
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
With the departure of Struts Shale, I think it is time we return to the
idea of
Struts as a single, unified framework. While I had hoped we could do this
by
including Shale, everyone involved felt Shale deserved its own pr
I'm against "official" code names. We have had enough confusion in Struts with
different names meaning different things, and we shouldn't pile on more names.
If folks want to off-hand use code names, that's fine, but to have them used in
code or documentation is too far. Version 1 and 2 are si
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases.
If we were to do that, the obvious choices would be Classic for 1.x
and Action for 2.x.
-Ted.
--
Wendy Smoak wrote:
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
2. We rename the https://svn.apache.org/repos/asf/struts/action
subversion
directory as https://svn.apache.org/repos/asf/struts/framework, keep
the other
top level directories the same
What do you think of...
repos/asf
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
2. We rename the https://svn.apache.org/repos/asf/struts/action subversion
directory as https://svn.apache.org/repos/asf/struts/framework, keep the other
top level directories the same
What do you think of...
repos/asf/struts/struts
repos
Mua-ha-ha :-))
+1 on renaming back.
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases. This had been suggested and
discussed long ago but was rejected.
Why codenames make sense:
* Job search. SAF1 and SAF2... oh... I mean, Struts 1.x and
On 6/28/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
I haven't read Michaels latest write up, so I don't know if its
substantially different, but last time I looked the only reason for
integrating the "dispatch" style into Action was (IMO) to encourage
its use.
If thats still true then my opini
With the departure of Struts Shale, I think it is time we return to the idea of
Struts as a single, unified framework. While I had hoped we could do this by
including Shale, everyone involved felt Shale deserved its own project and so
I'm adjusting my original Struts 2.0 proposal to simply rena
Martin Cooper wrote:
On behalf of the ASF Board and Struts PMC, we are pleased to announce that
Shale has been accepted as a top-level project of the Apache Software
Foundation.
As a top-level project, Shale will have its own website, mailing lists,
repository space, and Project Management Commi
On behalf of the ASF Board and Struts PMC, we are pleased to announce that
Shale has been accepted as a top-level project of the Apache Software
Foundation.
As a top-level project, Shale will have its own website, mailing lists,
repository space, and Project Management Committee. Shale will be an
The restriction comes from the Java relection API semantics, not OGNL. A
property can only have one type, so it makes sense that the getter and
setter for a JavaBean property must agree on that type. Changing this
would break compatibility with the JavaBean specification, at the least...
L.
I
I haven't read Michaels latest write up, so I don't know if its
substantially different, but last time I looked the only reason for
integrating the "dispatch" style into Action was (IMO) to encourage
its use. If thats still true then my opinion is unchanged:
http://marc.theaimsgroup.com/?l=struts
I'm on the same page as Hubert, as an outsider... I totally see this as
being a worthy "extras", and probably something a lot of people would
use, but integrated into the core, it just doesn't feel right to me.
Frank
Hubert Rabago wrote:
I like the functionality that this provides. If I ever
I like the functionality that this provides. If I ever get to work on
another Struts 1 project, I would certainly like to use this. That
said, I'm -0 to integrating it, but I won't stand in the way if other
committers accept it. I think though that it works well enough
without being integrated
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Integrating html2 would be nice too. It uses Ajax as well, so the two
engines can be combined into one.
In relation to html2, I am curious about how important client-side
validator is. I mean, comparing Ajax roundrip to amount of Javascri
On 6/28/06, bhanu_gulbarga <[EMAIL PROTECTED]> wrote:
Iam developing application in struts ...
Please post your question on the user list.
See: http://struts.apache.org/mail.html
Or, since your message footer indicates that you're using Nabble:
http://www.nabble.com/Struts---User-f206.html
Hi ,
Iam developing application in struts which has login page and
when username and password are given it should be authenticated and
the page should be switched to https
I had made necessary changes to include
and login-config to include the user properties
but the
/display.jsp
/error.js
Michael Jouravlev wrote:
In relation to html2, I am curious about how important client-side
validator is. I mean, comparing Ajax roundrip to amount of Javascript
preloaded for client-side validation, does it really make sense? And
if a form is filled out correctly, this validator code is not used
Iam devloping sample login application in struts
which should switch to https if the credential are correct
i made the necessary modification in web.xml to contain
the form-auth parameters and in the login-config.xml
I have made necessary modifcations
props/web-console-users.properties
but the p
Paul, thanks for the warm support, I really appreciate it! Well, I
cannot thank you more, my ears are all red :-)
In any case, I think we can wait until 1.3.5 goes GA before making a
final decision about where this code belongs. In the meantime I will
continue working on it.
Integrating html2 wo
46 matches
Mail list logo
