Re: JerichoFaces ?

2004-11-21 Thread Dakota Jack
Craig,

I not only have no technical arguments against a View Helper design
pattern, but the suggestion on the Wiki WhiteBoard for Struts both for
the JerichoData and the JerichoFaces is an instance of advocating such
a design pattern.  What I don't trust is the page based controller.

Jack

>Personally, I'm underwhelmed by the technical arguments made against a
>View Helper design pattern so far, so I'm not particularly interested
>(personally) in Jericho or JerichoFaces as a solution to anything --
>but who knows, some of the other developers might be.


-- 
"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Repost: JerichoFaces ?

2004-11-21 Thread Vic Cekvenich
:
Hopefully the current proposal of moving Shale to MyFaces get accepted 
there. It makes it less confusing.

Strut's current focus is on Sturts-Chain, CoR and command pattern:
ActionCommand - A Chain Command-like interface with one method:
   Execute(ActionContext context)
A context is just a map.
.V
Eddie Bush wrote:
I think Joe makes a good point.  Shale is what we have as a possible 
direction ... and it's being fleshed out.  Jerico, better or worse, I 
don't think is.

At this point, we're probably better to "put our code where our 
mouths are", if we don't like the direction things are headed.


You know, when I was a kid, I thought life was fantastic, save for 
the nights I absolutely forced my dad to blister my bottom to make me 
go to bed (kids ... it's their job) - it was so simple!  After 
several years though, I got a few more years on me and daddy just 
kept making me behave more and more!  Argh!  Life wasn't quite as 
simple anymore :-(  I had more responsibilities and more expectations 
laid on me.

Hey!  That kinda sounds like Struts, doesn't it?  Hrm ... You know, 
I'm losing my hair, and I don't look like I used to either.  Heck, 
I've gained a good 20 pounds since I was in college - and we won't 
talk about since Highschool!


:-)
Struts is kind of Craig's baby.  I think it's pretty suitable that he 
make his baby grow up to prepare it for the big bad world.  As with 
any parent, all he can do is steer it in the direction he feels is 
right.  A parent *is* morally obligated to teach their children the 
best they can, after all.

All I'm saying is that instead of casting all the dissenting remarks, 
we should recognize that Craig has put his best foot forward (People 
kinda thought he was nuts when he started Struts, if I remember the 
stories).  If a person has an implementation to put along-side of 
what he's got then I don't think it'd be real hard to do some 
comparison shopping, but it's pretty hard to comparison shop without 
something to compare to.  Duh? Hehehe ...

Maybe I'm too trusting, but having observed Craig's comments on shale 
and JSF and the pieces of JSF that "Shale proposes to depend upon", 
and realizing that he's in a very select, choice position so far as 
perspectives are concerned, I'm inclined to trust the guy.  ... 
especially when he keeps saying, "It'll be alright" (basically) and 
all the people that have something negative to say about Shale have 
to chip-in "... but I'm really not familiar with Faces".

So far as Hans' comment goes.  Whose word are you going to take?  
You've got a choice between Hans, who is certainly a sharp cookie, 
and Craig.  Hans is a bright guy who has done his homework and 
written us some fine literature ... and Craig is out there setting 
the tone for JSF ... oh, wait, Craig pretty well set the tone for 
Struts too - he invented it!

... my money is on Craig ... :-)
Peace ;-)
Eddie
P.S. - There's nothing wrong with discussion.  Discussions generally 
have two sides though, and most of what I've heard about Shale here 
is pretty one-sided.  My personal opinion is that it's time for folks 
to stop putting it down unless they've got a better idea and some 
code to put with it.

- Original Message - From: "Dakota Jack" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, November 21, 2004 12:01 AM
Subject: Re: JerichoFaces ?

On Sat, 20 Nov 2004 09:18:18 -0600, Joe Germuska <[EMAIL PROTECTED]> 
wrote:

I think a lot of people are making a mistake by making more out of
Shale than it is.  Shale is a proposal and a prototype.  It is here
now for people to use it and see what they thing of it.  It is taking
the opportunity to re-imagine Struts free of some of the backwards
compatibility baggage that Struts 1.x has.

Shale is Java ServerFaces: "ViewController is an interface describing
a JavaBean that is associated with a JavaServer Faces view (typically
a JSP page)", cf. http://www.apache.org/~craigmcc/struts-shale/.  Java
ServerFaces or Shale and Struts are different and inherently
incompatible visions, cf. the connection between Struts and JavaServer
Faces in Hans Bergsten's book on the same.  Is pointing this out or
raising the issue a problem?
The name "Struts" has great branding value as the advocates of Shale
and Java ServerFaces clearly see.  If you want to take that name and
give it to something fundamentally and philosophically inconsistent,
be my guest.  You are right.  People can continue to work on Struts
after the name has been moved to an architecture which is inconsistent
with Struts.  Things get a little confusing, perhaps, but that can be
done.
But, saying that this is happening (1) is not to denigrate Shale or
Java ServerFa

Re: JerichoFaces ?

2004-11-21 Thread Dakota Jack
Thanks for this, BaTien.  Points well taken.  Not on point in this
thread, however.  More to the point on this thread is the following
statement by Ted, and I quote:



On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf wrote:

>>
>> Has Struts Shale no relationship to (Struts/Commons)-Chain?


Technically, there only relationship between Struts and Shale is that
they are both standards-based web application frameworks originated by
Craig McClanahan  :)

I saw your post to the MyFaces list regarding Shale, Matthais, and it
will be interesting to see how the MyFaces community responds.

Given that Apache MyFaces now hosts generic JSF components, like JSF
Tiles, an obvious question is  whether Shale would be a better fit as
a MyFaces subproject.

-Ted.

