On 8/30/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Why, out of curiousity, do you insist on getting your hands dirty with low > level HTTP protocol details like dynamically constructing URL patterns? > Why, out of curiousity, do you insist on using GET queries (and thereby > throw away nearly the entire JSF lifecycle)?
For the record it was Mirek who was proposing that, I'm too new to claim that is what needs to be done. I only concern myself with it because I haven't received a reply on how to deal with this question that I asked a couple of times: >>>>> I'm still a bit confused on how you deal with links that go to backing bean methods for standard links/buttons. As an example, imagine the header on a page... John Doe [edit user] [logs for user] [user summary] [look up company] 1455 some address [edit address] Somewhere, state, 12456 The example above is a bit exaggerated, but the point is the links(or even buttons) would have to access methods in all different kinds of backing beans. <<<<<<<<<< I'm curious how to handle the above with JSF? I'm not trying to be difficult and I'm working dilligently at trying to grasp the concepts, but most of the examples do not address these common issues. You see links on 99.999% of the sites out there - from products you click on, to going to other sections of web sites. I don't think I'm that off base to expect the issue to be addressed a bit - maybe the wiki addresses it, and I missed it? I'm sure I'm missing a simple basic JSF concepts, but I know I'm not the only one that is confused on the issue. It's not that "I" or probably the others "want" to use get parameters - we are probably just too ignorant to know of the correct JSF way to do it. I think all we are doing is asking for how to best handle the situation with JSF, not that we truly want to force a square peg into a round hole. > Let the application deal with application level things like components > (hidden or not as need be), not implementation details. Like any other > technology, JSF will be intuitive if you use it the way it's intended -- and > it won't be if you don't. <snip> > Isn't "more intuitive" semantically meaningless, if we all can't even agree > on what "intuitive" means? :-) Fair enough. I should have qualified. One of the problems I'm realizing quite quickly with JSF is that it really tries to remove the user from having to deal with the whole servlet model and I understand how that could be a great thing. By intuitive I should have clarified that I meant in regard to the frame-of-reference coming from standard servlet/JSFprogramming. With Struts, once you realize that an Action class is really just a Servlet, you are back in the realm of dealing with Request/Session etc. With Struts you also seem to be able to ease into the process more gradually. Other than using the struts html:form tag, you can skip using most tags if you wanted. You could just standard html input tags. As you get more comfortable with the framework you can add more and more features. With Struts, viewing the html source generated also is pretty easy to see if things 'look as you'd expect.' With JSF, looking at the generated source code doesn't seem to help me very much. I'm all for learning JSF though. I'm by no means saying that Struts is better, or JSF is better, or .NET is better. I'm going to plug away to learn this technology. -- Rick
