|
From: Martin K. <Mar...@St...> - 2005-02-26 10:47:47
|
> I understand the diffrence between list set map but I do
> not know what property (bean), property (props)
> and element(map) makes so distinct.
Thinking about it, I don't understand the distinction between
set, list, props and map not more.
All four are collections. A property is an element, too.
<collection>
<element name="element1">value</element>
<element name="element2">value</element>
</collection>
This definition defines a domain layer and the set,list,map,props
is simply a special view on this domain. So when this described
collection is injected into any bean, the beans set property
method will decide which view on this declared model has
to be injected.
setMapProperty(Map map);
setListProperty(List list);
setSetProperty(Set set);
setPropertiesProperty(Properties properties);
A collection can be expressed in all those views on the
collection's data. The view kinds are not semantically equalent
of cause. Also the view becomes independent or is a model
itself. So using a certain view becomes a conversion from
one model to another. (but relativly speaking for the
first model the second expresses a certain view
(view imposes a metamodel)).
The next thing is that a element don't need a name in case
of a list. So name is a description providing additional
informations. If it is so, we need to find a way to derive
this additional information if we need it. This can be
solved plugable with a default way of using toString().
Meaning in case there is no explicit name specified a
the implicite name is used. The implicite name is the
self description of the element (Object.toString).
The implicite name may be a source of plugable logic
(e.g. property editor). So if you add an Image having
a name, you might use something like this:
<collection>
<element><bean class="Image"/></element>
</collection>
setImages(Map images);
-> This will result in injecting a map with the following
type Map<String imageName,Image image>;
With this also injecting selfdescribing bean properties
would be possible. This would increase the abstractness of
the declaration language.
<bean class="MyApplication">
<property>
<bean class="ApplicationModel"/>
</property>
</bean>
You don't need to know the properties name. It's up
to the application and the application model to find a
suiteable solution. So the user of the application and
the model, meaning writing it's own declaration, does
not know any additional implementation details.
I guess this would ease the framework by increasing
the abstractness of the descriptive language. Which
is desireable.
Cheers,
Martin (Kersten)
|