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.
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
> 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.
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:
> 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
> > 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.
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.
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
On Oct 21, 4:05 am, Chris Muir <chriscm...@gmail.com> wrote:
> 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.
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
On Oct 21, 10:35 am, John Stegeman <john.stege...@gmail.com> wrote:
> 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
> On Oct 21, 4:05 am, Chris Muir <chriscm...@gmail.com> wrote:
> > 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.
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.
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:.
> 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.
> 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.
> > 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.
|
