JSF code snippet: Page scope with Tomahawk save state component

JSF code snippet: Page scope with Tomahawk save state component
By default, JSF backing beans can be only in session or request scope. Having a "page" scope is very useful, so the state is maintained between requests, but is discared when you abandon the page (and not kept in the session). You can easily achieve this by using the UI save state component from MyFaces Tomahawk project.
The bean saved by saveState must be serializable (if you have a dataModel don't forget to declare it transient) and declared of request scope in faces-config.xml

In the jsp
< t:saveState id="saveState" value="#{BackingBean}" />

In web.xml
< context-param>
< param-name> javax.faces.STATE_SAVING_METHOD < /param-name>
< param-value>client < /param-value>
< /context-param>

< filter>
< filter-name>extensionsFilter < /filter-name>
< filter-class> org.apache.myfaces.component.html.util.ExtensionsFilter < /filter-class>
< /filter>


In faces-config.xml
< navigation-rule>
< from-view-id>/myScreen.jsp < /from-view-id>
< navigation-case>
< from-outcome>cancel < /from-outcome>
< to-view-id>/myScreen.jsp < /to-view-id>
< /navigation-case>
< /navigation-rule>
< managed-bean>
< managed-bean-name>BackingBean < /managed-bean-name>
< managed-bean-class>myPackage.BackingBean < /managed-bean-class>
< managed-bean-scope>request < /managed-bean-scope>
< /managed-bean>

The navigation rule to the same screen on cancel has the nice effect of clearing the saved values. That makes implementing a "Clear" button just that easy.

JSF code snippet: No data found message for a table

A short one: display a message when there's no results to display in the dataTable

< h:dataTable value="#{BackingBean.tableModel}"
... rest of the dataTable configuration
>
..... dataTable columns ...
< /h:dataTable>
< h:panelGrid width="100%" rendered="#{BackingBean.tableModel.rowCount == 0}">
< value="#{msgs.noResults}">
< /h:panelGrid>



The datatable will render only the column titles, and then the panel grid with the message will be rendered

UPDATE: I just noticed that while posting, the JSF tags got completely messed up, should be fixed now

JSF code snippet: parent-child lists

(I'm extracting a collection of JSF code snippets from my projects to keep them in a easily accessible place)
Here is an example of parent-child drop downs with multiple child selection, and the list of childs is not rendered until a parent is selected...

In the JSF page:

code:

...
< h:selectOneMenu id="parent" immediate="true"
value="#{BackingBean.selectedParent}"
valueChangeListener="#{BackingBean.changeParent}"
onchange="submit()" />
< f:selectItems value="#{BackingBean.parentsList}" >
< /h:selectManyListbox>
...
< h:selectManyListbox id="childs"
value="#{BackingBean.selectedChilds}"
rendered="#{BackingBean.parentId !=-1 }"
size="4" >
< f:selectItems value="#{BackingBean.childsList}" />
< /h:selectManyListbox>
...

In the backing bean:

code:


...
public void changeParent(ValueChangeEvent event)
{
Long parentId = (Long) event.getNewValue();
selectedChilds=new Long[0];
childList = getChildList(parentId);
}
...

My recipe for OOAD with UML

How do you go from requirements to coding?
Everybody has different alternatives. Working on my SCEA assignment, I'm using OOAD with UML.
I choose to have an intermediate point: I'm not formally doing the OOA first (only in my head) and the OOD doesn't have much detail.
Ingredients:

• Enough Use cases
• A Busines domain model (small)
• Some Aditional requirements
• Pen and paper (could be relpaced with a whiteboard)
• A working brain (hard to find, I usually manage without it ;-) )
• Plenty of coffee
• A beer

Read the use cases and requirements, stir that in your head for a while Get a piece of paper and draw the "map of the world" (existing components, outside systems, etc) to give your brain something to think about.
Create a very basic class diagram based on the domain model
Select one of most the complex use case and create a sequence diagram for it:

• Put the actors involved
• Choose the interface/style required to interact with them (web, Thick client, Messaging, etc.)
• Use the identified objects from the class diagram to fulfill the requirements from the use case
• Each object will have their responsibilities in the use case context.
• You will need to add more objects and/or split existing ones to better distribute those responsibilities
• Drink a cup of coffee
• Write your assumptions

Once you fulfilled the requirements of the use case, let the sequence diagram cool for a while.
Dump all the classes you identified in the class diagram and mix them with the existing ones.
Think how you can better organize it (if smells like refactoring, you’re good, but don’t expect any “code smell” we’re far from the code). Once you’re satisfied with the result, go back to the sequence diagram and adjust it so it conforms to the new class structure. If your class diagram grows too big (maybe # of classes >7+-2) organize it in layers: put one layer of services classes, one layer of domain classes, one layer of application classes, etc.
Once the class diagram is ready, group those classes in components of the component diagram (you can add lollipop notation for the interfaces, is a nice touch)
Rinse and repeat for the other use cases.
When you’re done, you can serve the components inside deployment units in a big deployment diagram.
Now you can take a break and drink the beer!

DISCLAIMER: as with most recipes, the real process is completely different

Yourdon's top ten software engineering ideas

While I'm busy working in SCEA part 2, I wanted to share this ideas from Yourdon.
He has a mindmap presentation about the top ten software engineering ideas (you can download the pdf here).
What he talks about?
1 - You can't control what you can't measure
2 - Peopleware
3 - Incrementalism
4 - Iteration
5 - Repair costs increase
6 - Tradeoffs are non-linear
7 - Reuse is important
8 - Risk management provides insights
8 - Consistency trumps brillance + death march
10 - Don't reinvent the wheel

Lots to comment on each one (he shows Brooks's "The Mythical Man-Month" and DeMarco's "Peopleware", I must agree!).

Waterfall, RUP, XP... and one process to bring them all, and in the darkness bind them

What happens if you have a big project to execute and your organization mandates Waterfall? Of course, you can try to follow the mandated process, and hope everything goes fine (bad news: chances are not).

As a rule, you must ALWAYS adopt/adapt the process to fit your project (and not the other way around)

A big project will be less risky using RUP, but if you can't convince the outside groups (typically management, QA, overzealous SPEG/SPI group, maybe the customers too) to use it, you can use RUP and make it look like a waterfall from the outside (but ONLY form the outside). BTW you should try to convince those groups that waterfall only looks good on paper and modern processes can yield better results, but it takes time, and probably you need to start right now with the project. How do you map RUP and Waterfall? Don't do the classic mistake of Inception=Requirements, Elaboration=Design, Construction=Coding & Unite testing, etc... you will be in trouble when at the end of Inception, the outside groups will ask for the complete requirements for review!

The trick here is map the end of Elaboration to the end Requirements phase, so you can collect all the requirements but also implement the critical ones. You can map the end of the Design phase to somewhere in the middle of Construction (or at the end if you can get away with it). When you're done with Construction, you can release your code to the outside QA team to do whatever they want. Probably is a good idea to have customer involvement early so he can try the system and provide valuable feedback (that's the whole idea!).

You will end with an oddly shaped (in time/effort) “Waterfall-looking” schedule but still all the advantages of an architecture centric iterative incremental methodology like RUP. And if you can't live without doing XP and will complain if you can't do it, you can safely do XP inside each RUP iteration...

BTW, by no means TRANSITION=TESTING!!!!

What's your project score?

The Standish group's CHAOS report has a table of success factors:

Success Criteria	Points
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

The study is not new, but still is valid. This are the critical factors for a project success.
Mapping it to your current project, will let you focus on the areas that will improve your chances...
What is your current project score?