> 
> You are right on the target, man. As Ted has spoken on several places
> that real developers write proposed codes to get feed back from others.
> He/she then uses the codes to make a living. This is  the greatest part
> of open sources, relying on economic invisible hand. I like to go half
> step further that as a technology entrepreneur  (i am not a programmer
> geek), i make my decision based on real deliverables that best meet
> requirements. We are accountable for our own actions.
> 
> Speaking out different opinions however is a very healthy first step
> while waiting for real codes on the table and keep things in proper
> perspective. Until we have real codes, we proceed with what is available.
> 
> BaTien
> DBGROUPS
> 
> 
> 
> >
> > Maybe I'm too trusting, but having observed Craig's comments on shale
> > and JSF and the pieces of JSF that "Shale proposes to depend upon",
> > and realizing that he's in a very select, choice position so far as
> > perspectives are concerned, I'm inclined to trust the guy.  ...
> > especially when he keeps saying, "It'll be alright" (basically) and
> > all the people that have something negative to say about Shale have to
> > chip-in "... but I'm really not familiar with Faces".
> >
> > So far as Hans' comment goes.  Whose word are you going to take?
> > You've got a choice between Hans, who is certainly a sharp cookie, and
> > Craig.  Hans is a bright guy who has done his homework and written us
> > some fine literature ... and Craig is out there setting the tone for
> > JSF ... oh, wait, Craig pretty well set the tone for Struts too - he
> > invented it!
> >
> > ... my money is on Craig ... :-)
> >
> > Peace ;-)
> >
> > Eddie
> >
> > P.S. - There's nothing wrong with discussion.  Discussions generally
> > have two sides though, and most of what I've heard about Shale here is
> > pretty one-sided.  My personal opinion is that it's time for folks to
> > stop putting it down unless they've got a better idea and some code to
> > put with it.
> >
> > - Original Message - From: "Dakota Jack" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Sunday, November 21, 2004 12:01 AM
> > Subject: Re: JerichoFaces ?
> >
> >
> >> On Sat, 20 Nov 2004 09:18:18 -0600, Joe Germuska <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> I think a lot of people are making a mistake by making more out of
> >>> Shale than it is.  Shale is a proposal and a prototype.  It is here
> >>> now for people to use it and see what they thing of it.  It is taking
> >>> the opportunity to re-imagine Struts free of some of the backwards
> >>> compatibility baggage that Struts 1.x has.
> >>
> >>
> >> Shale is Java ServerFaces: "ViewController is an interface describing
> >> a JavaBean that is associated with a JavaServer Faces view (typically
> >> a JSP page)", cf. http://www.apache.org/~craigmcc/struts-shale/.  Java
> >> ServerFaces or Shale and Struts are different and inherently
> >> incompatible visions, cf. the connection between Struts and JavaServer
> >> Faces in Hans Bergsten's book on the same.  Is pointing this out or
> >> raising the issue a problem?
> >>
> >> The name "Struts" has great branding value as the advocates of Shale
> >> and Java ServerFaces clearly see.  If you want to take that name and
> >> give it to something fundamentally and philosophically inconsistent,
> >> be my guest.  You are right.  People can continue to work on Struts
> >> after the name has been moved to an architecture which is inconsistent
> >> with Struts.  Things get a 

Re: JerichoFaces ?

2004-11-21 Thread Dakota Jack
The only point, Joe, I was interested in making was that Shale and
JavaServer Faces are inherently distinct from and not *mergable* with
Struts.  They can exist in tandem but not together.  I no one seems to
disagree with this.  There are lots of people that raise and debate
other points which have nothing to do with what I initially said. 
That is fine with me.  But, please don't connect the original thread
with those debates.  I have no dog in those hunts.

Jack

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-21 Thread Dakota Jack
Hi, Eddie,

The only point on this thread is that Struts as we know it and Shale
or JavaServer Faces can only co-exist or exist in tandem.  They are
not compatible in any sense greater than that.  The only connection
they can have is with some controller deciding which to use.

I think everyone that knows the two knows this.  I don't think Hans
and Craig disagree on this.  I think you are confused about this,
Eddie.  To dispell such confusion was the point of this thread.

The point of the thread was not to challenge Craig or anyone else
about anything.  Your support for Craig on this one, I think, is
misguided, because I don't think he is thinking what you think he is.
I have no problem with what Craig is proposing.  I just think some
don't see what the upshot really is.  If the discusson could focus on
that it would be good.

I don't think the notes about *coding* address the issue.

I like your dad, and think he has raised a fine kid too.  Don't know
if you have a brother by the same name?  LOL  Peace to you as well.


Jack

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-21 Thread BaTien Duong
Eddie Bush wrote:
I think Joe makes a good point.  Shale is what we have as a possible 
direction ... and it's being fleshed out.  Jerico, better or worse, I 
don't think is.

At this point, we're probably better to "put our code where our mouths 
are", if we don't like the direction things are headed.


You know, when I was a kid, I thought life was fantastic, save for the 
nights I absolutely forced my dad to blister my bottom to make me go 
to bed (kids ... it's their job) - it was so simple!  After several 
years though, I got a few more years on me and daddy just kept making 
me behave more and more!  Argh!  Life wasn't quite as simple anymore 
:-(  I had more responsibilities and more expectations laid on me.

Hey!  That kinda sounds like Struts, doesn't it?  Hrm ... You know, 
I'm losing my hair, and I don't look like I used to either.  Heck, 
I've gained a good 20 pounds since I was in college - and we won't 
talk about since Highschool!


:-)
Struts is kind of Craig's baby.  I think it's pretty suitable that he 
make his baby grow up to prepare it for the big bad world.  As with 
any parent, all he can do is steer it in the direction he feels is 
right.  A parent *is* morally obligated to teach their children the 
best they can, after all.

All I'm saying is that instead of casting all the dissenting remarks, 
we should recognize that Craig has put his best foot forward (People 
kinda thought he was nuts when he started Struts, if I remember the 
stories).  If a person has an implementation to put along-side of what 
he's got then I don't think it'd be real hard to do some comparison 
shopping, but it's pretty hard to comparison shop without something to 
compare to.  Duh? Hehehe ...
You are right on the target, man. As Ted has spoken on several places 
that real developers write proposed codes to get feed back from others. 
He/she then uses the codes to make a living. This is  the greatest part 
of open sources, relying on economic invisible hand. I like to go half 
step further that as a technology entrepreneur  (i am not a programmer 
geek), i make my decision based on real deliverables that best meet 
requirements. We are accountable for our own actions.

Speaking out different opinions however is a very healthy first step 
while waiting for real codes on the table and keep things in proper 
perspective. Until we have real codes, we proceed with what is available.

BaTien
DBGROUPS
Maybe I'm too trusting, but having observed Craig's comments on shale 
and JSF and the pieces of JSF that "Shale proposes to depend upon", 
and realizing that he's in a very select, choice position so far as 
perspectives are concerned, I'm inclined to trust the guy.  ... 
especially when he keeps saying, "It'll be alright" (basically) and 
all the people that have something negative to say about Shale have to 
chip-in "... but I'm really not familiar with Faces".

So far as Hans' comment goes.  Whose word are you going to take?  
You've got a choice between Hans, who is certainly a sharp cookie, and 
Craig.  Hans is a bright guy who has done his homework and written us 
some fine literature ... and Craig is out there setting the tone for 
JSF ... oh, wait, Craig pretty well set the tone for Struts too - he 
invented it!

... my money is on Craig ... :-)
Peace ;-)
Eddie
P.S. - There's nothing wrong with discussion.  Discussions generally 
have two sides though, and most of what I've heard about Shale here is 
pretty one-sided.  My personal opinion is that it's time for folks to 
stop putting it down unless they've got a better idea and some code to 
put with it.

- Original Message - From: "Dakota Jack" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, November 21, 2004 12:01 AM
Subject: Re: JerichoFaces ?

On Sat, 20 Nov 2004 09:18:18 -0600, Joe Germuska <[EMAIL PROTECTED]> 
wrote:

I think a lot of people are making a mistake by making more out of
Shale than it is.  Shale is a proposal and a prototype.  It is here
now for people to use it and see what they thing of it.  It is taking
the opportunity to re-imagine Struts free of some of the backwards
compatibility baggage that Struts 1.x has.

Shale is Java ServerFaces: "ViewController is an interface describing
a JavaBean that is associated with a JavaServer Faces view (typically
a JSP page)", cf. http://www.apache.org/~craigmcc/struts-shale/.  Java
ServerFaces or Shale and Struts are different and inherently
incompatible visions, cf. the connection between Struts and JavaServer
Faces in Hans Bergsten's book on the same.  Is pointing this out or
raising the issue a problem?
The name "Struts" has great branding value as the advocates of Shale
and Java ServerFaces clearly

