Re: JerichoFaces ?
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 ?
: 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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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]