Re: The framework I think I want...
Again, it was not a challenge. Thanks for explaining. On 1/6/06, Niall Pemberton [EMAIL PROTECTED] wrote: Its a valid point - I did vote for WebWork without much knowledge and anyone crticising my decision to do that probably has good grounds to do so. For the record the following was my response on the PMC list to the proposal to merge with WebWork. quote I like this idea and prefer it to Clarity. IMO a true merger of projects is the only way we might successfully pool resources and stop competing. Clarity is a good concept, but I don't believe it would be possible to keep everyone on board and prevent communities splitting. I have no real knowledge of WebWork, but it has a good reputation and I dabbled around in the source code a week or so ago and liked what I saw. I also think if Spring are involved then things are going to go badly - that may be an unfair criticism, but its my gut feeling. I don't have the time or ability to be driving Struts forward with major contributions or re-writes of the existing framework, but I am happy carrying on with smaller contributions and support -so pooling resources this way is IMO a good thing. It would be good to get to know the people from these other projects a bit better - I went to Eddie O'Neil's presentation at BeaWorld recently, but the others I know nothing about. Are any of them going to ApacheCon? end quote Niall - Original Message - From: Dakota Jack [EMAIL PROTECTED] Sent: Friday, January 06, 2006 11:59 PM I am confused (there's an opening for those that like them): did you not vote for WebWorks, Niall? If so, how could it be that this education is happening now? That's not a challenge so please don't take it as one, but a curious question as to what is going on. - 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?
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]
How to forward from one action to another, with modified parameters?
If a request for /retrieve.do?id=42 fails (e.g. couldn't find item in database), I'd like to say request.setStatus(HttpServletResponse.SC_NOT_FOUND); request.setAttribute(warning, Not your lucky day.); and forward (not redirect) the request to /search.do?query=42 Can this behavior be accomplishing with Struts? Currently I'm using request.getRequestDispatcher(...).forward(...) with a modified HttpServletRequest, but there must be a better way (TM)... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirection
Is there any way I could get an ActionForward to do permanent (301) rather than temporary (302) redirects? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirection
Not sure if i've understood what you're after, but you can just write to the reponse (as you would in a normal servlet) and return null for you action forward. Your webapp configuration will do the rest from there like with any webapp. On 1/7/06, Eric Jain [EMAIL PROTECTED] wrote: Is there any way I could get an ActionForward to do permanent (301) rather than temporary (302) redirects? - 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: Redirection
Mark Lowe wrote: Not sure if i've understood what you're after, but you can just write to the reponse (as you would in a normal servlet) and return null for you action forward. Your webapp configuration will do the rest from there like with any webapp. Yes, that's a solution. On the other hand ActionForwards are convenient to use (no need to worry about paths etc.), so I was wondering if you could do something like: forward.setRedirect(true); // existing method forward.setPermanent(true); // possible extension? I know it is possible to implement your own ActionForward classes, but I'm not sure that would help here. Ideally the RequestProcessor would ask the ActionForward for a status code at one point... - 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: Redirection
Hi, Eric, I think you have to go back through the code and find out where the status codes are handled. I have to admit that I don't know. If someone else does, this would be great information to have. This is an interesting problem and one that I always put on the back burner. Maybe now is the time to make some decisions about what to do. On 1/7/06, Eric Jain [EMAIL PROTECTED] wrote: Mark Lowe wrote: Not sure if i've understood what you're after, but you can just write to the reponse (as you would in a normal servlet) and return null for you action forward. Your webapp configuration will do the rest from there like with any webapp. Yes, that's a solution. On the other hand ActionForwards are convenient to use (no need to worry about paths etc.), so I was wondering if you could do something like: forward.setRedirect(true); // existing method forward.setPermanent(true); // possible extension? I know it is possible to implement your own ActionForward classes, but I'm not sure that would help here. Ideally the RequestProcessor would ask the ActionForward for a status code at one point... - 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: How to forward from one action to another, with modified parameters?
In my opinion, Eric, this is a bad solution. There are lots of reasons this is bad. Rather than go through them, I would suggest you just add the logic in /search.do?query=42 at the point you get the failure form /retrieve.do?id=42. On 1/7/06, Eric Jain [EMAIL PROTECTED] wrote: If a request for /retrieve.do?id=42 fails (e.g. couldn't find item in database), I'd like to say request.setStatus(HttpServletResponse.SC_NOT_FOUND); request.setAttribute(warning, Not your lucky day.); and forward (not redirect) the request to /search.do?query=42 Can this behavior be accomplishing with Struts? Currently I'm using request.getRequestDispatcher(...).forward(...) with a modified HttpServletRequest, but there must be a better way (TM)... - 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: Redirection
Currently (i.e. Struts 1.2.x) this is done in the processForwardConfig() method of the RequestProcessor - if the ActionMapping has redirect set to true it calls the sendRedirect(url) method - which as I understand it is a convenience method for setting a 302 status and location header. Currently you would have to create your own custom RequestProcessor to achieve this and override the processForwardConfig() method to do this. Not sure about isPermanent - looks like there are a number of redirection status codes according to the spec - 301/302/303/307 ftp://ftp.isi.edu/in-notes/rfc2616.txt Niall - Original Message - From: Dakota Jack [EMAIL PROTECTED] Sent: Saturday, January 07, 2006 3:06 PM Hi, Eric, I think you have to go back through the code and find out where the status codes are handled. I have to admit that I don't know. If someone else does, this would be great information to have. This is an interesting problem and one that I always put on the back burner. Maybe now is the time to make some decisions about what to do. On 1/7/06, Eric Jain [EMAIL PROTECTED] wrote: Mark Lowe wrote: Not sure if i've understood what you're after, but you can just write to the reponse (as you would in a normal servlet) and return null for you action forward. Your webapp configuration will do the rest from there like with any webapp. Yes, that's a solution. On the other hand ActionForwards are convenient to use (no need to worry about paths etc.), so I was wondering if you could do something like: forward.setRedirect(true); // existing method forward.setPermanent(true); // possible extension? I know it is possible to implement your own ActionForward classes, but I'm not sure that would help here. Ideally the RequestProcessor would ask the ActionForward for a status code at one point... - 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]
[JSF/Shale] bean:message with parameter
I want to do something like this in JSF:
bean:message key=affirmation.link1 arg0=%=szFormType%/
Which I think translates to
h:outputText value=#{bundle.affirmation.link1
f:param value=#{szFormType}/
/h:outputText
Is this correct?
Shawn
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Calendar Project
I couldn't find one, but this PHP based one will integrate with STRUTS, http://www.k5n.us/webcalendar.php You can use this PHP - JAVA bridge http://php-java-bridge.sourceforge.net/ (of course you have to have PHP installed first) Jim From: Rafael Taboada [EMAIL PROTECTED] Reply-To: Struts Users Mailing List user@struts.apache.org To: Struts List user@struts.apache.org Subject: Calendar Project Date: Fri, 6 Jan 2006 22:40:32 -0500 Please. Do u know a calendar project made in struts??? I mean, when u make an appointemnt, an event thanks -- Rafael Taboada Software Engineer Cell : +511-97753290 No creo en el destino pues no me gusta tener la idea de controlar mi vida - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Rahul Akolkar [EMAIL PROTECTED] wrote on 01/06/2006 05:07:21 PM: On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip/ Actually I found that dialog-config.xml had an xml error so I guess it was silently not loaded. So I fixed it and now the Cancel works (yeahh!!) so I think at least I have gotten into the dialog..:) My Search still throws a nasty error, but I guess I shall struggle with that awhile before I give up and ask you again..(:( snap/ Possibly rethink the corresponding outbound transition from the SearchHome view state (separate the search and results views). Thank you Rahul. Actually the specs are that my results appear just below my search form and I had already coded things so everything was in /search.jsp (I used rendered attributes to render results if present). However I guess what Shale requires is for the ids (names) to be different (and never mind what those names map to). So that's what i did: dialog name=Search Contacts start=Search Home view name=Search Home viewId=/search.jsp transition outcome=ContactListSuccess target=Contact List/ /view view name=Contact List viewId=/search.jsp /view end name=Home viewId=/worklist.jsp /end /dialog This worked for my *first* search: my searchBean.find() returns ContactListSuccess and everything is hunky dory. Sweet. *However*, since my search form is visble above my results, I got a Faces error when I searched again! And the error made sense too (;) since I was in the ContactListSuccess state (after the first successful search) and I was now transitioning to ContactSearchSuccess again due to the second search, which is not a legal outcome according to the dialog. So I moved the transition outcome=ContactListSuccess target=Contact List/ up so it was a common transition (instead of adding it twice) and then I no longer got the error. Furthermore, my menu bar, which is always visible and which has a link to dialog:Search Contacts also is always clickable. Thus I also need a common transition for outcome Search Contacts. So my dialog now looks like this: dialog name=Search Contacts start=Search Home transition outcome=cancel target=Home/ transition outcome=ContactListSuccess target=Contact List/ transition outcome=Search Contacts target=Home/ view name=Search Home viewId=/search.jsp /view view name=Contact List viewId=/search.jsp /view end name=Home viewId=/worklist.jsp /end /dialog I do have a few more transitions which I have omitted (which are not common), but it really seems to me that by making so many of the transitions common, I am not utilizing what Shale can give me via dialogs. Is this correct? Or is this what i have to live with since my specs dictate I show the search form above my results and I always have the menu bar visible? I get the feeling I may be missing something important.. -Rahul Once again thank you for your time and patience! Geeta
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: The framework I think I want...
I just wanted to say, this has been a great thread, and given me a lot of food for thought. As I mentioned previously, I've spent a lot of time with my head down developing in Struts 1.1, and now that I'm refactoring my site, it's good to hear people batting around different ideas about the different weaknesses/strengths of the various frameworks. I hadn't really thought about it, but looking at the code which has already been written for version 2 of my site, I noticed that I haven't used any ActionForms (yet). Everything is being communicated via AJAX, and I just haven't needed any. So it's interesting to hear that other people are moving away from them (even if for entirely different reasons). Any thoughts on JSTL? Must have? Nice but not necessary? Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: The framework I think I want...
Frank, Interesting... there is of course no reason you can't use ActionForms with AJAX, was it a conscious decision that you didn't need them? How are you getting around not using them? Your Actions pull parameters directly from request I assume? Right. My struts-config.xml file is basically divided into three sections, as follows. Setup actions: action path=/Home type=app.HomeSetupAction forward name=success path=/HomeView.do/ /action File mappings: action path=/HomeView forward=/pages/Home.jsp/action AJAX actions (all handled by one Action): action path=/GetWordInfo type=app.CommandAction/ action path=/Login type=app.CommandAction/ action path=/Logout type=app.CommandAction/ To send AJAX commands, I use JavaScript to construct an appropriate URL/query string, then send using the standard XMLHttpRequest code. Inside the CommandAction class, I figure out which command was called (request.getServletPath()), call the matching function, and use request.getParameter() to get the parameters specific to the command. Any thoughts on JSTL? Must have? Nice but not necessary? I just started using JSTL fairly recently, but I would highly recommend doing so. I guess I'd say VERY nice, but not necessary. However, I will say this... if you are thinking of using the Struts taglibs, aside from HTML, I think the better option by far is using JSTL. The HTML taglib still has a place, but the others I consider deprecated in favor of JSTL. Then again, if your building RIAs with Struts, my opinion is that the HTML taglib will get in your way far more than it will help anyway... That's another thread though :) Very interesting - now that I'm not using ActionForms (to repeat - not a conscious decision, but the way things seem to be turning out), I find myself only using tiles, logic, and bean tags. So, everything *but* html. I'll definitely give JSTL a hard look. Oh, and I use sslext. Is this still necessary in 1.2.8? In 1.3? Daniel - 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: [JSF/Shale] bean:message with parameter
On 1/7/06, Garner, Shawn [EMAIL PROTECTED] wrote:
I want to do something like this in JSF:
bean:message key=affirmation.link1 arg0=%=szFormType%/
Which I think translates to
h:outputText value=#{bundle.affirmation.link1
f:param value=#{szFormType}/
/h:outputText
Is this correct?
Almost ... first, try it with h:outputFormat instead of h:outputText.
And, if you've loaded message bundles that have keys with periods in them,
here's a trick that will simplify your life:
h:outputText value=#{bundle['affirmation.link1']}
f:param value=#{szFormType}/
/h:outputText
Shawn
Craig
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~
How to merely retrieve data? - Newbie looking for best practices
Greetings!
First, I'm new to Struts, and pretty green in my Java skills, but I'm
excited about learning both!
My goal is to retrieve data, which a jsp will spill out. I'm trying to
do it by writing a simple Action subclass to get the data and send it
along. The way I'm doing it isn't working.
My action mapping looks like this:
action
path=/records
type=app.actions.RecordsAction
forward=/pages/records.jsp /
My app.actions.RecordsAction looks approximately like this:
public class RecordsAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)throws IOException,
ServletException{
RecordList rl = new RecordList(); //Object used to get
records
List l = rl.getRecords();
request.setAttribute(records,l);
return mapping.findForward(could-be-anything);
}
}
The result is that I get forwarded to /pages/records.jsp without the
execute method ever being called in RecordsAction, and as such, I
get a null pointer when I try to do anything with the
request.getAttribute(records) in the jsp. However, this seems to
make perfect sense because I specified this to merely forward. So, how
do I get the data?
If I want to simply return dynamically generated content, without an
ActionForm, what's the best practice for retrieving it?
1.What should the Action subclass look like?
2. What would the action-mapping in struts-config.xml look like?
3. Is it common to use request.setAttribute(value) to send data to
the View? and if not, what's the correct way to send data to the View
layer? (I think this is the pivotal question)
I've been going through Struts in Action, which I find good as a
technical reference, but not so good when it comes to figuring out how
to achieve a simple goal, like this. In my quick research in the book
and online, everything I've found seems to be tied to ActionForms. But
I don't have an ActionForm. Alas!
I realize that I am probably missing something fundamentally basic and
that y'all might tell me to go RTFM. And that's cool, just point me to
it. Most of the stuff I've seen is very focussed on dealing with data
AND forms, but not data by itself. I'd be happy to find some
recommended documentation.
Thanks for your collective help in getting me on track!
Eric Rank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to merely retrieve data? - Newbie looking for best practices
On 1/7/06, Eric Rank [EMAIL PROTECTED] wrote: My goal is to retrieve data, which a jsp will spill out. I'm trying to do it by writing a simple Action subclass to get the data and send it along. The way I'm doing it isn't working. My action mapping looks like this: action path=/records type=app.actions.RecordsAction forward=/pages/records.jsp / Welcome! There's quite a bit of information in the DTD itself: http://struts.apache.org/dtds/struts-config/1_2/ Click on 'action' and then scroll up a bit to read the comments. For forward, it says: Exactly one of forward, include, or type must be specified. Instead of the forward attribute, try using a nested (or global) forward name=could-be-anything path=/pages/records.jsp / element. And yes, setting attributes in the request or session and retrieving them in the JSP is a reasonable thing to do. Take a look at JSTL if you aren't already using it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to merely retrieve data? - Newbie looking for best practices
Ahhh yes. Actually, I did check out the DTD a couple of days ago. I remember it saying how you can only put in one forward include or type. I just didn't connect how I would set a type and then specify a forward as the child node. Now it works just fine. I knew it was probably something simple. I appreciate your help! Thanks, Eric On 1/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/7/06, Eric Rank [EMAIL PROTECTED] wrote: My goal is to retrieve data, which a jsp will spill out. I'm trying to do it by writing a simple Action subclass to get the data and send it along. The way I'm doing it isn't working. My action mapping looks like this: action path=/records type=app.actions.RecordsAction forward=/pages/records.jsp / Welcome! There's quite a bit of information in the DTD itself: http://struts.apache.org/dtds/struts-config/1_2/ Click on 'action' and then scroll up a bit to read the comments. For forward, it says: Exactly one of forward, include, or type must be specified. Instead of the forward attribute, try using a nested (or global) forward name=could-be-anything path=/pages/records.jsp / element. And yes, setting attributes in the request or session and retrieving them in the JSP is a reasonable thing to do. Take a look at JSTL if you aren't already using it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] getting my first dialog to work with Shale/MyFaces
On 1/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Rahul Akolkar [EMAIL PROTECTED] wrote on 01/06/2006 05:07:21 PM: On 1/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip/ My Search still throws a nasty error, but I guess I shall struggle with that awhile before I give up and ask you again..(:( snap/ Possibly rethink the corresponding outbound transition from the SearchHome view state (separate the search and results views). Thank you Rahul. Actually the specs are that my results appear just below my search form and I had already coded things so everything was in /search.jsp (I used rendered attributes to render results if present). However I guess what Shale requires is for the ids (names) to be different (and never mind what those names map to). snip/ Not really. I understand your specs now, whats the nasty error you refer to, does that hold any clues? So that's what i did: dialog name=Search Contacts start=Search Home view name=Search Home viewId=/search.jsp transition outcome=ContactListSuccess target=Contact List/ /view view name=Contact List viewId=/search.jsp /view end name=Home viewId=/worklist.jsp /end /dialog This worked for my *first* search: my searchBean.find() returns ContactListSuccess and everything is hunky dory. Sweet. *However*, since my search form is visble above my results, I got a Faces error when I searched again! And the error made sense too (;) since I was in the ContactListSuccess state (after the first successful search) and I was now transitioning to ContactSearchSuccess again due to the second search, which is not a legal outcome according to the dialog. So I moved the transition outcome=ContactListSuccess target=Contact List/ up so it was a common transition (instead of adding it twice) and then I no longer got the error. snip/ A couple of things that I think are relevant here: * A self transition for a view state should be possible (its definitely legit in state chart theory, Shale dialogs being state charts for a specific purpose). * I tend to use action states since I can visualize the processing bits as states in the dialog config (and searching definitely qualifies), and the corresponding multiple logical outcomes (error, no results, few results, many results) appear as transitions in the action state. But, I understand this is subjective. Furthermore, my menu bar, which is always visible and which has a link to dialog:Search Contacts also is always clickable. Thus I also need a common transition for outcome Search Contacts. So my dialog now looks like this: dialog name=Search Contacts start=Search Home transition outcome=cancel target=Home/ transition outcome=ContactListSuccess target=Contact List/ transition outcome=Search Contacts target=Home/ view name=Search Home viewId=/search.jsp /view view name=Contact List viewId=/search.jsp /view end name=Home viewId=/worklist.jsp /end /dialog I do have a few more transitions which I have omitted (which are not common), but it really seems to me that by making so many of the transitions common, I am not utilizing what Shale can give me via dialogs. Is this correct? Or is this what i have to live with since my specs dictate I show the search form above my results and I always have the menu bar visible? I get the feeling I may be missing something important.. snip/ There is nothing wrong with common transitions -- Shale calls these global transitions -- pending they're truly common. Looking at what you have listed: * Transitions such as the first one (cancel) are useful when specified as global transitions, especially in wizard style dialogs, otherwise you'd be authoring them redundantly. * The second one is a candidate for localizing (will be a side-effect of having one view state). * The third one I believe is refering to the always clickable menu bar link to initiate the search dialog, and that is going to be suspect since Shale dialogs, as of today, work best when you run a dialog to completion before beginning another (where completion is defined as reaching an end state, that says nothing about any *task* being completed). Ofcourse, if you're using dialogs, it'd be good be aware of the known issues 35066 [1], 37120 [2] and 37571 [3], if you're not already. And finally, use the latest nightlies if you can, just saw r366984 [4] whiz by, that added better error messages for dialogs. -Rahul [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=35066 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120 [3] http://issues.apache.org/bugzilla/show_bug.cgi?id=37571 [4] http://svn.apache.org/viewcvs?rev=366984view=rev -Rahul Once again thank you for your time and patience! Geeta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [Shale] getting my first dialog to work with Shale/MyFaces
On 1/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: [snip] * A self transition for a view state should be possible (its definitely legit in state chart theory, Shale dialogs being state charts for a specific purpose). Self-transitions for a view state are definitely legal, but there's an interesting semantic twist here. Since we are in a view state, the transition is based on the logical outcome returned by the action method that is invoked for the submit button that actually submits the form (phew, say that sentence three times real fast :-). If the action method returns an outcome that happens to map to the same view identifier, a *new* component tree is still created, so you lose any state information you've stored in the current component tree. If the action method returns null, on the other hand, there is a short circuit to the normal transition mechanism that causes the current view to be redisplayed, *without* being recreated. This was done deliberately, so that action methods within a dialog work exactly the way they do outside a dialog. From a state chart perspective, you can assume there is an additional unspecified transition that says if the logical outcome is null, redisplay the current component tree without recreating it. This can be an important consideration when you are designing the UI of your application ... even if the *user* doesn't know or care whether a new view was created or not in this scenario, it can dramatically simplify your dialog configuration, and your application logic, to know that this is a scenario you can rely on. Craig
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: [Shale] getting my first dialog to work with Shale/MyFaces
On 1/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: [snip] * A self transition for a view state should be possible (its definitely legit in state chart theory, Shale dialogs being state charts for a specific purpose). Self-transitions for a view state are definitely legal, but there's an interesting semantic twist here. Since we are in a view state, the transition is based on the logical outcome returned by the action method that is invoked for the submit button that actually submits the form (phew, say that sentence three times real fast :-). If the action method returns an outcome that happens to map to the same view identifier, a *new* component tree is still created, so you lose any state information you've stored in the current component tree. If the action method returns null, on the other hand, there is a short circuit to the normal transition mechanism that causes the current view to be redisplayed, *without* being recreated. This was done deliberately, so that action methods within a dialog work exactly the way they do outside a dialog. From a state chart perspective, you can assume there is an additional unspecified transition that says if the logical outcome is null, redisplay the current component tree without recreating it. This can be an important consideration when you are designing the UI of your application ... even if the *user* doesn't know or care whether a new view was created or not in this scenario, it can dramatically simplify your dialog configuration, and your application logic, to know that this is a scenario you can rely on. snip/ That makes sense. A stay (null) transition should retain state, a self transition (amounts to calling onexit and onentry -- which gets us in initial -- for that state) should not. Now in terms of DialogNavigationHandler#transition(...) a null outcome and a stay transition seems to produce the identical State as a return value and hence identical results from a dialog progression perspective. A quick test by making the next transition on page 2 of the edit profile dialog (from the shale usecases war) point to the same state seemed to retain the values in the h:inputTexts. Is my quick test missing something? -Rahul Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