Re: JerichoFaces ?

2004-11-21 Thread Joe Germuska
At 10:01 PM -0800 11/20/04, Dakota Jack wrote:
Java ServerFaces or Shale and Struts are different and inherently
incompatible visions, cf. the connection between Struts and JavaServer
Faces in Hans Bergsten's book on the same.  Is pointing this out or
raising the issue a problem?
Of course not.  There's nothing wrong with discussion, but in this 
case, I feel like the discussion isn't really advancing anything.  I 
also still think that to say that Struts and JSF are inherently 
incompatible is simply not true - obviously, there have been many 
people on this list using the struts-faces library, which helps the 
two interoperate.  Whether that's a good way to do things or a bad 
way, it makes it clear that "inherently incompatible" is not the 
right way to describe their relationship.

The name "Struts" has great branding value as the advocates of Shale
and Java ServerFaces clearly see.  If you want to take that name and
give it to something fundamentally and philosophically inconsistent,
be my guest.
Here, again:  I want nothing more than a webapp framework that helps 
me and my team do our jobs.  I don't really give a flip about the 
branding value of Struts name, because I'm not trying to sell it.  I 
just want to use it.

To be honest?  I'm not that interested in Shale.  Right now, I'm much 
more excited about getting going on Struts 1.3 now that the 1.2.6 
test build is up and the SVN repository has a 1.2.x branch.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JerichoFaces ?

2004-11-21 Thread Eddie Bush
I think Joe makes a good point.  Shale is what we have as a possible 
direction ... and it's being fleshed out.  Jerico, better or worse, I don't 
think is.

At this point, we're probably better to "put our code where our mouths are", 
if we don't like the direction things are headed.


You know, when I was a kid, I thought life was fantastic, save for the 
nights I absolutely forced my dad to blister my bottom to make me go to bed 
(kids ... it's their job) - it was so simple!  After several years though, I 
got a few more years on me and daddy just kept making me behave more and 
more!  Argh!  Life wasn't quite as simple anymore :-(  I had more 
responsibilities and more expectations laid on me.

Hey!  That kinda sounds like Struts, doesn't it?  Hrm ... You know, I'm 
losing my hair, and I don't look like I used to either.  Heck, I've gained a 
good 20 pounds since I was in college - and we won't talk about since 
Highschool!


:-)
Struts is kind of Craig's baby.  I think it's pretty suitable that he make 
his baby grow up to prepare it for the big bad world.  As with any parent, 
all he can do is steer it in the direction he feels is right.  A parent *is* 
morally obligated to teach their children the best they can, after all.

All I'm saying is that instead of casting all the dissenting remarks, we 
should recognize that Craig has put his best foot forward (People kinda 
thought he was nuts when he started Struts, if I remember the stories).  If 
a person has an implementation to put along-side of what he's got then I 
don't think it'd be real hard to do some comparison shopping, but it's 
pretty hard to comparison shop without something to compare to.  Duh? 
Hehehe ...

Maybe I'm too trusting, but having observed Craig's comments on shale and 
JSF and the pieces of JSF that "Shale proposes to depend upon", and 
realizing that he's in a very select, choice position so far as perspectives 
are concerned, I'm inclined to trust the guy.  ... especially when he keeps 
saying, "It'll be alright" (basically) and all the people that have 
something negative to say about Shale have to chip-in "... but I'm really 
not familiar with Faces".

So far as Hans' comment goes.  Whose word are you going to take?  You've got 
a choice between Hans, who is certainly a sharp cookie, and Craig.  Hans is 
a bright guy who has done his homework and written us some fine literature 
... and Craig is out there setting the tone for JSF ... oh, wait, Craig 
pretty well set the tone for Struts too - he invented it!

... my money is on Craig ... :-)
Peace ;-)
Eddie
P.S. - There's nothing wrong with discussion.  Discussions generally have 
two sides though, and most of what I've heard about Shale here is pretty 
one-sided.  My personal opinion is that it's time for folks to stop putting 
it down unless they've got a better idea and some code to put with it.

- Original Message - 
From: "Dakota Jack" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, November 21, 2004 12:01 AM
Subject: Re: JerichoFaces ?


On Sat, 20 Nov 2004 09:18:18 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
I think a lot of people are making a mistake by making more out of
Shale than it is.  Shale is a proposal and a prototype.  It is here
now for people to use it and see what they thing of it.  It is taking
the opportunity to re-imagine Struts free of some of the backwards
compatibility baggage that Struts 1.x has.
Shale is Java ServerFaces: "ViewController is an interface describing
a JavaBean that is associated with a JavaServer Faces view (typically
a JSP page)", cf. http://www.apache.org/~craigmcc/struts-shale/.  Java
ServerFaces or Shale and Struts are different and inherently
incompatible visions, cf. the connection between Struts and JavaServer
Faces in Hans Bergsten's book on the same.  Is pointing this out or
raising the issue a problem?
The name "Struts" has great branding value as the advocates of Shale
and Java ServerFaces clearly see.  If you want to take that name and
give it to something fundamentally and philosophically inconsistent,
be my guest.  You are right.  People can continue to work on Struts
after the name has been moved to an architecture which is inconsistent
with Struts.  Things get a little confusing, perhaps, but that can be
done.
But, saying that this is happening (1) is not to denigrate Shale or
Java ServerFaces; (2) has nothing to do with the ASF open source
process and what people can and cannot work on; (3)  is not to support
or to decry the process.  Heck, maybe this is not right.  Seems to me
that discussion of what is happening and knowledge of the same is
legitimate, isn't it?  People can do what they want.  There stil

Re: JerichoFaces ?

2004-11-20 Thread Dakota Jack
On Sat, 20 Nov 2004 09:18:18 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:

> I think a lot of people are making a mistake by making more out of
> Shale than it is.  Shale is a proposal and a prototype.  It is here
> now for people to use it and see what they thing of it.  It is taking
> the opportunity to re-imagine Struts free of some of the backwards
> compatibility baggage that Struts 1.x has.

Shale is Java ServerFaces: "ViewController is an interface describing
a JavaBean that is associated with a JavaServer Faces view (typically
a JSP page)", cf. http://www.apache.org/~craigmcc/struts-shale/.  Java
ServerFaces or Shale and Struts are different and inherently
incompatible visions, cf. the connection between Struts and JavaServer
Faces in Hans Bergsten's book on the same.  Is pointing this out or
raising the issue a problem?

The name "Struts" has great branding value as the advocates of Shale
and Java ServerFaces clearly see.  If you want to take that name and
give it to something fundamentally and philosophically inconsistent,
be my guest.  You are right.  People can continue to work on Struts
after the name has been moved to an architecture which is inconsistent
with Struts.  Things get a little confusing, perhaps, but that can be
done.

