Reuse - Base class for backing beans

[John Flack]

I found that there were some methods that I was writing again and
again in backing beans. So I finally wrote my own backing bean base
class, and now all my backing beans subclass it. Anybody else doing
this? Good idea or bad? Another approach is to write utility classes
like Steve Muench;s EL class, and call the utility methods where
needed. Or some combination of the two.

[Avrom Roy-Faderman]

Well, I don't know about the EL class *specifically*--you're really not
"supposed" (by Faces standards) to be resolving EL in your beans (as
opposed to using injection). But the general idea of using
utility/singleton/pseudo-singleton classes (for things that can be
determined without injection, e.g., through BindingContext.getCurrent())
is preferable to doing this in a base class, because the coupling's
looser.

Here's what I mean: Suppose you have a base framework bean class,
myorg.framework.backing.BaseBackingBean. Then, you find a really cool bean
class published by a third party that you really want to use, but you need
to add in some functionality that is present in BaseBackingBean. You're in
trouble--you can't extend two classes at the same time, so you'll have to
duplicate code from one of them.

Now, by contrast, suppose you've just created a utility,
myorg.framework.util.BackingBeanUtils, and then you find that really cool
thrid-party bean. Now, it's no problem: You extend that third-party bean,
and delegate to methods from BackingBeanUtils. No code needs to be
duplicated.

A general principle: Subclassing to get functionality is more limiting
than using a utility to get functionality (which allows the base class to
vary), which itself is more limiting than using a composed object to get
functionality (which allows *both* the base class *and* the functionality
provider to vary). There can be factors that are more important than this
(e.g., if you want functionality from a class' protected methods, or if
the functionality is part of a framework that might call package-scoped
methods on it [as BC classes are], you'd better extend that class).

Best,
Avrom

--
Avrom’s Java EE and Oracle ADF Blog
http://www.avromroyfaderman.com

[Michael Koniotiakis]

We are also using base class for backing beans
We also use JSFUtils and ADFUtils.
In base backing bean we have methods for all actions and bindings to
template components.
(Like commit, rollback, insert, delete, exit, close, navigateTo,
openPopup etc)
We dont bind actions directly to bindings but allways to backing bean
that execute operations from bindings
For example for Commit button we have a method in Base class that
execute operation.
This helped us to add or change logic to all Commit buttons.
i.e. To add information on page that Commit was succesfull
To check if there are changes on transaction and if not to show
message that 'No changes to save'

I think this saves us from a lot of repeating code.

On 16 Οκτ, 02:27, "Avrom Roy-Faderman" <av...@avromroyfaderman.com>
wrote:

[Chris Muir]

Can't say we've created a backing bean super class either. As Avrom
says most of the common code required in the BBs goes into a utility
class as a static function.

We do use JSFUtils and ADFUtils, though we're rewriting them from the
ground up. This isn't an indirect comment on the quality of the
utility classes or there authors, but rather I'm not a big fan of
taking utility classes and leaving all the supplied methods in as
they're not tested in anyway by the programmers, the next programmer
can falsely assume they work correctly. Instead as we need a function
in the utility class we add them, with the assumption they then get
tested by the programmer at hand.

Regards,

CM.

[John Stegeman]

We *have* used backing bean super classes for specific use cases,
although not simply as a container for utility methods. The case I
have used them is when we have an application with a number of screens
that have similar/same functionality. An example of this is an
application where we esentially have a set of screens that all
function exactly the same way except that they each are used for
maintaining a different underlying database table. there was some
benefit in using a superclass for backing beans for those specific
screens - it enabled us to have the actual backing bean be simply a
constructor that set some private attributes (binding names and so
forth) that were defined for use in the parent class.

John

[Jang Vijay Singh]

From this discussion, it hasn't emerged that it is in any way a bad
practice to have beans inherit methods/functionality from other base
classes.
So I guess it would hold true for event handler methods (like Value
Change Listeners, action listeners, validators)? I don't see any valid
reason it should be unless the base methods are closely tied to
specific binding names which may or may not exist in all pageDefs in
which that code gets used.

JV

[Brenden Anstey]

Hi all,

I have been using the the base class approach on regular basis for
over year now and it definitely has its merits.

http://brendenanstey.blogspot.com/2007/03/how-to-reduce-coding-by-extending.html

As John said the benefit of this comes in to play when you have really
simple stuff to do in the backing bean like chaining execution of
commit, execute or determining the outcome based on the value of
something.

If I remember correctly there was some talk (with Frank N) of defining
a base class somewhere in the UI project that would be extended
automatically when new managed/backing beans are created.

cheers,
Brenden

[Florin Marcus]

Hi Brendan, interesting and useful posting!

Just one idea: how about the 'execute()' method from your example to
return the exception object instead of a boolean value.
It might prove useful when the business code is using a custom stack
of application exceptions.

Best,
Florin

On Nov 6, 2:25 am, Brenden Anstey <brenden.ans...@delexian.com>
wrote:.

> Hi all,
>
> I have been using the the base class approach on regular basis for

> oer year now and it definitely has its merits.
>
> http://brendenanstey.blogspot.com/2007/03/how-to-reduce-coding-by-ext...

[Brenden Anstey]

Hi Florin,

absolutely, the JSFBean could go a lot further. Execute including
parameters and better return types would definitely enhance the
functionality.

cheers,
Brenden

> > Brenden- Hide quoted text -
>
> - Show quoted text -