Use of Converters

[Matt Hughes <mh...@chariotsolutions.com>]

I have begun using converters more extensively in my project, and at 
first, I was using them in the typical way (creating a unique String 
representation of the object, and then back again), but recently I have 
begun toying with the idea of having a object lookup stored as a field 
in the converter.

Say I have object Foo in my system.  Foo is an immutable object with a 
primary key.  When FooConverter starts up, I get a list of all the Foos 
from my database, and populate a Map<PrimaryKey of foo, Foo>.  So my 
FooConverter looks something like:

String getAsString(Foo fooObj) {
    return String.valueOf(fooObj.getPrimaryKey());
}

Object getAsObject(String valueAsString)
{
    return fooMapLookup.get(valueAsString);
}


I should note that I am extending the JSFApplication class using Spring 
so that I control how the converter gets created, and using Spring 
inject the service used to build the map of Foos.

This approach seems to have three main advantages:

1) your getAsString method can return a much more concise String, as it 
only needs to return a primary key for lookup.  Using the regular 
approach to converters, every time you add a property to the object you 
are converting, you need to append a String version of that property to 
your getAsString() method.

2) if you have 500 Foo instances in your database, you will only ever 
have 500 Foo objects in your system at one time (assuming you converter 
is application scope) and  you won't be creating objects on every form 
submittal.

3) you can use your converter to add some validation to your program.  
If my lookup map has all the possible Foos in my system, and someone 
submits a value that is not in that lookup, I can throw a 
ConverterException.


Has anyone else used this approach to converters?  Does anyone see any 
pitfalls to doing it this way?

Re: Use of Converters

[Mert Çalışkan <mc...@gmail.com>]

We are using a converter to fetch the values from lookup tables in a generic
way.
POJOs are implementing an interface like,


public ILookupObject {

            public Object getThis();

            public Long getId();

            public String getName();

}

and a converter is defined in faces-config.xml for all the classes
implementing this interface.
While rendering selectable items, each lookup object -fetched calling
getThis(), in which lookup objects return themselves- is given into
Converter.getAsString(...)  method. This method returns getClass().getName()
+ '_' + getId() as identifier value.



And we're using it from jsf pages like,



<h:selectOneMenu id="cmbCountries" value="#{
personelPageCode.personel.country }">

            <f:selectItems value="#{
selectitems.personelPageCode.countries.name.this.toArray}" />

</h:selectOneMenu>

Only bu specifying an el, we can fill a combo box with values from dbase.
You can find detailed information at my teammate's
blogpost<http://www.jroller.com/page/ksevindik?entry=lookup_tables_with_hibernate_and>
.


Regards,

Mert


On 5/12/06, Julian Ray <ju...@yahoo.com> wrote:
>
>
> Hi Matt,
>
> we use a similar system to look up values for business object by primary
> key
> from the database which is highly de-normalized. We use Hibernate and have
> developed a base-class which we can either extend for unusual cases or use
> passed table/pk name via tag attributes.
>
> It works well and as Hibernate caches everything there is little impact on
>
> the database :). One trick is to return different values from the PK
> lookup
> such as names/addresses etc.. which are in user-configurable through our
> GUI. To do this we have default "long" "short" and "medium" formats
> available in the base class which can be interpreted based on the table
> being accessed.
>
> We did find that a generic lookup-converter is less useful (from a GUI
> developer perspective) as it tends to break the MVC model and lead to code
>
> changes in the JSP when the underlying data model changes so we now have
> created sub-classed converters for each table which is preferable.
>
>
> --
> View this message in context:
> http://www.nabble.com/Use-of-Converters-t1608471.html#a4360735
> Sent from the MyFaces - Users forum at Nabble.com <http://nabble.com/>.
>
>

Re: Use of Converters

[Julian Ray <ju...@yahoo.com>]

Hi Matt,

we use a similar system to look up values for business object by primary key
from the database which is highly de-normalized. We use Hibernate and have
developed a base-class which we can either extend for unusual cases or use
passed table/pk name via tag attributes.

It works well and as Hibernate caches everything there is little impact on
the database :). One trick is to return different values from the PK lookup
such as names/addresses etc.. which are in user-configurable through our
GUI. To do this we have default "long" "short" and "medium" formats
available in the base class which can be interpreted based on the table
being accessed.

We did find that a generic lookup-converter is less useful (from a GUI
developer perspective) as it tends to break the MVC model and lead to code
changes in the JSP when the underlying data model changes so we now have
created sub-classed converters for each table which is preferable.


--
View this message in context: http://www.nabble.com/Use-of-Converters-t1608471.html#a4360735
Sent from the MyFaces - Users forum at Nabble.com.