But, saying that this is happening (1) is not to denigrate Shale or
Java ServerFaces; (2) has nothing to do with the ASF open source
process and what people can and cannot work on; (3)  is not to support
or to decry the process.  Heck, maybe this is not right.  Seems to me
that discussion of what is happening and knowledge of the same is
legitimate, isn't it?  People can do what they want.  There still is
the need to be aware of what is happening in making such choices.  No?

Jack

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: JerichoFaces ?

2004-11-20 Thread Joe Germuska
If Struts needs that big a change to handle new stuff, perhaps it
might be better to create a new project and start Struts on a nice
end of life maintenance schedule.
I think a lot of people are making a mistake by making more out of
Shale than it is.  Shale is a proposal and a prototype.  It is here
now for people to use it and see what they thing of it.  It is taking
the opportunity to re-imagine Struts free of some of the backwards
compatibility baggage that Struts 1.x has.
If backwards compatibility is one's main concern, one can still work
on lots of future improvements on the Struts 1.x timeframe.   The
whole point of a Struts 2.0 is to take gambles on backwards
compatibility in hopes of payoffs that can't be reached in the
current constraints.  Meanwhile, I can see many ways that Struts 1.x
can be improved incrementally.
If one really wants to dream big, but just doesn't like Shale that
much, then I think one ought to approach it more or less as Craig
has.  Write a proposal, write some code, put something concrete out
for people to consider.
Apache is a democracy, but moreso it's a do-ocracy.  And, as noted
previously in this thread, the beginning of work on anything which
might be called Struts 2.x by no means equals the death or
obsolescence of Struts 1.x.  It is entirely possible for both to be
developed in parallel, as long as people step up to do the work of
developing.
If you want Struts 1.x to survive, you have the power to help it
survive, no matter what happens with Shale. Insofar as this
discussion is happening on the user list, all who are bothering to
read should be stepping up, saying "this is where Struts is harder
than it needs to be" or "we use Struts in this way and we think its
something everyone could benefit from" or otherwise helping to point
out where Struts is failing.  One might almost think it doesn't
really, given the lack of specific comments from people about what
they'd like to see in it.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JerichoFaces ?

2004-11-19 Thread Ted Husted
For the sake of clarity, I'm crossposting this one message, but otherwise only 
respond to this thread on the dev list. People interested in this sort of thing 
should subscribe to the dev list. (Please, please, do.)

