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. Struts has a considerable history of being "cast in[to] something concrete". I am not sanguine about the value of theoretical discussions at the level of UML diagrams, etc., however. I think they are important. We now know enough about the behavior of object oriented design patterns to know that they are not merely "airy-fairy" discussions. As you noted once, keeping a copy of J2EE design patterns next to you as you code is a serious and great help. I think theoretical groundings and plans prior to coding not only mean mean something rather than "doesn't mean anything" but think that they are more important than the typing that produces the code. Anyway, later I will address Joe's questions. Jack --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
