Wow Robert, I was totally going in the wrong direction on that one!
I had some confusion on how the Conduits worked, and I had thought the
BeanModel* was doing more reflection deeper in the code.
The code you wrote works great! I am now using maps back my Grid!
I haven't yet implemented a way to inject the MapBeanModelSource, so I
am injecting a regular BeanModelSource and doing this:
@Inject
private BeanModelSource bms;
public MapBeanModelSource getMbms() {
return new MapBeanModelSource(bms);
}
I'm still learning how to use the contribute* in my appmodule.
Since I'm on my 3rd espresso:
A row in my code is actually a Map<String,FormattableDataItem<<RAW
extends Comparable>,DISPLAY>
Where RAW is something like a BigDecimal.
Then I have a custom ColumnModel that is a Map<String, BasicColumn>
My BasicColumn class all the settings I need for a column, and is used
when plucking columns from a resultset, and assigning a DecimalFormat.
It also holds aggregate data for the column and tool tip text for the
column.
On 8/15/07, Robert Zeigler <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