On Thu, 18 Nov 2004 11:52:07 -0800, Dakota Jack wrote:
> My discussion of Struts being on the chopping block (look deeply
> into that chicken's eyes ;-) ) is based on seeing the controller
> mechanism, what Craig now calls a "monolithic" controller, being
> jettisoned.

Here are the true facts:

Most of us eat our own dog food. Most of us (meaning the committers) use Struts 
in real life, in our own projects, just like you. We all work with different 
teams, on projects of different scales.

So long as we need Struts 1.x ourselves, then Struts 1.x will continue to be 
improved and maintained. If this particular group of Struts committers all 
moved to JSF and wanted to use Shale, and some other group of committers wanted 
to maintain Struts 1.x instead, then I'd be the first to start nominating 
people.

Struts is an ASF project, and this is the foundation in a nutshell:

* As long as there is a community of developers who are ready, willing, and 
able to roll up their sleeves and maintain a codebase, then the codebase will 
live on. Indefinitely.

Our one and only business model is whether there are volunteers to do the work. 
Nothing else matters.

So, next, I'm going to spend some of my volunteer hours getting Struts 1.2.x 
ready for a .6 release. After that, we can go on to Struts 1.3.x, featuring 
Common Chain. We're not always quick, but we are steady.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: JerichoFaces ?

2004-11-19 Thread Chappell, Simon P
highly intelligent and 
well-informed just to be undecided about them." - Laurence J. Peter


>-Original Message-----
>From: Dakota Jack [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 18, 2004 2:36 PM
>To: Struts Users Mailing List
>Subject: Re: JerichoFaces ?
>
>
>Okay, I will move my part of this discussion to the developers list. 
>I don't agree, however.  I think that the user list is role oriented
>(for user concerns which would include issues on using Struts but not
>be exclusive to using Stuts, e.g. would include anything important to
>users) and not merely action oriented (about using struts merely). 
>Pax vobiscum!
>
>Jack
>
>
>On Thu, 18 Nov 2004 13:23:07 -0600, Joe Germuska 
><[EMAIL PROTECTED]> wrote:
>> 
>> I would agree with Craig, though, that these are struts-dev
>> discussions.  This list is for "how do I use Struts?"  There are
>> enough people on the struts-dev list who will have experience and
>> opinions enough to contribute to the discussion, and anyone on this
>> list is welcome to join that one if they don't want to miss anything.
>> 
>> 
>> 
>> Joe
>> 
>> --
>> Joe Germuska
>> [EMAIL PROTECTED]
>> http://blog.germuska.com
>> "Narrow minds are weapons made for mass destruction"  -The Ex
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-18 Thread Dakota Jack
Okay, I will move my part of this discussion to the developers list. 
I don't agree, however.  I think that the user list is role oriented
(for user concerns which would include issues on using Struts but not
be exclusive to using Stuts, e.g. would include anything important to
users) and not merely action oriented (about using struts merely). 
Pax vobiscum!

Jack


On Thu, 18 Nov 2004 13:23:07 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> 
> I would agree with Craig, though, that these are struts-dev
> discussions.  This list is for "how do I use Struts?"  There are
> enough people on the struts-dev list who will have experience and
> opinions enough to contribute to the discussion, and anyone on this
> list is welcome to join that one if they don't want to miss anything.
> 
> 
> 
> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[OT] Re: JerichoFaces ?

2004-11-18 Thread Dakota Jack
Craig,

I don't understand this.   I do want to be in the
middle of the herd on protocols and I do want to be heard.  

I don't understand your point here, however.  Are you seriously
saying this is just "noise" to users?  

Anyway, out of a lot of deference to you and out of a bit of "fear" 
from the warning part of "fair warning" and a little gratitude for the
fair part of "fair warning", I have added [OT] to this.  I assume that
this discussion has to be at least as important to users as other 
[OT] discussions?  If you insist that even this is not acceptable, 
I will even drop this [OT] qualifier and move over to the developer 
list despite my judgment to the contrary and despite the fact that
I think this stiffles legitimate discussion.

Jack


On Thu, 18 Nov 2004 11:19:23 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Nov 2004 10:45:31 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> 
> [snip]
> > With all due respect, which is considerable, on this topic the user
> > list seems far more appropriate than the developer list to me.  Users
> > have a significant investment in Struts remaining Struts.
> 
> Fair warning -- violating the community culture about how open source
> packages are developed; particularly here at Apache, is not going to
> help you get your ideas listened to, no matter how good they are.
> 
> Craig
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-18 Thread Dakota Jack
Joe,

This will be, to promote clarity, in a few parts.  The first is: WHAT
IS STRUTS? as you requested.  (See
http://rollerjm.free.fr/pro/Struts11.html#3 ).

> Elaborating from this, one might ask "what is Struts?"  

 Then again, I don't think the answer is
> critically important.  I don't really care what it's called; I just
> want a webapp framework that makes my job easier.  Continuity with
> Struts 1.x will help with that, since I won't have to live through
> retraining myself and the whole team -- but we've learned to deal
> with lots of change anyway.

This is, I think, well-known but may need to be said at the present
time.  I don't see StrutsJericho as a departure from the big picture
that is Struts.

Struts as I see it is essentially the framework defined by the classes
in Struts in part named by "Action", i.e. ActionServet, Action,
ActionForm, ActionMapping, ActionForward, etc.

The ActionServlet takes a client's request which has a predefined
"intent" in the web.xml to employ the Struts framework (usually via
".do" in the request URL) and passes them off to the appropriate
Action subclass with any predefined "hooks", such as to an ActionForm.
 After processing, the Action subclass passes back control with an
ActionForward which tells the controller what response object to
return for the client's request.  The response object itself, e.g.
HTML, is created by the "view helpers" in Struts, e.g. JSP pages,
taglibs, etc.,, and its grabbing of data from request, page (tile),
session and application scope.  (This is where event based mechanism
in JerichoState, which is related to but not at all essential to
StrutsJericho -- controller -- comes into play.)

I refer anyone interested in this to the "pretty pictures" ;-) at
http://rollerjm.free.fr/pro/Struts11.html#3 which are fairly accurate,
I think, and have been provided to ASF by  Jean-Michel Garnier.

My discussion of Struts being on the chopping block (look deeply into
that chicken's eyes ;-) ) is based on seeing the controller mechanism,
what Craig now calls a "monolithic" controller, being jettisoned.

 > Particularly
> when one looks at the chain-processing model, the definition becomes
> much more amorphous. 

I think that is 180 degrees off and that chain request processing is
completely in tune with the Struts architecture for the following
reasons.  The controller in Struts follows what the controller is
supposed to be in the classic MVC design, viz. a Strategy design
pattern which has as its job "defin[ing] the way the user interface
reacts to user input" (Gamma, et al, "Design Patterns: Elements of
Reusable Object-Oriented Software, p. 4).  The Strategy pattern
essentially allows you to use different algorithms for a task. 
StrutsJericho clearly is an improvement on the original Struts vision
in this respect in that it allows the freedom to construct different
algorithms in the controller, ActionServlet, by allowing the
programmer to break down the RequestProcessor into increments which
can be arranged in various orders.

So far as I can tell, Shale merely dumps this whole idea for a page
based controller.  I am not adverse to page based controllers,
although I would not pursue this solution.  What I am saying is that
if there is a page based controller solution, it does not count as an
enhancement of but rather as a destruction of Struts.  If we want a
framework for Java ServerPages that is enamored of a page based
controller that is very cool and I would love to see it.  But, even
though Struts has great name recognition, grabbing the Struts name to
promote a non-Struts product seems too Machievellian to me.  LOL  That
*is* a joke, so let's laugh together.  If someone can explain to me
how the Struts controller vision can survive Shale, I would be very
interested.  If Shale is going to replace rather than enhance Struts,
let's know that up front.  Struts needs a big change, I think.  And, I
like the ideas Ted Husted has offered in StrutsJericho for Struts 2.0.
 Anyway, I would follow pretty much what everyone has been saying for
years in terms of what is essentially Struts.  Struts is pretty much
the controller mechanism that defined by handing off the ball to
Action subclasses and their return ActionForwards.  This is a way cool
idea, I think, and I would strongly suggest enhancing it rather than
dumping it as the way for Struts 2.0.  This does not mean I would not
support any work on anything.  I would support increasing rather than
decreasing choices.

I envision three more emails on this to the list: (1) what is
JerichoState?  (2) what is JerichoFaces?  and (3) does Shale jettison
rather than enhance Struts?  Then I will put up the core of these
emails with the helpful responses from the list.

I hope this addressed your question about what is Struts adequ

Re: JerichoFaces ?

2004-11-18 Thread Joe Germuska
If Struts as we know it dies with Shale
Struts as you know it will not die until no developers (including 
you) are interested in maintaining Struts-as-you-know-it.  It's 
Apache-licensed software.  Nothing is stopping anyone from TODAY 
getting the source-code, making a few simple changes to package names 
and such, and checking it into a SourceForge project and starting a 
whole new line of development.

Not only that, but it would be entirely possible to keep Struts 1.x 
development alive at Apache for a long time to come -- look, you can 
still get Tomcat 3 and 4 from "the official site."

If you're most interested in furthering Struts more like it is today, 
maybe you have some changes which "belong" in the Struts 1.x 
code-line that you'd like to work on?

I would agree with Craig, though, that these are struts-dev 
discussions.  This list is for "how do I use Struts?"  There are 
enough people on the struts-dev list who will have experience and 
opinions enough to contribute to the discussion, and anyone on this 
list is welcome to join that one if they don't want to miss anything.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JerichoFaces ?

2004-11-18 Thread Craig McClanahan
On Thu, 18 Nov 2004 14:09:02 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
> If Struts 2 is something fundamentally different from Struts 1, is it
> not possible that Struts 1 and Struts 2 could coexist and that the two
> could be maintained and (if people desire) developed separately? I mean,
> even if development peters out on Struts 1, can't it still stick around
> in its mature form? Doesn't it make sense that Craig could/should
> eventually leave behind Struts 1 to focus on Struts 2, etc., but that
> some other(s) could "inherit" leadership of Struts 1 and keep it going
> as well, if there is a user base to warrant it (if that is not already
> the case)?
> 

There are many precedents for exactly this approach, including several
here at Apache:

* HTTP server (1.3 and 2.0 are totally different)

* Tomcat (3.x and 4.x were totally different)

as well as external examples (Windows 3.x versus XP, or ASP to
ASP.NEt, or VB to VB.Net, for example).

> I am speaking hypothetically because I haven't looked beyond Craig's
> initial Shale proposal doc (so I am quite uninformed about the
> fundamental differences), and I am not a Struts contributor in any form
> other than by helping (OK, *attempting* to help?) people on this list.
> But I do know that there are plenty of developers who really like the
> Struts of today, and perhaps it will remain good for certain jobs for an
> indefinite amount of time while Struts 2 is aimed at a different
> (probably more advanced) set of general requirements. Does anyone agree
> or am I missing something?
> 
> 
> Erik
> 

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-18 Thread Erik Weber
If Struts 2 is something fundamentally different from Struts 1, is it 
not possible that Struts 1 and Struts 2 could coexist and that the two 
could be maintained and (if people desire) developed separately? I mean, 
even if development peters out on Struts 1, can't it still stick around 
in its mature form? Doesn't it make sense that Craig could/should 
eventually leave behind Struts 1 to focus on Struts 2, etc., but that 
some other(s) could "inherit" leadership of Struts 1 and keep it going 
as well, if there is a user base to warrant it (if that is not already 
the case)?

I am speaking hypothetically because I haven't looked beyond Craig's 
initial Shale proposal doc (so I am quite uninformed about the 
fundamental differences), and I am not a Struts contributor in any form 
other than by helping (OK, *attempting* to help?) people on this list. 
But I do know that there are plenty of developers who really like the 
Struts of today, and perhaps it will remain good for certain jobs for an 
indefinite amount of time while Struts 2 is aimed at a different 
(probably more advanced) set of general requirements. Does anyone agree 
or am I missing something?

Erik

Dakota Jack wrote:
Thanks for your thoughts, Craig.  See infra.  Most of your comments
were about the appearance, mien, bearing, style, and environment of
the discussion about Jericho versus Shale.
I hope we don't have to keep discussing the legitimacy of the
discussion itself.  I am comfortable that a discussion of this topic
is legitimate on a Struts user list.  I think that we can talk about
these issues, whomever is right, closer to right, or whatever, and
that such talk is constructive and to be advised.
I am going to try to bring the discussion back a bit more to the
substance of the issues.  Hopefully the following will be constructive
for all.
 

PLEASE move the discussions over the the developer
list where they belong. 
   

With all due respect, which is considerable, on this topic the user
list seems far more appropriate than the developer list to me.  Users
have a significant investment in Struts remaining Struts.
Buying into Struts is not like buying a cup of coffee.  If Starbucks
wants to change to franchised taverns selling Mai Tai's and assorted
"umbrelled" drinks, we can always go to another coffee house.  If
Struts ends, the user is out of luck.
Joe wants my worries about Struts's future in relation to Shale cashed
out, and that certainly is a reasonable request.  The concern,
however, is primarily a user's concern and I would certainly advise
the user to pay attention to these developments.  If these worries are
not real, I would certainly read every word you have to say on that
with utmost care.  You can understand, I am sure, that the worry is
important to people that have an investment in Struts.
 

Since we're all developers here ... you might consider trying to
demonstrate with *code* instead of words (or pretty pictures :-) why a
proposed solution is better.  
   

The diagram at http://131.191.32.112:8080/ cuts down on traffic: a
picture is worth a 1000 words?  The issues at this stage are
architectural not code.  So, from my perspective, this is the
appropriate presentation of the issues.  I don't think that code would
be at all helpful at this juncture.  More on this below.
 

Show us an application based on that
design (preferably one also implemented on the alternative approaches
so we can compare -- and it doesn't have to be mailreader; I'm game
for a different one).
   

There are numerous applications written in Struts and Struts has
proved itself.  Jericho as I see it is merely a very well thought out
technical improvement on Struts and can rely upon the past history and
success of Struts.  Jericho keeps the part that is "not broken". 
Shale, however, if my view of Shale is right, essentially displaces
Struts with a new theory and has the burden of showing that code will
do what Struts can do and has done.  My main proposal, which is
consistent with Jericho but which is not part of Jericho per se, is to
develop a separate JerichoState mechanism with an event architecture
which will enhance the MVC pattern in a web based environment.

What I am advocating is the carpenter's adage -- measure twice, cut
once, and is the jumper's adage -- look before you leap.  I don't
think the sewer's adage -- a stitch in time saves nine -- is
appropriate to this discussion.  ;-)
 

You've said you don't like the page controller approach.  Fine ...
that's your right.  
   

I don't mind page controllers in one sense but do have questions in
another sense of page controller, i.e. in the sense employed in Java
ServerFaces and related to the controller in the MVC design pattern
which I think has proven itself.  I may be wrong.  But, heh, isn't
this the place to discuss it?  Where else?
 

But "Struts is dead" comments are just noise,
   

I am not saying "Struts is dead".  Let's be clear about that.  I am
very connected to the whole Str

Re: JerichoFaces ?

2004-11-18 Thread Dakota Jack
Thanks for your thoughts, Craig.  See infra.  Most of your comments
were about the appearance, mien, bearing, style, and environment of
the discussion about Jericho versus Shale.

 I hope we don't have to keep discussing the legitimacy of the
discussion itself.  I am comfortable that a discussion of this topic
is legitimate on a Struts user list.  I think that we can talk about
these issues, whomever is right, closer to right, or whatever, and
that such talk is constructive and to be advised.

I am going to try to bring the discussion back a bit more to the
substance of the issues.  Hopefully the following will be constructive
for all.


> PLEASE move the discussions over the the developer
> list where they belong. 

With all due respect, which is considerable, on this topic the user
list seems far more appropriate than the developer list to me.  Users
have a significant investment in Struts remaining Struts.

Buying into Struts is not like buying a cup of coffee.  If Starbucks
wants to change to franchised taverns selling Mai Tai's and assorted
"umbrelled" drinks, we can always go to another coffee house.  If
Struts ends, the user is out of luck.

Joe wants my worries about Struts's future in relation to Shale cashed
out, and that certainly is a reasonable request.  The concern,
however, is primarily a user's concern and I would certainly advise
the user to pay attention to these developments.  If these worries are
not real, I would certainly read every word you have to say on that
with utmost care.  You can understand, I am sure, that the worry is
important to people that have an investment in Struts.

> Since we're all developers here ... you might consider trying to
> demonstrate with *code* instead of words (or pretty pictures :-) why a
> proposed solution is better.  

The diagram at http://131.191.32.112:8080/ cuts down on traffic: a
picture is worth a 1000 words?  The issues at this stage are
architectural not code.  So, from my perspective, this is the
appropriate presentation of the issues.  I don't think that code would
be at all helpful at this juncture.  More on this below.

> Show us an application based on that
> design (preferably one also implemented on the alternative approaches
> so we can compare -- and it doesn't have to be mailreader; I'm game
> for a different one).

There are numerous applications written in Struts and Struts has
proved itself.  Jericho as I see it is merely a very well thought out
technical improvement on Struts and can rely upon the past history and
success of Struts.  Jericho keeps the part that is "not broken". 
Shale, however, if my view of Shale is right, essentially displaces
Struts with a new theory and has the burden of showing that code will
do what Struts can do and has done.  My main proposal, which is
consistent with Jericho but which is not part of Jericho per se, is to
develop a separate JerichoState mechanism with an event architecture
which will enhance the MVC pattern in a web based environment.

What I am advocating is the carpenter's adage -- measure twice, cut
once, and is the jumper's adage -- look before you leap.  I don't
think the sewer's adage -- a stitch in time saves nine -- is
appropriate to this discussion.  ;-)

