It’s been a while since the last installment of ADF BC Tuning, but it’s time to start it up again. I’ve already posted tips for tuning entity objects, associations, view objects (in three parts), and view links, so now, let’s turn our attention to the last of the major business components: application modules.
Now that we’ve looked at tuning entity objects and associations, we’ll turn to talking about tuning your ADF view objects for good performance and memory management. There’s a lot to say about tuning view objects (more than for any other business component, in my opinion), so I’m going to break this topic up over two posts. This week, we’ll discover the reasons for and against basing read-only view objects on entity objects, learn how to control how much data is fetched into the middle tier at one time (and how to optimize this for your particular case), and talk about what passivation of view objects is and how to control whether and how much of it happens. Next week, we’ll talk about query-level range paging, forward-only mode, and the spill-to-disk feature for handling very large caches.
As promised, I’m posting of the presentation I’d been hoping to give at the OOW Unconference Methodology Symposium last week, expanded slightly for the more forgiving medium of a blog. As it turns out, it’s expanded substantially more than I thought, so I’m going to divide it into two parts. This week, I’ll talk about the basics of the methodology, its goals, and the two techniques it relies heavily upon. Next week, I’ll talk about the actual development process it specifies.
“Extreme Reusability” (the name is not mine, but rather Chris Muir’s; however, I decided I like it) is an idea for an ADF development methodology for mid-sized teams (generally around 4-20 developers) that I’ve been recently expanding on. Continue reading Extreme Reusability, Part I
This is the second part of a two-part series about undocumented tricks with shared application module instances. Last week, I talked about calling methods (at the application module, view object, or view row level) from shared application module instances. This week, I’m going to talk about displaying data (in a non-LOV context) out of them. If you want a general overview of what shared application module instances are and why I think using them is a good idea (particularly at the application scope), look here.
What is a backing bean? Getting a consistent answer can be harder than you might think. For example, the NetBeans JSF tutorial claims that the two terms are synonyms. And NetBeans had its origin at Sun, so they ought to know, right? On the other hand, the official Java EE 5 Tutorial says that a backing bean “is a JavaServer Faces managed bean that is associated with the UI components used in a particular page.” That suggests that backing beans are a proper subclass of managed beans. And that’s straight from the horse’s mouth, at java.sun.com.
I think that the distinction made by the Java EE tutorial–that a backing bean is a particular sort of managed bean distinguished by its association with a particular page’s components–is a very useful one. But the tutorial also states that “A typical JavaServer Faces application couples a backing bean with each page in the application.” And that is where we part company.