+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 PRO
--- 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 C
(Note - since viewcvs is currently not working against the SVN
repository, I've posted the original Shale proposal directly at:
http://www.apache.org/~craigmcc/struts-shale-README.html
It has details relevant to the questions below.)
On Fri, 21 Jan 2005 08:05:31 -0600, David Suarez
<[EMAIL PR
ou're passed a scope as part of the execute method to make it clear that
any of the work you do is limited to whatever the configuration scope is
(handled as part of config).
Please advise how this may or may not suit your needs. I hope I'm not 100%
off-base here.
Regards...djsuarez
--
> > 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 lik
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'
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 ha
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
-
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 nam
It would be a good idea to name both the set and the member at the same time.
Some suggestions
* Activity and Task
* Circuit and Gate
* Track and Step
* Process and Node
which leads to conjugations like
* ActivityState
* CircuitState
* TrackState
* ProcessState
If this were Friday, I might add
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).
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 dia
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,
ers List" ; "Sean Schofield"
<[EMAIL PROTECTED]>
Cc: "Hubert 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-backward
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 t
> 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 se
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.
Per
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
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
> > g
> 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 yo
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 p
+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 t
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 06:48:37
I have to smile at the suggestion that "[shale]" will be a substitute
for "OT" so that Struts developers will not be burdened by these JSF
discussions. That is exactly the sentiment of Rod Johnson in "J2EE
Development without EJB". I also agree. What could be more ironic
than a proposed future o
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 sessio
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
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 di
> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein
> <[EMAIL PROTECTED]> wrote:
> >
> > 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
> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein
> <[EMAIL PROTECTED]> wrote:
> >
> > 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
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
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
>
> > 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 peo
>
> > 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 peo
CTED]
> Sent: 28. oktober 2004 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
CTED]
> Sent: 28. oktober 2004 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
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
The focus of the visual component base solution
would be to create a XML definition, backed
beans, and an abstract factory/ cache to manage
the resources. Create a view controller or
action class that knows how to use the metadata
to manage corresponding model classes. And view
helpers that
> 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 part
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 .
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
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
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 --
>
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 ... mo
List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 26, 2004 1:04 PM
Subject: Re: 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 o
.
2 cents, 4 cents, 6 cents ... a dollar! er ... maybe 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 p
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 processin
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 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 we
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 outs
y 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 s
smussen" <[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 to t
uts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 26, 2004 7:21 PM
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 exclusi
try JSF out and this was only 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
>
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 th
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 to
need to go and
> actullay try JSF out.
>
> Niall
>
>
>
> - Original Message -
> From: "Sean Schofield" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, October 26, 20
gey I need to go and
actullay try JSF out.
Niall
- 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 things as simple as
possible and not reinventing what JSF (and other frameworks) can do
for you.
The more I look at JSF, the more impressed I am with it. In many ways
it seems to be a signifcant improvement upon
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 before
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
sday, October 26, 2004 4:16 PM
Subject: Re: Struts Shale
> 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" <
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
> 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 interfac
64 matches
Mail list logo