> 
> You've said you don't like the page controller approach.  Fine ...
> that's your right.  

I don't mind page controllers in one sense but do have questions in
another sense of page controller, i.e. in the sense employed in Java
ServerFaces and related to the controller in the MVC design pattern
which I think has proven itself.  I may be wrong.  But, heh, isn't
this the place to discuss it?  Where else?

> But "Struts is dead" comments are just noise,

I am not saying "Struts is dead".  Let's be clear about that.  I am
very connected to the whole Struts idea.  I am worried that *if* Shale
is adapted Struts is dead.  This is not "noise" but a serious concern
which is either true or false.  Which is it?

> until you demonstrate exactly why and how your approach is better.  

If Struts *is* dead, then my investment in Struts is seriously
impacted whichever approach is "better".  Right?  If Struts as we know
it dies with Shale, and that is the discussion topic in one aspect,
that has impacts that must address issues way beyond which is better. 
I might have an investment in Struts which would be important even if
Shale were better.  (I am not at all tending to think that, but,
again, that is another issue.)  Again, this is not like the Starbucks'
where there are other Struts houses out their the user can rely on if
Shale changes things as dramatically as I suspect it does.

> I don't *care* if you like page controller or not.  I don't *care* if
> your picture indicates a mythical complete separation between the
> various elements -- it doesn't mean anything until its cast in
> something concrete.

