+1 (non binding) for Alpha
On 3/23/06, Gary VanMatre [EMAIL PROTECTED] wrote:
+1 for Alpha as well. Outside of the one known issue with the sql-browser
application, it looks good. Nice work Wendy.
Gary
-- Original message --
From: Wendy Smoak [EMAIL PROTECTED]
--- Please Note: This is a conv. I had with Craig and I cannot
access bugzilla ATM, so I'm forwarding this to the full list with
attachments.
--- This email has my first email fo Craig, his reply and at last my
new reply to both Craig and List.
/ First Email /
Dear
how this may or may not suit your needs. I hope I'm not 100%
off-base here.
Regards...djsuarez
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 5:04 AM
To: Struts Developers List
Subject: Re: [shale] Re: Struts Shale
It would be a good idea
What about a UseCase, who keeps track of the state of the
(dialog|conversation|navigation) with the user?
No need to separate in Action (behavior of a object) and ActionForm (state
of a object). Just an UseCase (oder MongoMongoBanana) to invoke its
methods via reflection (a la DispatchAction).
What about a UseCase, who keeps track of the state of the
(dialog|conversation|navigation) with the user?
No need to separate in Action (behavior of a object) and ActionForm (state
of a object). Just an UseCase (oder MongoMongoBanana) to invoke its
methods via reflection (a la DispatchAction).
Not MD_20_20_State? LOL. Anyway, I like this suggestion on any day
of the week. I think naming here is very, very important, by the way.
So much difficulty is caused by bad naming.
Jack
On Thu, 20 Jan 2005 06:04:23 -0500, Ted Husted [EMAIL PROTECTED] wrote:
It would be a good idea to name
On Wed, 19 Jan 2005 22:12:58 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
ClientState?
ViewState?
What is the lifetime? If the lifetime = x, I would suggest XState.
X ~= longer than a request, shorter than a session
:-)
Jack
Craig
Craig Wrote:
My current thinking is that we want the ability to have more than one
active dialog, so you can push from one dialog to another, then
pop back out. That's why I made it the dialog's responsibility to
clean itself up.
I don't like the fact that the dialog has to know the
On Thu, 20 Jan 2005 11:54:06 -0600, Michael Rasmussen
[EMAIL PROTECTED] wrote:
Craig Wrote:
My current thinking is that we want the ability to have more than one
active dialog, so you can push from one dialog to another, then
pop back out. That's why I made it the dialog's
snip
Craig Wrote:
My current thinking is that we want the ability to have more than one
active dialog, so you can push from one dialog to another, then
pop back out. That's why I made it the dialog's responsibility to
clean itself up.
I don't like the fact that the
The only problem I have with wizard is that it implies a serial
forwards-backwards flow. I can see cases for dialogs :-) with
branches in them. (It's the same reason I took standard next and
previous methods back out of the API ... the concept doesn't always
apply.
To me, the lifetime of the
Rabago [EMAIL PROTECTED]
Sent: Wednesday, January 19, 2005 7:37 PM
Subject: Re: [shale] Re: Struts Shale
The only problem I have with wizard is that it implies a serial
forwards-backwards flow. I can see cases for dialogs :-) with
branches in them. (It's the same reason I took standard next
In the past I've been around this merry-go-round on another Controller
implementation, the end result of that painful exercise in semantics was
the following:
1) An activity - a single node on the flow - display a page, send an
email, execute this code etc.
2) A Process - a group of activities,
ClientState?
ViewState?
What is the lifetime? If the lifetime = x, I would suggest XState.
Jack
On Wed, 19 Jan 2005 16:37:58 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
The only problem I have with wizard is that it implies a serial
forwards-backwards flow. I can see cases for dialogs
Hello Craig,
I see your point and I think you are right but there is one disadvantage
leaving the coding of the prev and next button up to the developer. Most
of the times the developers do not clean up the session when using a
dialogflow or a pageflow. This leaves a lot of garbage in the
No one is suggesting that Shale is off-topic. Using these types of remarks in a
subject line is an established courtesy on higher-traffic lists.
The Shale codebase lives here, and Struts Dev is the preferred list for posts
regarding Struts Shale.
'nuff said.
-Ted.
On Tue, 18 Jan 2005
+1, In the normal case nested process scope should be automatically
cleaned up, however, in order for that to be useful, there also has to
be sufficient metadata defining the process to map return state from
the private process (dialog) scope to the outer scope automatically,
plus of course
On Tue, 18 Jan 2005 17:14:56 +, Duncan Mills
[EMAIL PROTECTED] wrote:
+1, In the normal case nested process scope should be automatically
cleaned up, however, in order for that to be useful, there also has to
be sufficient metadata defining the process to map return state from
the private
Regarding the name dialog (which Duncan also raised in his original
post); I'm open to alternatives, but could not think of anything that
was really more evocative. I've heard some people refer to the
general idea as transaction scope, but IMHO that doesn't really
match up to what you might
On Tue, 18 Jan 2005 12:41:35 -0500, Sean Schofield
[EMAIL PROTECTED] wrote:
Regarding the name dialog (which Duncan also raised in his original
post); I'm open to alternatives, but could not think of anything that
was really more evocative. I've heard some people refer to the
general idea
Duncan Mills seems to characterize this as PrivateProcess. Something
like that seems far more didactic and helpful to me than something it
really is not, like Dialogue or Conversation. My suggestion is that
the name reflect precisely what it is.
Jack
On Tue, 18 Jan 2005 13:10:54 -0600, Hubert
Dakota Jack [EMAIL PROTECTED] wrote:
Duncan Mills seems to characterize this as PrivateProcess. Something
like that seems far more didactic and helpful to me than something it
really is not, like Dialogue or Conversation. My suggestion is that
the name reflect precisely what it is.
Perhaps
I almost suggested the same thing: conversation. Its length,
though, could be unfriendly. ConversationController.
What about dialogue with the ue at the end?
What about wizard? This is what we call our own custom solution
that we're using now. Wizard generally implies a guided series of
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
My personal itch is to not have to build everything from scratch --
its to build on the JSF request processing lifecycle, without
committing you to any particular view tier templating approach.
Doing more work than that is ... more
How could there be a reason not to do this? (This is not a rhetorical
question.)
Jack
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote:
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
My personal itch is to not have to build everything from scratch --
its
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote:
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
My personal itch is to not have to build everything from scratch --
its to build on the JSF request processing lifecycle, without
committing you to any
Why is it not possible for the framework to use interfaces into which
JSF can be plugged in, perhaps with adapters, as an option well as
other alternatives? This too is not a rhetorical question.
Jack
On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote:
On Thu, 28
I think that's Ted's basic point.
My answer is to consider how much extra machinery you have to build in
to the Struts abstraction of what a ViewController is so that an
application built on top of Struts can use different technologies.
Just as one example out of my list from the previous email
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted wrote:
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
My personal itch is to not have to build everything from scratch --
its to build on the JSF request processing lifecycle, without
committing you to any particular view
I admit to a huge amount of ignorance about JSF. I have partly been
stymied by an inability to decide on a text to read. I have always
liked Hans work, and may go that direction. I cannot know, of course,
how that ignorance impacts my part in this discussion. I do think
that in any event it is
19:40
To: Dakota Jack; Struts Developers List
Subject: Re: Struts Shale
I think that's Ted's basic point.
My answer is to consider how much extra machinery you have to
build in to the Struts abstraction of what a ViewController
is so that an application built on top of Struts can use
19:40
To: Dakota Jack; Struts Developers List
Subject: Re: Struts Shale
I think that's Ted's basic point.
My answer is to consider how much extra machinery you have to
build in to the Struts abstraction of what a ViewController
is so that an application built on top of Struts can use
3.1 Java2 Standard Edition APIs
I'd be +1 for J2SE 5.0
Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I
would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should
be widely deployed by then. If not, then our endorsement of it could
encourage people to
3.1 Java2 Standard Edition APIs
I'd be +1 for J2SE 5.0
Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I
would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should
be widely deployed by then. If not, then our endorsement of it could
encourage people to
On Thu, 28 Oct 2004 15:27:49 -0700, Dakota Jack [EMAIL PROTECTED] wrote:
I admit to a huge amount of ignorance about JSF. I have partly been
stymied by an inability to decide on a text to read. I have always
liked Hans work, and may go that direction. I cannot know, of course,
how that
On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein
[EMAIL PROTECTED] wrote:
3.1 Java2 Standard Edition APIs
I'd be +1 for J2SE 5.0
Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I
would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should
be
At 3:27 PM -0700 10/28/04, Dakota Jack wrote:
I admit to a huge amount of ignorance about JSF. I have partly been
stymied by an inability to decide on a text to read. I have always
liked Hans work, and may go that direction. I cannot know, of course,
how that ignorance impacts my part in this
Craig is starting from his knowledge of JSF and proscribing it as a
facility for providing a lot of functionality to Shale.
er... prescribing. Sorry.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote:
URL: http://wiki.apache.org/struts/StrutsShale
A few more more notes.
2.4 View Controller
3.3 View (Presentation) Tier APIs
Proposal:: JavaServer Faces 1.1
Does the View Controller need to be tied to JSF?
Could the interface be
I would be +1 for 1.5 as well
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message -
From: Ted Husted [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 1:14 AM
Subject:
I'm +1 for 1.5 as well, but from memory I believe there were people who
didn't want to be that bleeding edge.
Niall
- Original Message -
From: James Mitchell [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 4:16 PM
Subject: Re: Struts Shale
Just time for a couple of notes this morning.
I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this
is going to take. The struts core part of this isn't really huge or
complicated, but asking a Struts developer for a timeline is probably
a silly thing to do :-).
Other comments
At 5:32 PM +0100 10/26/04, Niall Pemberton wrote:
I'm +1 for 1.5 as well, but from memory I believe there were people who
didn't want to be that bleeding edge.
Or those who use a lovely operating system whose own Tiger release is
still several months away, with no plans for Java 5.0 support
- Original Message -
From: Sean Schofield [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 6:35 PM
Subject: Re: Struts Shale
I'm +1 on JDK 1.4 (+0 on JDK 1.5).
I also agree with Craig's sentiments on keeping
At 7:02 PM +0100 10/26/04, Niall Pemberton wrote:
I'm all for taking JSF faces strongly into account, but the proposal seems
to be *JSF only* for the view tier - to the exclusion of all others. Since I
haven't tried out JSF yet and therefore don't know enough about it that
makes me uneasy.
Seems
Niall Pemberton wrote:
I'm all for taking JSF faces strongly into account, but the proposal seems
to be *JSF only* for the view tier - to the exclusion of all others. Since I
haven't tried out JSF yet and therefore don't know enough about it that
makes me uneasy.
Is this correct? I did get that
intended as an initial
*musing*.
Niall
- Original Message -
From: Michael Rasmussen [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 7:03 PM
Subject: Re: Struts Shale
Some people already moan that struts is too jsp orientated with
the tags
Subject: Re: Struts Shale
Niall Pemberton wrote:
I'm all for taking JSF faces strongly into account, but the proposal
seems
to be *JSF only* for the view tier - to the exclusion of all others.
Since I
haven't tried out JSF yet and therefore don't know enough about it that
makes me uneasy
Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 7:03 PM
Subject: Re: Struts Shale
Some people already moan that struts is too jsp orientated with
the tags that are included
I'm not trying to tip the discussion in any direction here, but I
thought I would point out that JSF
- Original Message - From: Michael Rasmussen
[EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 7:03 PM
Subject: Re: Struts Shale
Some people already moan that struts is too jsp orientated with
the tags that are included
I'm not trying
Niall Pemberton wrote:
OK Craig didn't say it was JSF only - but that was my interpretation of
the likely direction.
He said The interface as currently defined is not dependent on JSF but
then went on to say that JSF already solves a whole load of the view tier
issues and re-inventing them outside
On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
Niall Pemberton wrote:
OK Craig didn't say it was JSF only - but that was my interpretation of
the likely direction.
He said The interface as currently defined is not dependent on JSF but
then went on to say that
On Tue, 26 Oct 2004 19:40:59 +0100, Niall Pemberton wrote:
OK Craig didn't say it was JSF only - but that was my
interpretation of the likely direction.
Something to consider is that we are not constrained to a single line of development.
We could proceed with Struts Shale as a subproject
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan [EMAIL PROTECTED] wrote:
* The proposed Struts Core doesn't contain or use any
JSF components -- it presumes the use of the infrastructure
stuff (managed beans, expressions, navigation mapping,
as well as the basic request processing
not :-)
Eddie
- Original Message -
From: Michael Rasmussen [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 1:03 PM
Subject: Re: Struts Shale
Some people already moan that struts is too jsp orientated with
the tags that are included
I'm not trying
: Struts Shale
At 7:02 PM +0100 10/26/04, Niall Pemberton wrote:
I'm all for taking JSF faces strongly into account, but the proposal seems
to be *JSF only* for the view tier - to the exclusion of all others. Since
I
haven't tried out JSF yet and therefore don't know enough about it that
makes me
56 matches
Mail list logo
