I'm pleased to announce a couple of new postings at JSFCentral: an interview with Stan Silvert about JSFUnit from last year's JSFOne conference, and part 2 of Steven Murray's series on designing JSF applications.
Here's an excerpt from Stan Silvert on Testing JSF Applications with JSFUnit: Kito: So let’s say I am writing my JSF application and I decide I want to get JSFUnit and I download it. What do I have to do? Let’s say I want to test…like a login page and I have written my backing bean and have some components on the page and I want to test that it works OK. Stan: What you do is get the JSFUnit JAR, of course with several supporting JARs. There is a “getting started” page -- if you go to jsfunit.org you can see all this step by step. You get the JARs, you do make some modifications to your web XML to set up a couple of filters and a couple of extra filters that are used by Cactus, which is what we use to do the in-container magic for JUnit. Then you write your test, which is usually very few lines of code. You have a JSF client session and a JSF server session so you use the JSF client session to click things on the page and you input things on the form and such as that. Then every time there is an HTTP request you can go to this JSF server session object and look at all the things on the server, like the value of your managed beans. Did the value really make it into the managed bean like you expected? Did the component tree turn out the way you expected? It is a very powerful way to do assertions instead of having to do assertions on the HTML – which is something we still allow you to do – but really a better way is to assert that the JSF component tree turned out right. Because that is what your logic actually took care of. Like I say, it’s not many lines of code to write tests to test things. Read more or download the MP3 here: http://www.jsfcentral.com/articles/silvert-08-09.html Here's an excerpt from Designing JSF Applications: a Storyboard Approach, Part 2: The Presentation Model is based on the MVC pattern called Separated Presentation. The premise of the pattern is quite simple: you place the presentation and domain code into separate layers that have strict visibility rules, which allow the presentation to call the domain but the domain remains completely unaware of the presentation. There are two basic ways that you can implement a controller using this pattern. The first is called Supervising Controller. In this technique you are permitted to use data binding to communicate directly between the view and the domain model; this is the common pattern you see promoted in JSF examples. The problem with the Supervising Controller is that often the view logic can be complex and difficult to manage. The preferred pattern for a storyboard design is to use a Presentation Model, which is illustrated in figure 1. A presentation model pulls the state and behavior of the view out into a model class that encapsulates access to the domain model and provides a public interface that is consumed by the view. The key features of the presentation model are:. * The presentation state is in the model * The presentation logic is in the model * The view observes the model and updates accordingly * The model does not know about the view The motivation is to create controllers that manage their own state and interact with each other when necessary. Read more here: http://www.jsfcentral.com/articles/storyboard_2.html --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3
