Hm...
Really seems like you're trying to work swim against the current...
For your example, I wouldn't forgo the bean model.
I would probably create a "MapBeanModel", which takes a map as an
input, and implements the BeanModel interface.
(An alternative might be to create a MapBeanModelSource service,
which uses the normal "BeanModelSource" service to generate
a model, strips out whatever columns the generic model added, then
adds the entry set to the model).
A map bean model source implementation seems pretty trivial,
something like...
//you would likely want to define this as an interface, and then
implement the interface, but for the sake of brevity...
public MapBeanModelSource {
private final BeanModelSource _beanModelSource;
public MapBeanModelSource(final BeanModelSource beanModelSource) {
_beanModelSource = beanModelSource;
}
public BeanModel generateBeanModel(Map<String,String>
map,ComponentResources resources) {
BeanModel model = _beanModelSource.create
(Map.class,false,resources);
//remove is varags, so you could get fancy and do this in
one line if you wanted...
for(String name : model.getPropertyNames()) {
model.remove(name);
}
for(Entry<String,String> entry : map.entrySet()) {
model.add(entry.getKey(), new MapPropertyConduit
(entry.getKey());
}
return model;
}
}
//not generified, for the sake of brevity...
public class MapPropertyConduit implements PropertyConduit {
private String _key;
public MapPropertyConduit(String key) {
_key = key;
}
public Object get(Object instance) {
return ((Map)instance).get(_key);
}
public Class getPropertyType() {
//since your example used a Map<String,String>, assume
string...
return String.class;
}
public void set(Object instance, Object value) {
((Map)instance).put(_key,value);
}
}
Disclaimer: above code is written entirely off the cuff, but it
should convey the general idea.
And with that, any time you have your list of maps, inject your
service and build your bean model that way.
Voila... no "row class per list".
Robert
On Aug 14, 2007, at 8/1410:19 PM , Daniel Jue wrote:
I am trying to find the best approach to making changes to the
existing Tapestry 5 core components. This is what I've thought of so
far. Please add suggestions or correct me!
Very Small Changes:
Changing the look of a component:
1. Override styles with your own CSS file, no changes made to
actual components.
Small Changes:
Changing an image used in a component:
1. Hacking the actual T5 library (replacing image files)
(unmaintainable)
Medium Changes:
Changing the non-programmatic html output:
1. Hacking the actual T5 library (replacing or modifying the template)
(unmaintainable)
Big Changes:
i.e. Changing the html markup that gets output, or changing data
model:
1. A complete rebuild of component that exists the way the T4
contrib did.
2. Hacking the actual T5 code (bad, unmaintainable)
i.e. Pulling the GridPager away from the Grid.
1. A complete rebuild of component that exists the way the T4
contrib did.
A real life example:
I want to display a Grid without using the BeanModel. My data is in a
list of maps, with each row item being a map<String,String>. Rather
than construct a row class for each list, I'd rather supply a keySet()
of the column names. I would think this falls under the "Big Changes"
category.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