My "picture" is merely additive to StrutsJericho, which I don't
discuss but which has a serious presentation on the whiteboard. 
Str

Re: JerichoFaces ?

2004-11-18 Thread Craig McClanahan
Jack,

Since we're all developers here ... you might consider trying to
demonstrate with *code* instead of words (or pretty pictures :-) why a
proposed solution is better.  Show us that it makes the framework code
easier to write and maintain.  Show us an application based on that
design (preferably one also implemented on the alternative approaches
so we can compare -- and it doesn't have to be mailreader; I'm game
for a different one).

You've said you don't like the page controller approach.  Fine ...
that's your right.  But "Struts is dead" comments are just noise,
until you demonstrate exactly why and how your approach is better.  I
don't *care* if you like page controller or not.  I don't *care* if
your picture indicates a mythical complete separation between the
various elements -- it doesn't mean anything until its cast in
something concrete.

And, by the way, PLEASE move the discussions over the the developer
list where they belong.  Anyone on the user list who wants to
participate in the discussion (or just follow along) is welcome to
subscribe.  Users who are interested primarily in getting the current
version to work will appreciate the lower volume on a pretty high
volume list.

Craig



On Thu, 18 Nov 2004 07:49:01 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Hi, Joe,
> 
> This is certainly a reasonable request and I don't take it personally
> at all.  I don't think what I have said is overblown.  I will add more
> later, but for the moment let me say that one needs to articulate what
> Struts does and ask what is left with the new proposals.  I will add
> more on that later today if I find the time.  We can all do that,
> however.  I do think that, if you want in any sense what Struts has
> been, I don't think what I said is alarmist but true.  If not, I
> certainly would like to get the truth clarified.  I have found your
> contributions to be clear, thought, and sound at all levels.  I am
> more than happy to meet this request.
> 
> Jack
> 
> 
> 
> 
> > At 11:56 PM -0800 11/17/04, Dakota Jack wrote:
> > >The bottom line is that Shale is wholly inconsistent with the Struts
> > >approach.  If Struts 2.0 becomes Shale, Struts is dead.
> >
> > Jack, don't take this personally, as I appreciate your energy and
> > your efforts to articulate an alternative -- but I see this as
> > alarmist and overblown.  I have been trying to track this thread, and
> > I have yet to see a convincing argument backing up this statement.
> >
> > I'm still looking for the personal time to get Shale running and to
> > look at making an app with it, but if you're going to make this
> > statement (and you have a couple of times), then I think you need to
> > come up with a concise explanation of why Shale is "wholly
> > inconsistent with Struts."  If you've made this point, I apologize
> > for missing that email.  Maybe you could add it to the web site
> > you're developing, or on a page in the Wiki?
> >
> > Elaborating from this, one might ask "what is Struts?"   Particularly
> > when one looks at the chain-processing model, the definition becomes
> > much more amorphous.  Then again, I don't think the answer is
> > critically important.  I don't really care what it's called; I just
> > want a webapp framework that makes my job easier.  Continuity with
> > Struts 1.x will help with that, since I won't have to live through
> > retraining myself and the whole team -- but we've learned to deal
> > with lots of change anyway.
> >
> > Joe
> >
> > --
> > Joe Germuska
> > [EMAIL PROTECTED]
> > http://blog.germuska.com
> > "Narrow minds are weapons made for mass destruction"  -The Ex
> >
> > -
> >
> >
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-18 Thread Dakota Jack
Hi, Joe,

This is certainly a reasonable request and I don't take it personally
at all.  I don't think what I have said is overblown.  I will add more
later, but for the moment let me say that one needs to articulate what
Struts does and ask what is left with the new proposals.  I will add
more on that later today if I find the time.  We can all do that,
however.  I do think that, if you want in any sense what Struts has
been, I don't think what I said is alarmist but true.  If not, I
certainly would like to get the truth clarified.  I have found your
contributions to be clear, thought, and sound at all levels.  I am
more than happy to meet this request.

Jack


> At 11:56 PM -0800 11/17/04, Dakota Jack wrote:
> >The bottom line is that Shale is wholly inconsistent with the Struts
> >approach.  If Struts 2.0 becomes Shale, Struts is dead.
> 
> Jack, don't take this personally, as I appreciate your energy and
> your efforts to articulate an alternative -- but I see this as
> alarmist and overblown.  I have been trying to track this thread, and
> I have yet to see a convincing argument backing up this statement.
> 
> I'm still looking for the personal time to get Shale running and to
> look at making an app with it, but if you're going to make this
> statement (and you have a couple of times), then I think you need to
> come up with a concise explanation of why Shale is "wholly
> inconsistent with Struts."  If you've made this point, I apologize
> for missing that email.  Maybe you could add it to the web site
> you're developing, or on a page in the Wiki?
> 
> Elaborating from this, one might ask "what is Struts?"   Particularly
> when one looks at the chain-processing model, the definition becomes
> much more amorphous.  Then again, I don't think the answer is
> critically important.  I don't really care what it's called; I just
> want a webapp framework that makes my job easier.  Continuity with
> Struts 1.x will help with that, since I won't have to live through
> retraining myself and the whole team -- but we've learned to deal
> with lots of change anyway.
> 
> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> -
> 
> 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-18 Thread Joe Germuska
On Wed, 17 Nov 2004 21:52:56 -0800, Craig McClanahan 
<[EMAIL PROTECTED]> wrote:
It's sort of interesting that a "page controller" is one of the things
people really like about Tiles, for the same reason I like it --
cutting down on the number of moving parts :-).
I am not wholly in love with the tiles controller.  I find it 
inconvenient to handle errors that might occur in the controller once 
the HTTP response is already committed.  I would prefer to have those 
errors happen before control is forwarded, so that I can use a basic 
error page rather than having a blank tile appear, or having to 
sprinkle  tags throughout my pages.  I like the basic idea, 
but I don't like deferring that processing to after-Struts.

On the other hand, I think the basic model of mapping a piece of 
handler code to a "view path" in about the same way we map code to 
request URL paths is brilliant and makes many things work much more 
cleanly.  I'd just rather do it in a "view controller" than in a JSP 
tag.

At 11:56 PM -0800 11/17/04, Dakota Jack wrote:
The bottom line is that Shale is wholly inconsistent with the Struts
approach.  If Struts 2.0 becomes Shale, Struts is dead.
Jack, don't take this personally, as I appreciate your energy and 
your efforts to articulate an alternative -- but I see this as 
alarmist and overblown.  I have been trying to track this thread, and 
I have yet to see a convincing argument backing up this statement.

I'm still looking for the personal time to get Shale running and to 
look at making an app with it, but if you're going to make this 
statement (and you have a couple of times), then I think you need to 
come up with a concise explanation of why Shale is "wholly 
inconsistent with Struts."  If you've made this point, I apologize 
for missing that email.  Maybe you could add it to the web site 
you're developing, or on a page in the Wiki?

