Of course this idea of being partial bean partial dynamic bean (or in this case map) is on the weird side of things.

I guess in this case the get and put could respect the bean property as well.

 

That being said, I don't know if it's a good idea to treat a map as if it is only a Map. 

If I have getters and setters that control some sort of behavior of the map, they are properties of the map object not values controlled by the map.  It comes down to "properties" that serve different concerns.

 

In my particular case I can easily model the bean differently to have a map rather then be a map.  However I can imagine some sort of map in which the consumer may want to do something like

 

String vRetValue = "";

 

vMyMap.setAcceptNullValues(true);

vRetValue = vMyMap.get("SOMEKEY");

 

where acceptNullValues property is set by an IoC container.

 

Any thoughts?

-R

 

-----Original Message-----
From: Danner, Russ [mailto:[EMAIL PROTECTED]
Sent:
Friday, October 14, 2005 5:52 PM
To: '[email protected]'
Subject: Question about property resolution

 

Hello all,

 

First before ranting... I want to say THANK YOU for this framework implementation.  I think it is great.

                                   

And now the rant J

The My Faces property resolver uses an algorithm for getType that first checks to see if the resolved "Base" object is a map.

When the object is a map the code looks inside the map then responds with the outcome.

 

This works great when the bean I have is ONLY a map.  Suppose I have a class which implements map, but also has other bean properties that need to be addressed. 

 

There needs to be some precedence: like BEAN interface then SPECIAL interfaces or visa versa. But we cannot simply treat maps as if they are not beans.  We should not create an environment in which beans can be either a first or second class citizen.

 

I think the bean standard should be respected first then any other special interface resolver should be able to be plugged in.

IE one for maps, another for dynamic beans etc.

 

 

We should correct this as it creates incompatibility with applications implemented with the java RI.

 

See attached code:

    public Class getType(Object base, Object property)

    {

        try

        {

            if (base == null || property == null ||

                property instanceof String && ((String)property).length() == 0)

            {

                throw new PropertyNotFoundException("Bean is null");

            }

 

            if (base instanceof Map)

            {

                Object value = ((Map) base).get(property);

 

                // REVISIT: when generics are imlemented in JVM 1.5

                return (value == null) ? Object.class : value.getClass();

            }

 

            // If none of the special bean types, then process as normal Bean

            PropertyDescriptor propertyDescriptor =

                getPropertyDescriptor(base, property.toString());

 

            return propertyDescriptor.getPropertyType();

        }

        catch (PropertyNotFoundException e) {

            throw e;

        }

        catch (Exception e)

        {

            return null;

        }

    }

 

Best Regards,

-R

______________________________________
R U S S   D A N N E R
Architect
Technology Services Group
[v] 617.450.3086 [f] 877.408.8154
[e] [EMAIL PROTECTED]

The First Church of Christ, Scientist
One Norway Street | Mailstop: C01-20
Boston, MA 02115-3195

 

Reply via email to