Re: [OT] Re: Advice for Struts expert wanting to try Shale?
I'm thinking you _still_ don't know what libel is, but feel free to sue me. Leave my employer out of it. As we're fond of saying, no jumping in. If you'd rather I posted only from one of my non-work email accounts I'm happy to do that as well if it makes you feel better. If you'd like to meet in person to discuss this issue I'm happy to oblige. And yes, I posted this to the group rather than you personally, because: a) you won't talk to me directly b) you felt so wronged that you emailed my boss rather than me b) I just like people to know what's going on behind the scenes Dave Dave Newton wrote: Dakota Jack wrote: Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not calling you the mythological (perhaps quasi-mythological) creature from fables, I'm calling you an internet troll as defined here: http://en.wikipedia.org/wiki/Internet_troll. From time to time you post genuinely useful stuff; the rest of the time you take four sentences to tell somebody how little they know and attempt to pass it off as somehow being helpful, enlightening, or educational... but it's not: it's mean-spirited and demeaning. You can tell somebody you think they're wrong in much better ways. I have personally developed a slew of ways of calling people stupid that allow them the honor of thanking me for doing it afterwards. It's actually a LOT more fun that way. I don't mentor people by telling them how little they know about a technology or the relative merits of one versus another; that isn't functional. I don't teach my students by pointing out how little they know and making constant, somewhat passive-aggressive comments regarding their lack of knowledge. I am supportive and encouraging: _that's_ what makes an educator great, and I'm not even all that good. Of course, much of the negative commentary you write to and about people that disagree with you, whether or not they're correct (I, at least, believe you make perfectly valid points at times) might _also_ be construed as libel, as defined by the _American and English Encylopedia of Law_ as: a malicious defamation expressed either by writing or printing or by signs, pictures, effigies or the like; tending to blacken the memory of one who is dead, or to impeach the honesty, integrity, virtue or reputation, or to publish the natural or alleged defects of one who is alive, thereby exposing him to public hatred, contempt, ridicule or obloquy; or to cause him to be avoided or shunned or to injure him in his office, business or occupation. There are several interesting bits contained within this definition that warrant closer examination. 1) Malicious. I don't even consider _your_ negative posts malicious, I just consider them rude and demeaning. I don't think I've ever seen a truly malicious post, even including some of the more unsavory ones from ex-listers gone awry ;) 2) [...] impeach the honesty, integrity [...] If anyone should tread lightly in this area it would have to be those that question the motives of certain developers regarding certain technologies that some of us may or may not like or approve of. 3) If a post here ever caused anybody to be exposed to public hatred, contempt, ridicule or obloquy I'd be impressed, as I really didn't think our readership was that high. 4) [...] cause him to be avoided or shunned or to injure him [...] Have you noticed that the only posts of yours that people reply to are the ones that either contain useful information, questions, etc. or are dealing with somebody that hasn't learned to your mean, trolling ones? The one that has been most exposed to public contempt, at least, appears to be you, and the one most shunned in this (according to you) professional setting is _you_. I believe you're smart and capable yet I see your posts in my inbox like an accident on the side of the road: I don't want to look, because so often there's blood and mayhem, but I feel compelled to. Occasionally I am pleasantly surprised with an actual discussion. I'll admit a certain amount of disappointment sometimes that there isn't another wonderful flame-fest brewing, but I generally get over that fairly quickly. This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. This is a mailing list, not an office. This is, at best, a professional-as-possible setting. Would you use the language you use against those who disgree with you in a professional setting? _I_ sure wouldn't, and I wouldn't tolerate it from anybody that worked with me or for me, either. Quite frankly, idiocies _do_ seem to be rather common fare, but that's because people seem incapable
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
Let me get this right, he _told on you_ ... as in tattletale??? That's just repugnant and pitiful. Did we not learn anything last year when Mark lost his job? -Dennis Dave Newton [EMAIL PROTECTED] 01/11/2006 11:27 AM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org, Rob Freda [EMAIL PROTECTED] cc Subject Re: [OT] Re: Advice for Struts expert wanting to try Shale? I'm thinking you _still_ don't know what libel is, but feel free to sue me. Leave my employer out of it. As we're fond of saying, no jumping in. If you'd rather I posted only from one of my non-work email accounts I'm happy to do that as well if it makes you feel better. If you'd like to meet in person to discuss this issue I'm happy to oblige. And yes, I posted this to the group rather than you personally, because: a) you won't talk to me directly b) you felt so wronged that you emailed my boss rather than me b) I just like people to know what's going on behind the scenes Dave Dave Newton wrote: Dakota Jack wrote: Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not calling you the mythological (perhaps quasi-mythological) creature from fables, I'm calling you an internet troll as defined here: http://en.wikipedia.org/wiki/Internet_troll. From time to time you post genuinely useful stuff; the rest of the time you take four sentences to tell somebody how little they know and attempt to pass it off as somehow being helpful, enlightening, or educational... but it's not: it's mean-spirited and demeaning. You can tell somebody you think they're wrong in much better ways. I have personally developed a slew of ways of calling people stupid that allow them the honor of thanking me for doing it afterwards. It's actually a LOT more fun that way. I don't mentor people by telling them how little they know about a technology or the relative merits of one versus another; that isn't functional. I don't teach my students by pointing out how little they know and making constant, somewhat passive-aggressive comments regarding their lack of knowledge. I am supportive and encouraging: _that's_ what makes an educator great, and I'm not even all that good. Of course, much of the negative commentary you write to and about people that disagree with you, whether or not they're correct (I, at least, believe you make perfectly valid points at times) might _also_ be construed as libel, as defined by the _American and English Encylopedia of Law_ as: a malicious defamation expressed either by writing or printing or by signs, pictures, effigies or the like; tending to blacken the memory of one who is dead, or to impeach the honesty, integrity, virtue or reputation, or to publish the natural or alleged defects of one who is alive, thereby exposing him to public hatred, contempt, ridicule or obloquy; or to cause him to be avoided or shunned or to injure him in his office, business or occupation. There are several interesting bits contained within this definition that warrant closer examination. 1) Malicious. I don't even consider _your_ negative posts malicious, I just consider them rude and demeaning. I don't think I've ever seen a truly malicious post, even including some of the more unsavory ones from ex-listers gone awry ;) 2) [...] impeach the honesty, integrity [...] If anyone should tread lightly in this area it would have to be those that question the motives of certain developers regarding certain technologies that some of us may or may not like or approve of. 3) If a post here ever caused anybody to be exposed to public hatred, contempt, ridicule or obloquy I'd be impressed, as I really didn't think our readership was that high. 4) [...] cause him to be avoided or shunned or to injure him [...] Have you noticed that the only posts of yours that people reply to are the ones that either contain useful information, questions, etc. or are dealing with somebody that hasn't learned to your mean, trolling ones? The one that has been most exposed to public contempt, at least, appears to be you, and the one most shunned in this (according to you) professional setting is _you_. I believe you're smart and capable yet I see your posts in my inbox like an accident on the side of the road: I don't want to look, because so often there's blood and mayhem, but I feel compelled to. Occasionally I am pleasantly surprised with an actual discussion. I'll admit a certain amount of disappointment sometimes that there isn't another wonderful flame-fest brewing, but I generally get over
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
[EMAIL PROTECTED] wrote: Let me get this right, he _told on you_ ... as in tattletale??? Yeah :D Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
On 1/11/06, Dave Newton [EMAIL PROTECTED] wrote: If you'd rather I posted only from one of my non-work email accounts Better yet, take out a gmail account under a pseudonym, and then refer to Dave Newton in the third person. :) There's a reason why executioners wore a mask. Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: Advice for Struts expert wanting to try Shale?
Let me get this right, he _told on you_ ... as in tattletale??? Opinion... If I were his employer, I would like to know what how he was behaving if: 1) He was doing/posting things from a corporate email address that might reflect badly on my company. 2) Spreading inflammatory comments while under my employ BUT using his own email address IF a search engine brought up both sets of information simultaneously, thus reflecting badly on my company by bringing both of his references (us and his) together in one unflattering light. It's called bad PR and it costs employers money. Regards, David P.S. Still waiting for him to sue me... but I stopped holding my breath months ago because I was - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: Advice for Struts expert wanting to try Shale?
Wait. You're not Dave are you? :-) B. -Original Message- From: Albany Rose [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 1:54 PM To: user@struts.apache.org Subject: Re: [OT] Re: Advice for Struts expert wanting to try Shale? On 1/11/06, Dave Newton [EMAIL PROTECTED] wrote: If you'd rather I posted only from one of my non-work email accounts Better yet, take out a gmail account under a pseudonym, and then refer to Dave Newton in the third person. :) There's a reason why executioners wore a mask. Al. - 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: [OT] Re: Advice for Struts expert wanting to try Shale?
There's a reason why executioners wore a mask. Because they couldn't stand the smell of Dakota Jack? *snicker* Well, I've said my two snide comments as the moon nears full so I'll return you to your regularly scheduled code discussions. Regards, David P.S. Struts-Shale, that means you! ;) -- see, on topic reference! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
LOL ok last post in this thread, but this is pathetic. He hijacks the majority of threads about Shale to say how JSF sucks compare to Struts. He even says JSF is visual basic and Struts is C++, wich I can't believe he's doesn't see as a provocative post. He's not polite and he's unrespectful to a lot of people and yet he complains when people are tired of his attitude and call him a Troll. I can't understand he didn't see that coming from miles. Sorry, Dakota, I think your attitude is really offending and pitiful. You brought this upon yourself. Email my boss if you want or sue me if you want (I hope your lawyers knows the french civil code). Well, I apologize for this post to the other people on this mailing list, I don't like to critizice a person attitude publicly but I think he's going way too far now. On 1/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Let me get this right, he _told on you_ ... as in tattletale??? That's just repugnant and pitiful. Did we not learn anything last year when Mark lost his job? -Dennis Dave Newton [EMAIL PROTECTED] 01/11/2006 11:27 AM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org, Rob Freda [EMAIL PROTECTED] cc Subject Re: [OT] Re: Advice for Struts expert wanting to try Shale? I'm thinking you _still_ don't know what libel is, but feel free to sue me. Leave my employer out of it. As we're fond of saying, no jumping in. If you'd rather I posted only from one of my non-work email accounts I'm happy to do that as well if it makes you feel better. If you'd like to meet in person to discuss this issue I'm happy to oblige. And yes, I posted this to the group rather than you personally, because: a) you won't talk to me directly b) you felt so wronged that you emailed my boss rather than me b) I just like people to know what's going on behind the scenes Dave Dave Newton wrote: Dakota Jack wrote: Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not calling you the mythological (perhaps quasi-mythological) creature from fables, I'm calling you an internet troll as defined here: http://en.wikipedia.org/wiki/Internet_troll. From time to time you post genuinely useful stuff; the rest of the time you take four sentences to tell somebody how little they know and attempt to pass it off as somehow being helpful, enlightening, or educational... but it's not: it's mean-spirited and demeaning. You can tell somebody you think they're wrong in much better ways. I have personally developed a slew of ways of calling people stupid that allow them the honor of thanking me for doing it afterwards. It's actually a LOT more fun that way. I don't mentor people by telling them how little they know about a technology or the relative merits of one versus another; that isn't functional. I don't teach my students by pointing out how little they know and making constant, somewhat passive-aggressive comments regarding their lack of knowledge. I am supportive and encouraging: _that's_ what makes an educator great, and I'm not even all that good. Of course, much of the negative commentary you write to and about people that disagree with you, whether or not they're correct (I, at least, believe you make perfectly valid points at times) might _also_ be construed as libel, as defined by the _American and English Encylopedia of Law_ as: a malicious defamation expressed either by writing or printing or by signs, pictures, effigies or the like; tending to blacken the memory of one who is dead, or to impeach the honesty, integrity, virtue or reputation, or to publish the natural or alleged defects of one who is alive, thereby exposing him to public hatred, contempt, ridicule or obloquy; or to cause him to be avoided or shunned or to injure him in his office, business or occupation. There are several interesting bits contained within this definition that warrant closer examination. 1) Malicious. I don't even consider _your_ negative posts malicious, I just consider them rude and demeaning. I don't think I've ever seen a truly malicious post, even including some of the more unsavory ones from ex-listers gone awry ;) 2) [...] impeach the honesty, integrity [...] If anyone should tread lightly in this area it would have to be those that question the motives of certain developers regarding certain technologies that some of us may or may not like or approve of. 3) If a post here ever caused anybody to be exposed to public hatred, contempt, ridicule
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
On 1/11/06, Brantley Hobbs [EMAIL PROTECTED] wrote: You're not Dave are you? :-) Dave's not here. Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Dakota Jack wrote: The view controller is not a controller in the Web-MVC sense and is completely misleading, in my opinion, Mark. So part of this just may be who's dog is in the hunt? The point of the tool-based and VB analogy is that JSF tries to hide from you, to do it for you, what other frameworks, like Struts, demand you know. This allows quick turnaround and allows the construction of tools. This was the charter for JSF. It is not a bug, it is deliberate. So, if this confuses a new person, at least it has the value of being accurate as hell. Well in my opinion JSF is much closer to the traditional way of doing user interfaces than Struts, most people who have a clear experience in user interfaces probably grasp the page centric approach of JSF easier than the enforced action centric approach of Struts. The terms, component, Page, Backend Controller are visible in one way or the other in most rich client uis, also the validation on component levels, the events etc... In one way the comparison to Visual Basic is valid, because it brings a rich client approach to the page-action-page mix of html and struts. But from a functionality point of view JSF is sort of Struts 2.0 because the more you dive into the framework them more you see that basically everything (sans client side validation) of Struts still is there, but so much more and everything especially configurationwise a tad more cleaned up and with less xml. So, if you want to use programmers with little experience and train them to use the inevitable tools, just like with the community college VB junkies, JSF is a good alternative. If you think a smaller cadre of thinking and knowing engineers is the way to go, like cs graduates who know Java or C++, then Struts is the way to go. I do not think so, JSF is definitely not graspable by the first community, because once you get out of the we have a set of component level, things become more complicated than the usual visual tool user can handle. Struts never even tries to reach the visual level. But does not cover all areas jsf covers. If you dive deeper into JSF you can find that JSF partially was derived from Struts, but adds lots of stuff to the mix. But one thing for me in JSF is heavens sent, that you finally have a huge number of components and a clear and good event system, the rest is up to the taste, after all you cannot really change within the boundaries of HTML how html behaves. If you go the enforced model controller route or the non enforce model view controller or model view route is up to personal taste. JSF is not more page centric than Struts. JSF is page centric. Struts is not page centric. Something has to take JSF from page to page, and this is called a view controller due to an unfortunate naming of a pattern having to do with views, pages. This, again, is NOT a controller as you find in Struts. Actually it is the nav handler :-), it just happens that you have the controller logic in the backend beans and thus you get an action controller that way. What you probably mean is the view handler, but that is something entirely different, and nav and view handlers are replaceable parts. I personally would find my VB and C++ the most helpful. I always find heuristics the most helpful, unless you want to get bogged down in irrelevant detail, like view controller. This is essentially the sort of choice you are making. VB is a tool based, dumbed down, language. JSF is a tool based, dumbed down framework. C++ is a full blown language. Struts is a full blown framework. I assume you never had a serious look at jsf, judging a framework by its tools and never look beyound is always bad ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Advice for Struts expert wanting to try Shale?
Dakota Jack wrote: Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not calling you the mythological (perhaps quasi-mythological) creature from fables, I'm calling you an internet troll as defined here: http://en.wikipedia.org/wiki/Internet_troll. From time to time you post genuinely useful stuff; the rest of the time you take four sentences to tell somebody how little they know and attempt to pass it off as somehow being helpful, enlightening, or educational... but it's not: it's mean-spirited and demeaning. You can tell somebody you think they're wrong in much better ways. I have personally developed a slew of ways of calling people stupid that allow them the honor of thanking me for doing it afterwards. It's actually a LOT more fun that way. I don't mentor people by telling them how little they know about a technology or the relative merits of one versus another; that isn't functional. I don't teach my students by pointing out how little they know and making constant, somewhat passive-aggressive comments regarding their lack of knowledge. I am supportive and encouraging: _that's_ what makes an educator great, and I'm not even all that good. Of course, much of the negative commentary you write to and about people that disagree with you, whether or not they're correct (I, at least, believe you make perfectly valid points at times) might _also_ be construed as libel, as defined by the _American and English Encylopedia of Law_ as: a malicious defamation expressed either by writing or printing or by signs, pictures, effigies or the like; tending to blacken the memory of one who is dead, or to impeach the honesty, integrity, virtue or reputation, or to publish the natural or alleged defects of one who is alive, thereby exposing him to public hatred, contempt, ridicule or obloquy; or to cause him to be avoided or shunned or to injure him in his office, business or occupation. There are several interesting bits contained within this definition that warrant closer examination. 1) Malicious. I don't even consider _your_ negative posts malicious, I just consider them rude and demeaning. I don't think I've ever seen a truly malicious post, even including some of the more unsavory ones from ex-listers gone awry ;) 2) [...] impeach the honesty, integrity [...] If anyone should tread lightly in this area it would have to be those that question the motives of certain developers regarding certain technologies that some of us may or may not like or approve of. 3) If a post here ever caused anybody to be exposed to public hatred, contempt, ridicule or obloquy I'd be impressed, as I really didn't think our readership was that high. 4) [...] cause him to be avoided or shunned or to injure him [...] Have you noticed that the only posts of yours that people reply to are the ones that either contain useful information, questions, etc. or are dealing with somebody that hasn't learned to your mean, trolling ones? The one that has been most exposed to public contempt, at least, appears to be you, and the one most shunned in this (according to you) professional setting is _you_. I believe you're smart and capable yet I see your posts in my inbox like an accident on the side of the road: I don't want to look, because so often there's blood and mayhem, but I feel compelled to. Occasionally I am pleasantly surprised with an actual discussion. I'll admit a certain amount of disappointment sometimes that there isn't another wonderful flame-fest brewing, but I generally get over that fairly quickly. This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. This is a mailing list, not an office. This is, at best, a professional-as-possible setting. Would you use the language you use against those who disgree with you in a professional setting? _I_ sure wouldn't, and I wouldn't tolerate it from anybody that worked with me or for me, either. Quite frankly, idiocies _do_ seem to be rather common fare, but that's because people seem incapable of looking at documentation. Sorry to have to discuss something other than the issues. Why apologize THIS time?! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Sorry to repost this, but I wanted to know if I was the only one facing this difficulty and if it's the case how to avoid it. Any thougts? On 1/8/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Just a small correction below : On 1/8/06, Alexandre Poitras [EMAIL PROTECTED] wrote: I am developping a navigation panel like the panel2 from tomahawk (I had to offer some more features) and I like the way you can embedd some navigation items tags (NavigationItem, NavigationItems) inside the navigation tag to specify the different elements of the panel. Since the navigation model elements need some more attributes then SelectItem like an action attribute (supporting MethodBinding of course), you end up developping some custom models elements just adding some more attributes. I think this part is alright, I don't want to use something generic like DynaFormBean in Struts but I think some base model elements could be standardized like a base class Item and some subclasses like SelectItem and ActionItem (I read somewhere there something similar in Oracle ADF components, maybe I should take a look). The problem I see here is you have to implement for each kind of model, two custom UIxxxItem and UIxxxItems components so you can end up with a lot of redundant UI components. This problem is quite familiar in the OO world and it is usually solved elegantly by the Bridge pattern, where here model elements are the abstraction hierarchy and the UIxxxItem and UIxxxItems are the implementations specific. I mean the inverse, he UIxxxItem and UIxxxItems are the abstraction hierarchy and the model elements the implementation hierarchy. So what I would like is to be able to always use the same UI components to specify the model of a parent UI component. What I am doing right now, is whenever a component have a model defined by child elements, it implements a custom interface having a method returning the model class it supports and making sure all model elements have a constructor taking a properties map as an input (in case the element must be built from the UIxxxItem properties). Then I have developped a custom iterator capable of going throught any UI component model implemented by those standard model UI components. Maybe someone have a better design to propose me but it seems to do the trick for the moment. What do you think? Of course with JSP you need to developp a lot of custom tags but I guess not with Clay or facelets :)) Here's the link to the Tomahawk panel I was refering to : http://www.irian.at/myfaces/panelnavigation_2.jsp.source On 1/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Just a couple of comments intermixed below. On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. While these are the only two events defined in the standard, it is perfectly feasible for JSF components to define their own events, and their own event handlers, using the same basic infrastructure. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to
Re: Advice for Struts expert wanting to try Shale?
for Struts expert wanting to try Shale? On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ted Husted wrote: An expert uses the best tool for the job. A journeyman wants one size to fit all. Blessed are those who get to make such decisions. There are unfortunately many shops that decide what the proper technologies are *before* any project kicks off, all in the name of standardization. And some shops even standardize on details like which IDE everyone *must* use. :) Happily, before long, an enterprise will be able to standardize on Apache Struts, and some lucky developers will be able to at least choose the best Struts tool for the job. Perhaps one day we won't have to type cast every problem as a nail. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. I would keep that in mind if I were you. This is not some free-fire zone where you can treat people outside the law. If you have your opinions, that is well and good. Don't negate mine with statements like this unless you want to have to prove the matter in a court of law. This is made public rather than to you personally to give other similarly lacking in enlightenment fair warning. Sorry to have to discuss something other than the issues. On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html tags and it was complex to bind complex forms. In JSF, you can use EL value bindings or method bindings expressions. It is really great in my mind and very simple at the same time, thank to IoC and managed beans. - Finally, JSF has a component model and so reusing is very easy. The components hide most of the complexity to the developper (ugly javascript for exemple). Learning to developp components is what take time to learn, but you can get started quite fast if you just want to use it first. At least, there are a lot of exemples available. - One last thing, since the data and method bindings are specified in the jsp/html/whatever technologie you use for view page and the navigation is specified globally in the configuration file (not per action like in Struts), it is quite easy to follow the application flow. It was something that was annoying me sometimes with Struts, lot of places to look to find where the executed code is located. I hope it's help and since I am far from considering me a JSF expert, anyone can feel free to correct me. And please be tolerant about my english since I am not a native speaker and it's quite a long post :) On a side note for people having experience developping custom components, what annoys me so far in JSF is the model package, in fact the SelectItem class. There are no model objets for action components (like you need for a menu or navigation panel) and no universal components (UISelectItem and UISelectItems) for specifying the model. You need one for each component and it is quite a pain in the a.. to code those again and again. Anyway, it always possible to develop your own model hierarchy and use an adaptor to make SelectItem compatible with it. As anyone had the same problem so far? If it is the case, maybe a solution could be part of the future commons-jsf package that have been discussed in the past. I am working on something around this problem so I could probably submit it once I'm done. On 1/7/06, Dakota Jack
Re: Advice for Struts expert wanting to try Shale?
From: Dakota Jack [EMAIL PROTECTED] Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a troll in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. Actually, I've always thought of this kind of troll http://www.pitt.edu/~dash/type0122e.html This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. I would keep that in mind if I were you. This is not some free-fire zone where you can treat people outside the law. If you have your opinions, that is well and good. Don't negate mine with statements like this unless you want to have to prove the matter in a court of law. This is made public rather than to you personally to give other similarly lacking in enlightenment fair warning. Sorry to have to discuss something other than the issues. Very interesting, and only if as much intellectual collateral was spent addressing technical issues... On 1/7/06, Alexandre Poitras wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html tags and it was complex to bind complex forms. In JSF, you can use EL value bindings or method bindings expressions. It is really great in my mind and very simple at the same time, thank to IoC and managed beans. - Finally, JSF has a component model and so reusing is very easy. The components hide most of the complexity to the developper (ugly javascript for exemple). Learning to developp components is what take time to learn, but you can get started quite fast if you just want to use it first. At least, there are a lot of exemples available. - One last thing, since the data and method bindings are specified in the jsp/html/whatever technologie you use for view page and the navigation is specified globally in the configuration file (not per action like in Struts), it is quite easy to follow the application flow. It was something that was annoying me sometimes with Struts, lot of places to look to find where the executed code is located. I hope it's help and since I am far from considering me a JSF expert, anyone can feel free to correct me. And please be tolerant about my english since I am not a native speaker and it's quite a long post :) On a side note for people having experience developping custom components, what annoys me so far in JSF is the model package, in fact the SelectItem class. There are no model objets for action components (like you need for a menu or navigation panel) and no universal components (UISelectItem and UISelectItems) for specifying the model. You need one for each component and it is quite a pain in the a.. to code those again and again. Anyway, it always
Re: Advice for Struts expert wanting to try Shale?
Gary VanMatre wrote: Very interesting, and only if as much intellectual collateral was spent addressing technical issues... Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Frank W. Zammetti [EMAIL PROTECTED] wrote on 01/08/2006 11:29:54 AM: Gary VanMatre wrote: Very interesting, and only if as much intellectual collateral was spent addressing technical issues... Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL Frank Which certainly suggests a new entry for the you are a geek if .. :)) Geeta
Re: Advice for Struts expert wanting to try Shale?
Trollomic? Combination of Troll and Comic? One who is a troll and yet makes you laugh at the same time? Frank [EMAIL PROTECTED] wrote: Frank W. Zammetti [EMAIL PROTECTED] wrote on 01/08/2006 11:29:54 AM: Gary VanMatre wrote: Very interesting, and only if as much intellectual collateral was spent addressing technical issues... Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL Frank Which certainly suggests a new entry for the you are a geek if .. :)) Geeta -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Just a small correction below : On 1/8/06, Alexandre Poitras [EMAIL PROTECTED] wrote: I am developping a navigation panel like the panel2 from tomahawk (I had to offer some more features) and I like the way you can embedd some navigation items tags (NavigationItem, NavigationItems) inside the navigation tag to specify the different elements of the panel. Since the navigation model elements need some more attributes then SelectItem like an action attribute (supporting MethodBinding of course), you end up developping some custom models elements just adding some more attributes. I think this part is alright, I don't want to use something generic like DynaFormBean in Struts but I think some base model elements could be standardized like a base class Item and some subclasses like SelectItem and ActionItem (I read somewhere there something similar in Oracle ADF components, maybe I should take a look). The problem I see here is you have to implement for each kind of model, two custom UIxxxItem and UIxxxItems components so you can end up with a lot of redundant UI components. This problem is quite familiar in the OO world and it is usually solved elegantly by the Bridge pattern, where here model elements are the abstraction hierarchy and the UIxxxItem and UIxxxItems are the implementations specific. I mean the inverse, he UIxxxItem and UIxxxItems are the abstraction hierarchy and the model elements the implementation hierarchy. So what I would like is to be able to always use the same UI components to specify the model of a parent UI component. What I am doing right now, is whenever a component have a model defined by child elements, it implements a custom interface having a method returning the model class it supports and making sure all model elements have a constructor taking a properties map as an input (in case the element must be built from the UIxxxItem properties). Then I have developped a custom iterator capable of going throught any UI component model implemented by those standard model UI components. Maybe someone have a better design to propose me but it seems to do the trick for the moment. What do you think? Of course with JSP you need to developp a lot of custom tags but I guess not with Clay or facelets :)) Here's the link to the Tomahawk panel I was refering to : http://www.irian.at/myfaces/panelnavigation_2.jsp.source On 1/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Just a couple of comments intermixed below. On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. While these are the only two events defined in the standard, it is perfectly feasible for JSF components to define their own events, and their own event handlers, using the same basic infrastructure. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. I actually wish there wasn't be so much difference here :-(. In the original vision of Struts, the idea of an ActionForward was very much to describe an *outcome* (this is what happened), not a *destination* (this is where to go next). Unfortunately, most Struts
Re: Advice for Struts expert wanting to try Shale?
this person PRODUCTIVE Yes I have learned that obfuscation and confusion are more than acceptable substitutes for generating working code - Original Message - From: Mark Lowe [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, January 07, 2006 6:44 AM Subject: Re: Advice for Struts expert wanting to try Shale? On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
I am developping a navigation panel like the panel2 from tomahawk (I had to offer some more features) and I like the way you can embedd some navigation items tags (NavigationItem, NavigationItems) inside the navigation tag to specify the different elements of the panel. Since the navigation model elements need some more attributes then SelectItem like an action attribute (supporting MethodBinding of course), you end up developping some custom models elements just adding some more attributes. I think this part is alright, I don't want to use something generic like DynaFormBean in Struts but I think some base model elements could be standardized like a base class Item and some subclasses like SelectItem and ActionItem (I read somewhere there something similar in Oracle ADF components, maybe I should take a look). The problem I see here is you have to implement for each kind of model, two custom UIxxxItem and UIxxxItems components so you can end up with a lot of redundant UI components. This problem is quite familiar in the OO world and it is usually solved elegantly by the Bridge pattern, where here model elements are the abstraction hierarchy and the UIxxxItem and UIxxxItems are the implementations specific. So what I would like is to be able to always use the same UI components to specify the model of a parent UI component. What I am doing right now, is whenever a component have a model defined by child elements, it implements a custom interface having a method returning the model class it supports and making sure all model elements have a constructor taking a properties map as an input (in case the element must be built from the UIxxxItem properties). Then I have developped a custom iterator capable of going throught any UI component model implemented by those standard model UI components. Maybe someone have a better design to propose me but it seems to do the trick for the moment. What do you think? Of course with JSP you need to developp a lot of custom tags but I guess not with Clay or facelets :)) Here's the link to the Tomahawk panel I was refering to : http://www.irian.at/myfaces/panelnavigation_2.jsp.source On 1/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Just a couple of comments intermixed below. On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. While these are the only two events defined in the standard, it is perfectly feasible for JSF components to define their own events, and their own event handlers, using the same basic infrastructure. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. I actually wish there wasn't be so much difference here :-(. In the original vision of Struts, the idea of an ActionForward was very much to describe an *outcome* (this is what happened), not a *destination* (this is where to go next). Unfortunately, most Struts developers don't use forwards that way -- and you can make exactly the same mistake :-) when using logical outcomes in JSF. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html
Re: Advice for Struts expert wanting to try Shale?
JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
The view controller is not a controller in the Web-MVC sense and is completely misleading, in my opinion, Mark. So part of this just may be who's dog is in the hunt? The point of the tool-based and VB analogy is that JSF tries to hide from you, to do it for you, what other frameworks, like Struts, demand you know. This allows quick turnaround and allows the construction of tools. This was the charter for JSF. It is not a bug, it is deliberate. So, if this confuses a new person, at least it has the value of being accurate as hell. So, if you want to use programmers with little experience and train them to use the inevitable tools, just like with the community college VB junkies, JSF is a good alternative. If you think a smaller cadre of thinking and knowing engineers is the way to go, like cs graduates who know Java or C++, then Struts is the way to go. JSF is not more page centric than Struts. JSF is page centric. Struts is not page centric. Something has to take JSF from page to page, and this is called a view controller due to an unfortunate naming of a pattern having to do with views, pages. This, again, is NOT a controller as you find in Struts. I personally would find my VB and C++ the most helpful. I always find heuristics the most helpful, unless you want to get bogged down in irrelevant detail, like view controller. This is essentially the sort of choice you are making. VB is a tool based, dumbed down, language. JSF is a tool based, dumbed down framework. C++ is a full blown language. Struts is a full blown framework. On 1/7/06, Mark Lowe [EMAIL PROTECTED] wrote: On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float
Re: Advice for Struts expert wanting to try Shale?
Both struts and jsf provide a means of handling form submissons, that seems pretty view controller to me. I dont get how everything's so black and white and/or chalk and cheese. Sure you define views in jsf, and you can mess with more than just the forms, but are the differences really as profound or their similarities really comparable to VB and C++? Sorry I dont get it. When coding jsf and struts struff I get the feeling that I'm being abstracted from the servlet spec. What IDE vendors do is their affair, they've been trying to make coding brain dead for years and I doubt thats going to stop (note: I'm not saying that if someone uses an ide s/he is brain dead). But thats how JSF and struts are supported by IDE vendors not what they are in themselves, is a motorway made with tarmac or cars? Like i said before, C++ and VB like struts and jsf, sorry I'm trying to get it but I'm not there yet.. While I know there are differences between jsf and struts, I dont think they are as profound as you've stated. Amen, brother. I wish Mark would see this. So do I, I guess I'll have to keep at it, and maybe one day I can become just like you :o) More seriously I'd really like what I'm missing clarifed as there's obviously something I haven't understood. Mark On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: Amen, brother. I wish Mark would see this. On 1/7/06, Martin Gainty [EMAIL PROTECTED] wrote: let me assure you VB isnt the only course designed for tech support people wedged between auto-shop and recess yesterday I was prevented from implementing a script because the individual didnt want to grant me permissions to the ** directory i.e. The LAST thing I want to do is to make this person PRODUCTIVE Yes I have learned that obfuscation and confusion are more than acceptable substitutes for generating working code - Original Message - From: Mark Lowe [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, January 07, 2006 6:44 AM Subject: Re: Advice for Struts expert wanting to try Shale? On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers
Re: Advice for Struts expert wanting to try Shale?
By the way the so called application controller (RequestProcessor) pattern has NOTHING to do with the controller (action, backing bean), also called input controller, found in the so often misunderstood MVC pattern. The only similarity is the sharing of the term controller. If you don't believe me, you can look in the famous pattern books out there (Fowler, J2EE core patterns). So Dakota your argument doesn't make any senses to me unless you clarify wich controller you talk about... On 1/7/06, Mark Lowe [EMAIL PROTECTED] wrote: Both struts and jsf provide a means of handling form submissons, that seems pretty view controller to me. I dont get how everything's so black and white and/or chalk and cheese. Sure you define views in jsf, and you can mess with more than just the forms, but are the differences really as profound or their similarities really comparable to VB and C++? Sorry I dont get it. When coding jsf and struts struff I get the feeling that I'm being abstracted from the servlet spec. What IDE vendors do is their affair, they've been trying to make coding brain dead for years and I doubt thats going to stop (note: I'm not saying that if someone uses an ide s/he is brain dead). But thats how JSF and struts are supported by IDE vendors not what they are in themselves, is a motorway made with tarmac or cars? Like i said before, C++ and VB like struts and jsf, sorry I'm trying to get it but I'm not there yet.. While I know there are differences between jsf and struts, I dont think they are as profound as you've stated. Amen, brother. I wish Mark would see this. So do I, I guess I'll have to keep at it, and maybe one day I can become just like you :o) More seriously I'd really like what I'm missing clarifed as there's obviously something I haven't understood. Mark On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: Amen, brother. I wish Mark would see this. On 1/7/06, Martin Gainty [EMAIL PROTECTED] wrote: let me assure you VB isnt the only course designed for tech support people wedged between auto-shop and recess yesterday I was prevented from implementing a script because the individual didnt want to grant me permissions to the ** directory i.e. The LAST thing I want to do is to make this person PRODUCTIVE Yes I have learned that obfuscation and confusion are more than acceptable substitutes for generating working code - Original Message - From: Mark Lowe [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, January 07, 2006 6:44 AM Subject: Re: Advice for Struts expert wanting to try Shale? On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Mark On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: If you don't believe me, you can look in the famous pattern books out there (Fowler, J2EE core patterns). Some of which used Struts as one of the use cases to prove a pattern exists. :) But, in the end, it is what it is. What we call a mechanism is not as important as whether the mechanism suits a developer's needs. Sometimes JSF will work well for an application. Sometimes it won't. An expert uses the best tool for the job. A journeyman wants one size to fit all. Another example is SQL data mappers verus object relational mappers. Sometimes, iBATIS is the best tool for the job. Sometimes Cayene or Hibernate work even better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Ted Husted wrote: An expert uses the best tool for the job. A journeyman wants one size to fit all. Blessed are those who get to make such decisions. There are unfortunately many shops that decide what the proper technologies are *before* any project kicks off, all in the name of standardization. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Mark Lowe [EMAIL PROTECTED] wrote: On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: JSF is page centric rather than Action centric. There is no controller as you understand that in Struts with JSF. JSF is for a tool based, dumbed down, approach: JSF is to Struts as Visual Basic is to C++. JSF is more page centric than struts, but they aren't chalk and cheese. The view controller is still in the backing bean and then mapping of outcome to jsp is done via xml configuration. How page or controller centric you want jsf to be is upto you, this is where the diffence between JSF being a spec and struts a framework start being more visible. If you are familiar with Core J2EE Patterns terminology, you'll find it easiest to understand JSF and Shale in terms of the View Helper[1] pattern, where the helper items are the JSF component tags and your backing beans, and the Dispatcher View[2] pattern, which combines the Front Controller[3] and View Helper[1] patterns together. In the Dispatcher View sequence diagram (Figure 7.25) the roles and responsibilities match up like this: * Contrroller == FacesServlet * Dispatcher == the JSF Lifecycle object that manages the request processing lifecycle * View == The JSF view (often a JSP page, but not required with things like Clay or Facelets) * Helper == The backing bean assocated with the view (in Shale, the VIewController is a View Helper that does more than what you get in pure JSF applications) In a JSF application, there's actually two ways to implement classic Front Controller type functionality, such as send the user to the logon page if they are not currently logged on: * With a servlet Filter that gets invoked in front of the JSF controller (Shale has support for this). When Struts 1.0 was created, there was no such thing, so we had to provide this capability inside ActionServlet. Now, the container has a much more flexible mechanism that can work on either JSF requests or non-JSF requests. * By using a JSF PhaseListener to interact with the JSF Lifecycle (which has Controller capabilities as well) This is the way most AJAX enabled JSF components interact with the server side of their asynchronous requests ... they submit a request to a URL mapped to FacesServlet, and a component-provided PhaseListener intercepts control after the Restore View phase has completed. But the point is clear ... the Lifecycle implementation plays a controller role as well, and you can customize its behavior with phase listeners quite easily. If I was asking how to get started with jsf and shale I'd find your VB vs C++ statement confusing and not very helpful at all. Don't expect much help from someone who doesn't seem to care much for either JSF or Shale :-). Mark Craig [1] http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html [2] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html [3] http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Craig McClanahan [EMAIL PROTECTED] wrote:
In a JSF application, there's actually two ways to implement classic Front
Controller type functionality, such as send the user to the logon page if
they are not currently logged on:
Concrete examples will help make this clearer, so here are the pure-servlet
and pure-JSF ways to accomplish this:
* With a servlet Filter that gets invoked in front of the JSF controller
(Shale has support for this). When
Struts 1.0 was created, there was no such thing, so we had to provide
this capability inside ActionServlet.
Now, the container has a much more flexible mechanism that can work on
either JSF requests or
non-JSF requests.
import com.mycompany.mypackage.User;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
public class LogonCheckFilter implements Filter {
// No initialization required
public void init(FiterConfig config) {}
// No finalization required
public void destroy() {}
// Process each incoming request this filter is mapped to
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
// Check for a user object in session scope
User user = (User)
((HttpServletRequest) request).getSession().getAttribute(user);
// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on
// If the user is not logged on, redirect to the logon page
if (user == null) {
// Do a RequestDispatch.forward() to display the logon page
instead of the requested page
RequestDispatcher rd = ((HttpServletRequest)
request).getRequestDispatcher(/logon.jsp);
rd.forward(request, response);
return;
}
// Otherwise, do the standard processing for this request
chain.doFilter(request, response);
}
}
* By using a JSF PhaseListener to interact with the JSF Lifecycle (which has
Controller capabilities as well)
This is the way most AJAX enabled JSF components interact with the
server side of their asynchronous
requests ... they submit a request to a URL mapped to FacesServlet, and
a component-provided
PhaseListener intercepts control after the Restore View phase has
completed. But the point is clear ...
the Lifecycle implementation plays a controller role as well, and you
can customize its behavior with
phase listeners quite easily.
import com.mycompany.mypackage.User;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
public class LogonCheckListener implements PhaseListener {
// Tell JSF which lifecycle phase(s) we are interested in
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
// No before phase processing required
public void beforePhase(PhaseEvent event) {}
// Perform the logon check after restore view has been completed
public void afterPhase(PhaseEvent event) {
// Check for a user object in session scope
FacesContext context = event.getFacesContext();
User user = (User)
context.getExternalContext().getSessionMap().get(user);
// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on,
// as well as the restored state of the component tree for the page
that
// is submitting this request, as of the last time it was rendered
// If the user is not logged on, redirect to the logon page
if (user == null) {
// Create the view for the logon page and render it
context.getApplication().getViewHandle().createView
(context, /logon.jsp);
context.renderResponse();
return;
}
// Otherwise, do the standard processing for this request
; // No extra processing required
}
}
Both approaches are functionally equivalent, in that (when the user is not
logged on) they bypass the normal form submit processing and cause the logon
page to be rendered instead. If the user *is* already logged on, the
standard processing proceeds.
Craig
Re: Advice for Struts expert wanting to try Shale?
LOL I gave him the very same answer that you did, including the same citations. The difference is that I did not gloss over the confusion you have systematically engendered by not just owning up to the differences from day one. You don't have to love something to explain it. Otherwise, who would have known about the ugly duckling? On 1/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: If you are familiar with Core J2EE Patterns terminology, you'll find it easiest to understand JSF and Shale in terms of the View Helper[1] pattern, where the helper items are the JSF component tags and your backing beans, and the Dispatcher View[2] pattern, which combines the Front Controller[3] and View Helper[1] patterns together. In the Dispatcher View sequence diagram (Figure 7.25) the roles and responsibilities match up like this: Don't expect much help from someone who doesn't seem to care much for either JSF or Shale :-). Mark Craig [1] http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html [2] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html [3] http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html tags and it was complex to bind complex forms. In JSF, you can use EL value bindings or method bindings expressions. It is really great in my mind and very simple at the same time, thank to IoC and managed beans. - Finally, JSF has a component model and so reusing is very easy. The components hide most of the complexity to the developper (ugly javascript for exemple). Learning to developp components is what take time to learn, but you can get started quite fast if you just want to use it first. At least, there are a lot of exemples available. - One last thing, since the data and method bindings are specified in the jsp/html/whatever technologie you use for view page and the navigation is specified globally in the configuration file (not per action like in Struts), it is quite easy to follow the application flow. It was something that was annoying me sometimes with Struts, lot of places to look to find where the executed code is located. I hope it's help and since I am far from considering me a JSF expert, anyone can feel free to correct me. And please be tolerant about my english since I am not a native speaker and it's quite a long post :) On a side note for people having experience developping custom components, what annoys me so far in JSF is the model package, in fact the SelectItem class. There are no model objets for action components (like you need for a menu or navigation panel) and no universal components (UISelectItem and UISelectItems) for specifying the model. You need one for each component and it is quite a pain in the a.. to code those again and again. Anyway, it always possible to develop your own model hierarchy and use an adaptor to make SelectItem compatible with it. As anyone had the same problem so far? If it is the case, maybe a solution could be part of the future commons-jsf package that have been discussed in the past. I am working on something around this problem so I could probably submit it once I'm done. On 1/7/06, Dakota Jack [EMAIL PROTECTED] wrote: LOL I gave him the very same answer that you did, including the same citations. The difference is that I did not gloss over the confusion you have systematically engendered by not just owning up to the differences from day one. You don't have to love something to explain it. Otherwise, who would have known about the ugly duckling? On 1/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: If you are familiar with Core J2EE Patterns terminology, you'll find it easiest to understand JSF and Shale in terms of the View Helper[1] pattern, where the helper items are the JSF component tags and your backing beans, and the Dispatcher View[2] pattern, which combines the Front Controller[3] and View Helper[1] patterns together. In the Dispatcher View sequence diagram (Figure 7.25) the roles and responsibilities match up like this: Don't expect much help from someone who doesn't seem to care much for either JSF or Shale :-). Mark
Re: Advice for Struts expert wanting to try Shale?
Just a couple of comments intermixed below. On 1/7/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie Cleared FUD about JSF is a good introduction to. I think one of the previous poster posted the link. Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. While these are the only two events defined in the standard, it is perfectly feasible for JSF components to define their own events, and their own event handlers, using the same basic infrastructure. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. I actually wish there wasn't be so much difference here :-(. In the original vision of Struts, the idea of an ActionForward was very much to describe an *outcome* (this is what happened), not a *destination* (this is where to go next). Unfortunately, most Struts developers don't use forwards that way -- and you can make exactly the same mistake :-) when using logical outcomes in JSF. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html tags and it was complex to bind complex forms. In JSF, you can use EL value bindings or method bindings expressions. It is really great in my mind and very simple at the same time, thank to IoC and managed beans. The synergy of the managed beans facility is pretty nice ... especially when you realize you can use bindings on *any* property of *any* component, not just on the value property of an input component. - Finally, JSF has a component model and so reusing is very easy. The components hide most of the complexity to the developper (ugly javascript for exemple). Learning to developp components is what take time to learn, but you can get started quite fast if you just want to use it first. At least, there are a lot of exemples available. - One last thing, since the data and method bindings are specified in the jsp/html/whatever technologie you use for view page and the navigation is specified globally in the configuration file (not per action like in Struts), it is quite easy to follow the application flow. It was something that was annoying me sometimes with Struts, lot of places to look to find where the executed code is located. In both environments, the navigation rules are defined globally. The difference in granularity is how a navigation rule is selected: * In Struts, it's based solely on the outcome returned by a particular action (which can be defined either globally or locally). * In JSF, it's based (at least for the standard navigation handler; you can replace this if you want something different) on three criteria: - What page am I currently on? - Which action method was executed? - What logical outcome was returned by the executed method? In the JSF case, there are wildcarding capabilities for navigation that also let you be pretty concise in what you actually have to specify for common cases. I hope it's help and since I am far from considering me a JSF expert, anyone can feel free to correct me. And please be tolerant about my english since I am not a native speaker and it's quite a long post :) You're doing great ... once you get me past a restaurant menu, my grasp of French is *really* limited :-). On a side note for people having experience developping custom
Re: Advice for Struts expert wanting to try Shale?
On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Hi. I've done a couple of industrial-strength websites using Struts, Tiles JSTL. I decided to start on a little personal project, mostly as a way to get on board with some technologies, some of which I've used before (maven 1/2, torque), some which I want to learn (JSF, Shale). I looked around the Shale pages a bit last night, and found myself unable to grasp what it offered. I also looked at some of the JSF introductory articles, and was concerned that they referenced pre- release versions of JSF, and didn't reference Shale. I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). I'm happy to abandon Struts if it makes sense, and certainly I'd like to replace Struts components when functionality is provided by Shale/ JSF. Can someone point me to (or give me) an appropriate overview? Thank you very much! Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). -- Rick Craig [1] http://struts.apache.org/struts-shale/ [2] http://people.apache.org/~craigmcc/apachecon-2005-shale.pdf
Re: Advice for Struts expert wanting to try Shale?
Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
I should clarify: not all our Actions are just glue. They perform significant work when such work is constrained to the website needs (choosing what data to display). When it comes to purchases and registration, however, they are more like glue, even even more so when some functions are called by non-web-container code (for example, our automated subscription renewals). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
On 1/6/06, Rick Mann [EMAIL PROTECTED] wrote: Thanks for the response, Craig. It's nice to get an answer from THE authority :-). Questions below... On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: I'd definitely ignore anything about prereleases of JSF 1.0 ... that has been out for nearly two years now. A good starting place for general JSF knowledge and information is http://jsfcentral.com. Kito does a good job of staying on top of the most recent articles and items of interest. This, by the way, is *exactly* the place to start before looking much at Shale itself -- Shale *srongly* presumes that you are familiar with JSF, and what it brings to the table all by itself, because it focuses on adding value around the edges. Without understanding those edges a little, it's harder to appreciate the benefits :-). Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. Good. The JSF RI comes with several samples, as does MyFaces. A question comes up: what has happened to Tiles? Is it no longer a part of Struts? I'm still terribly unfamiliar with the new Struts website. Tiles itself is definitely still part of the Struts project. Two things are happening to it: * Organizationally, it becomes a subproject of Struts (just like Shale), so that it could be released independently of the rest of the core framework. * Technically, there is a sandbox version of Tiles that has its Struts-Action-Framework dependencies removed, so that it could be used with any MVC framework (and Shale is currently using a snapshot version of this code). Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or is there some other way to get site LF re-use? Tiles is still one option for this (indeed, besides the Shale integration, MyFaces's JSF implementation comes with their own integration of the original Struts tiles code.) Another approach is to look for component solutions that do layout management for you -- plus things like the Clay plugin to Shale, which lets you accomplish lots of the same sorts of reuse issues, but at a finer grained level than just a page or a tile. The Shale use cases example app has several ways in which Clay can be used like this. If that's not enough technologies to look at :-), there's another interesting approach to reusing layouts called Facelets[1]. Like Clay, Facelets leverages a JSF extensibility point called a ViewHandler that lets you be pretty innovative at substituting in alternatives to JSP as the mechanism for authoring the view pages of your application. Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One high level overview is the session I did at ApacheCon (reprised from one that David Geary and I did at JavaOne)[2] ... but the slides lose a little in the translation without the corresponding demo program, which is not in a shape that I'm quite ready to check in yet :-). Okay, I'll hold off worrying about Shale for now. Sounds like I can work it in easily enough when the time comes. We'l be here :-). Here's my big question: do I still think in terms of Struts Actions handling the business logic of my application (which they rarely do; they usually glue to the real biz code)? Or do I look to putting all that glue within JSF controllers? For someone familiar with Struts 1.x, I would draw the following analogies: * Where in Struts you have an Action and an ActionForm, with JSF you tend to combine them into a single request scope object. * Where an ActionForm tells you to use Strings for the properties, JSF components deal with conversion for you, so you can use native data types. * It's also possible to bind JSF components directly to POJO model objects if you want ... sorta like what WebWork does too. * Where Struts actions tend to have either a single execute() method for the entire page, or some sort of dispatch mechanism, you tend to bind each submit button in a JSF page to a separate action method in some backing bean (although you can share them if two different buttons should really do the same thing). * Just like an Action in Struts, the action method called by JSF should be considered an adapter to the real business logic (although, just like you can do with Struts, it's possible to embed business logic directly in the method :-). * Shale's ViewController adds the notion of application event calbacks to the strictly UI events that JSF supports. Of particular interest is the prerender() callback, which is invoked just before the next page actually renders ... the perfect place to do what you'd put in a setup action in a traditionally architected Struts application. As you become more familiar with JSF and Shale, you're likely to end up agreeing with my judgement on the best two features of the combination for an experienced Struts developer contemplating using JSF: * Managed
Re: Advice for Struts expert wanting to try Shale?
Craig, do you have this posted anywhere other than here on this list? This is a great summary that I've actually been looking for, so I'm glad I peeked into this thread. Thanks. You should add this to your blog somewhere or it should be on JSF Central. I'd like to bookmark it. Craig McClanahan wrote: For someone familiar with Struts 1.x, I would draw the following analogies: * Where in Struts you have an Action and an ActionForm, with JSF you tend to combine them into a single request scope object. * Where an ActionForm tells you to use Strings for the properties, JSF components deal with conversion for you, so you can use native data types. * It's also possible to bind JSF components directly to POJO model objects if you want ... sorta like what WebWork does too. * Where Struts actions tend to have either a single execute() method for the entire page, or some sort of dispatch mechanism, you tend to bind each submit button in a JSF page to a separate action method in some backing bean (although you can share them if two different buttons should really do the same thing). * Just like an Action in Struts, the action method called by JSF should be considered an adapter to the real business logic (although, just like you can do with Struts, it's possible to embed business logic directly in the method :-). * Shale's ViewController adds the notion of application event calbacks to the strictly UI events that JSF supports. Of particular interest is the prerender() callback, which is invoked just before the next page actually renders ... the perfect place to do what you'd put in a setup action in a traditionally architected Struts application. As you become more familiar with JSF and Shale, you're likely to end up agreeing with my judgement on the best two features of the combination for an experienced Struts developer contemplating using JSF: * Managed beans extend the Struts concept of magically instantiating ActionForm beans, and makes it general purpose -- they can be created indirectly by virtue of being bound to a component property, or you can evaluate expressions programmatically (with the possible side effects of creating new objects on the fly). Plus, you get basic dependency injection for free ... if your DI needs are relatively simple, you don't need something like Spring -- although you can certainly use that as well if you need it. * Shale dialogs address one of the tougher architectural areas in Struts 1.x ... how to deal with setup actions versus process actions, and how to organize everything. Dialogs lets you divide up your application into states (action state = method execution, view state = page rendering + the following form submit, subdialog state lets you treat dialogs as black box subroutines). Every state returns a logical outcome string, which can be used to drive transitions to other states. And, you can have as many action states as you like between view states. It's pretty easy to architect the overall organization of the application in these terms, and to divide things up into logically separate units of work. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Rick Mann wrote: Okay, I'll try to find a hello world JSF example. That might be enough for me to build on. One series of articles from IBM that I found very helpful when I first started looking at JSF (thanks Wendy for linking them!) can be found here, if you're still looking for a good intro: http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=nonbelievers: L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
On 1/6/06, Rick R [EMAIL PROTECTED] wrote: Craig, do you have this posted anywhere other than here on this list? This is a great summary that I've actually been looking for, so I'm glad I peeked into this thread. Thanks. You should add this to your blog somewhere or it should be on JSF Central. I'd like to bookmark it. Or, someone could give Craig a hand and start adding posts like this to the wiki. :) * http://wiki.apache.org/struts/StrutsShale No reason to let Craig have all the fun. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