Elaborating from this, one might ask "what is Struts?"   Particularly 
when one looks at the chain-processing model, the definition becomes 
much more amorphous.  Then again, I don't think the answer is 
critically important.  I don't really care what it's called; I just 
want a webapp framework that makes my job easier.  Continuity with 
Struts 1.x will help with that, since I won't have to live through 
retraining myself and the whole team -- but we've learned to deal 
with lots of change anyway.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JerichoFaces ?

2004-11-17 Thread Dakota Jack
Again, Craig, we are in complete agreement.  I also am madly in love
with the basic idea behind Tiles and with what Tiles does.  I don't
see why everyone isn't.

Tiles, however, uses a "controller" in a very different sense than the
sense Struts uses a web framework controller in a MVC pattern.  Tiles
is not at all like Java ServerFaces.  That is to mix apples and
oranges.

Tiles, unlike Java ServerFaces, is perfectly consistent with Struts.  

Indeed, the JerichoFaces envisioned at http://131.191.32.112:8080/
encompasses the whole Tiles idea.

The fact that Tiles has an interface used to insert the referents of
attributes in definitions which is called incidentally called
"Controller" does not mean it is anything like a controller in an MVC
framework.  It is not.

Tiles is not a page based MVC controller or any type of MVC controller
at all, and is consistent with either a page based controller such as
Java ServerFaces or a controller that keeps the view and the model
appropriately separate such as Struts.  RIght?

The bottom line is that Shale is wholly inconsistent with the Struts
approach.  If Struts 2.0 becomes Shale, Struts is dead.  That would
be, I think, a shame.  I would encourage Shale and Struts.  I know
that as things stand, I simply cannot go the Shale route.  So far my
concerns are magnified not ameliorated by my admitted learning curve
on Java ServerFaces.  If Shale were to adopt something like Java
ServerFaces but consistent with Sttuts, that would be different.  But
that is not in the mix, so the difference is moot.

As you can see, at http://131.191.32.112:8080/ I have now split up
JerichoData and JerichoFaces.  I think that a wholly separate event
based architecture with a multithreaded scheduler on the side is
needed for workflow.  That is what I have been doing for about six
months and I am very happy with the results.  The View in the MVC does
not care about the model, really.  What it cares about is what
eventually is moved to request, page (tile), session and application
scope and is available to tags.  Consequently, I think that an
abstraction which provides a framework data center apart from the
model data in databases, etc., not only makes sense but will allow
workflows to concentrate on algorithms and policies and not worry
about where the data is.  The data will be where the interface between
the JerichoFaces and JerichoData says it is.  The basic idea is just
to have a Data interface which JerichoFaces can use to retrieve its
Data for its components.

Thanks for your thoughts.  Please feel free to smack me around if
there is some legitimate sense in which Tiles Controller classes can
be considered to be a controller in the MVC pattern in Struts.




On Wed, 17 Nov 2004 21:52:56 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Nov 2004 21:43:14 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > Craig,
> >
> > I not only have no technical arguments against a View Helper design
> > pattern, but the suggestion on the Wiki WhiteBoard for Struts both for
> > the JerichoData and the JerichoFaces is an instance of advocating such
> > a design pattern.  What I don't trust is the page based controller.
> 
> It's sort of interesting that a "page controller" is one of the things
> people really like about Tiles, for the same reason I like it --
> cutting down on the number of moving parts :-).
> 
>   http://struts.apache.org/api/org/apache/struts/tiles/Controller.html
> 
> >
> > Jack
> >
> 
> Craig
> 
> 
> 
> 
> >
> > >Personally, I'm underwhelmed by the technical arguments made against a
> > >View Helper design pattern so far, so I'm not particularly interested
> > >(personally) in Jericho or JerichoFaces as a solution to anything --
> > >but who knows, some of the other developers might be.
> >
> > --
> > "You can't wake a person who is pretending to be asleep."
> >
> > ~Native Proverb~
> >
> > "Each man is good in His sight. It is not necessary for eagles to be crows."
> >
> > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-17 Thread Craig McClanahan
On Wed, 17 Nov 2004 21:43:14 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Craig,
> 
> I not only have no technical arguments against a View Helper design
> pattern, but the suggestion on the Wiki WhiteBoard for Struts both for
> the JerichoData and the JerichoFaces is an instance of advocating such
> a design pattern.  What I don't trust is the page based controller.

It's sort of interesting that a "page controller" is one of the things
people really like about Tiles, for the same reason I like it --
cutting down on the number of moving parts :-).

  http://struts.apache.org/api/org/apache/struts/tiles/Controller.html

> 
> Jack
> 

Craig


> 
> >Personally, I'm underwhelmed by the technical arguments made against a
> >View Helper design pattern so far, so I'm not particularly interested
> >(personally) in Jericho or JerichoFaces as a solution to anything --
> >but who knows, some of the other developers might be.
> 
> --
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for eagles to be crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-17 Thread Dakota Jack
Craig,

I not only have no technical arguments against a View Helper design
pattern, but the suggestion on the Wiki WhiteBoard for Struts both for
the JerichoData and the JerichoFaces is an instance of advocating such
a design pattern.  What I don't trust is the page based controller.

Jack

>Personally, I'm underwhelmed by the technical arguments made against a
>View Helper design pattern so far, so I'm not particularly interested
>(personally) in Jericho or JerichoFaces as a solution to anything --
>but who knows, some of the other developers might be.


--
"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JerichoFaces ?

2004-11-15 Thread Craig McClanahan
Jack,

Two things you might want to do ...

* Note that several of the Struts developers are currently
  at ApacheCon in Las Vegas this week (not me, alas, due
  to scheduling conflicts).

* Migrate discussions like this over to the developer list,
  since that's where decisions on the future will actually
  be made.

Personally, I'm underwhelmed by the technical arguments made against a
View Helper design pattern so far, so I'm not particularly interested
(personally) in Jericho or JerichoFaces as a solution to anything --
but who knows, some of the other developers might be.

Craig


On Mon, 15 Nov 2004 16:42:16 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Instead of having the Java ServerFaces controller handle both the
> relationship to the controller and to the model from the view, what if
> we employed the Jericho update to Struts 2.0 and added as an option a
> JerichoFaces that only interfaced with the model, having a view
> controller that did not take over the controller function of the "MVC"
> pattern, e.g.
> 
>view <==> contoller <==> model <==> view <==> etc. or
> 
>controller
> 
> view  model
> 
> See http://131.191.32.112:8080/ for a diagram.
> 
> Jack
> 
> --
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for eagles to be crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



JerichoFaces ?

2004-11-15 Thread Dakota Jack
Instead of having the Java ServerFaces controller handle both the
relationship to the controller and to the model from the view, what if
we employed the Jericho update to Struts 2.0 and added as an option a
JerichoFaces that only interfaced with the model, having a view
controller that did not take over the controller function of the "MVC"
pattern, e.g.

   view <==> contoller <==> model <==> view <==> etc. or 


   controller

view  model

See http://131.191.32.112:8080/ for a diagram.

Jack

-- 
"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]