On 3/20/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > If you go directly from view to controller to view, this is called a "page > controller". It is what it is. It is in my opinion a design mess that is > adapted by tool based applications like JSF, .NET and Visual Basic. If you > think that is good stuff, be my guest. It is not the C in MVC, not matter > how you slice your bread
Once again you confuse the FrontController (input controller according to Fowler) and the Application Controller. Application Controller = mediator between the user interface and domain logic, totally MVC agnostic. Front Controller or input controller = A single point of dispatch for incoming http requests (basically even handlers). And by the way, try JSF and you'll see that what you said isn't true. Controller to view to controller to view, what are you talking about? You click a button, a request is submitted to the Front Controller, wich handles the event correctly and dispatch to the appropriate unit of treatment. In struts the Action, in JSF every registered event handler. The events dispatchers (not as with Swing) and handler are independant of the components. So the difference is basically there, Struts handle page events while JSF handle component events. The flow is the same. "Page controller is distinguished from a Front Controller in that the page controller operates on only a single logical page, where a Front Controller performs this functions for a set of logical pages." Even if isn't always the case (as with Action Struts) some of my events handler are generic and SHARED between different pages. Anyway just take a look at a JSF PhaseListener and please explain me how it is a Page Controller. JSF just offers the advantages of a page controller while sticking with a front controller. >. The third disagrees with you and agrees with me: > > "JSF uses the Page Controller Pattern. Although there is a single servlet > every faces request goes through, the job of the servlet is to receive a > faces page with components. It will then fire off events for each component > and render the components using a render toolkit. The components can also be > bound to data from the model. The faces life-cycle is illustrated in Figure > 2." > You know I have thrown this one in just to see how honest you were, I wanted to see if you were going to take the only part that you like and you did. I don't agree with the guy and I could be wrong but most sources I have red agree with the facts that JSF is front controller oriented. Unless someone give me strong evidences, I will continue to clear the FUD about it. > The fourth thinks that MVC is a pattern and is not credible. Ok, fallacies again. Because he doesn't have the same ideas as you, he is not credible. I am taking notes... There has been so many debate about how to designate MVC, architectural pattern, mini design pattern, design pattern, you name them. Sorry but once again you are just taking the part you want. > > On 3/20/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > I don't agree with you FacesServlet is a pure front controller, Faces > > lacks an application controller on purpose but not a front controller. > > It fits to the description in the blue prints and in Martin Fowler > > book, the best reference on Enterprise applications patterns I know > > of. Just tell me why you think it isn't? I will agree that JSf doesn't > > have an application controller (this what Shale offer after all) but > > it is totally front-controller oriented according to the definition. I > > think you are confusing application controller and front controller > > patterns, But since I disagree with you I don't get MVC and you are > > not interested. Fallacies again Dakota... > > > > First, here's some reference about JSF being front controller oriented > > (not by Craig since you always claim he has an hidden agenda, > > something I found totally ridiculous): > > > > > > http://www.codeguru.com/csharp/.net/net_general/toolsand3rdparty/article.php/c11139/ > > > > http://www.oracle.com/technology/tech/java/newsletter/articles/introjsf/index.html > > http://websphere.sys-con.com/read/46516.htm > > http://www-128.ibm.com/developerworks/java/library/wa-dsgnpatjsf.html > > http://java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/ > > > > > > Oh yeah right those articles are from big corporations who just want > > to make profit on poor developers.... But do some searches yourself, > > you'll find tons of reference on the subject. > > > > Here's what I get of MVC in JSF : > > > > Controler = FrontController + event dispatchers > > Model = backing beans (data model) + UI components (ui model) > > View = renderers + the view handler > > > > So where am I wrong? Please give me some technical details for once > > instead of saying I don't get it. > > > > By the way, I develop JSF applications using Vanilla Eclipse and my > > coworkers do to. Tools support is not why we have chosen JSF. > > > > > > On 3/20/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > This (below) has nothing to do with smarts. It has to do with the > > purpose > > > of JSF. The same was true of Visual Basic. A genius might use it or > > build > > > it or whatever. Indeed, I have friends smarter than me for sure who > > worked > > > for years with Visual Basic. But, it was made for the technically > > > challenged and is a tool, nonetheless. JSF, I must assume, was built > > the > > > way it was as an answer to the .NET challenge. Myself, I think that is > > a > > > mistake, but I understand the reasoning. I am not against JSF, never > > have > > > been. > > > > > > <snip> > > > On 3/20/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > > > > > On 3/20/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > JSF is built for those who are > > > > > technically challenged and for tools. > > > > > > > > Ok, once again people who use JSF aren't smart, huh wait "technically > > > > challenged". If it isn't a fallacy I wonder what it is... > > > > > > </snip> > > > > > > This (below) notion that JSF has a front controller is plain bogus. I > > > recommend you follow up on this, check definitions, etc. (aside from > > those > > > marketing definitions Craig has offered) and think it through. Try the > > > following sort of basic introduction to the front controller pattern: > > > > > > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html > > > > > > Mostly, I think, you need to take a look at how the model / view / > > > controller are connected in your web architecture, with a clear > > > understanding, as Ted has pointed out, that the web MVC decoupling is: > > > > > > controller --> model --> view > > > > > > If you chose to couple everything, then I am not interested in your > > ideas. > > > Someone else might be, but I am not. > > > > > > <snip> > > > > > > > If you had taken a serious look at JSF you will see it isn't page > > > > controller based but front controller based. FacesServlet is > > > > equivalent to the Struts ActionServlet, the big difference is that JSF > > > > doesn't include straight out of the book an Application Controller. It > > > > focuses on the MVC patterns in which by the way "C" stand for input > > > > controller and not application controller, something a lot of people > > > > don't get (quite well explained in Fowler book, a worth reading). > > > > > > > > > </snip> > > > > > > > > > -- > > > "You can lead a horse to water but you cannot make it float on its > > back." > > > ~Dakota Jack~ > > > > > > > > > > > > -- > > Alexandre Poitras > > Québec, Canada > > > > --------------------------------------------------------------------- > > 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~ > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]