i see the implementation this way:
public interface IModel
{
public Object getObject(String id)
public void setObject(String id, Object value)
}a very simple mapmodel:
public class MappedModel
{
private Hashmap values;
getObject(String id) return values.get(id);
setObject(String id,Object value) values.put(id,value)
}A propertymodel:
public class PropertyModel()
{
private Object object;
getObject(String id) return Ognl.getValue(id, getContext(), object, propertyType);
setObject(String id, Object value) Ognl.setValue(id, getContext(), object, value);
}
Then only Forms would have to have a Model like one of those
And Fields just call that model with there propertyName (not name itself, i would like to split that)
Of course fields can have there own model also if they want that like a simple model:
public class SimpleModel
{
private Object object;
getObject(String id) return object;
setObject(String id,Object value) object = value;
}Then most of the model creation we have to do now are gone.
johan
johan
Jonathan Locke wrote:
since wicket components have to have names, wouldn't it work to just add the component's name as this "data provider id"?
public interface IModel { public Object getObject(String id) public void setObject(String id, Object value) }
we'd then change Component.getModelObject() to this:
public final Object getModelObject() { final IModel model = getModel(); if (model != null) { return model.getObject(name); } else { return null; } }
we would actually continue to allow IModels to do anything they want (they can ignore the id or do OGNL or return a random Object) and you could implement a compound property model object like you're talking about (if i understand you right). in this case we'd have a PropertyModel wrapper that takes an Object like so:
public class PropertyModel { final Object object;
public PropertyModel(Object object) { this.object = object; }
public Object getObject(String id) { // reflective get return Objects.getValue(object, id); }
public void setObject(String id, Object value) { // reflective set Objects.setValue(object, id, value); } }
so now a Form can actually edit a model by having a PropertyModel and the children of the Form can be constructed with just a name. then FormComponent.initModel() doesn't create a PropertyModel wrapper. it instead just returns the Form's model.
as long as we don't lose the generality and detachability of IModel as it exists, i'm not against being more efficient.
is the above what you're trying to say? (i didn't really understand what you were saying until a few hours after i responded the first time...)
best,
jon
Jan Blok wrote:
Hi,
What made you decide to do things like this?
Eh, Ease of use (as mostly all things are name-value pairs), less objects created, over 4 years databinding experience ;-)
Efficiency?
Also, less objects to create is more efficient, be able to support more end-user, notice also vastly less call to make to attach/detach for all current PropertyModel's (since the PropertyModel could handle multiple name-value pairs, becoming a real properties-model)
And how would a component know how to get its data?
As indicated our components have get/setDataProvider, but keeping using expression in the component constructor would be no problem I guess
I guess it needs some kind of registry to get the model from first,
right? No, no change there, only other method signatures on IModel, that's all...
Regards Jan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eelco Hillenius
Sent: Thursday, March 03, 2005 10:30 PM
To: [email protected]
Subject: Re: [Wicket-develop] Wicket IModel questions
Interesting. What made you decide to do things like this? Efficiency? And how would a component know how to get its data? I guess it needs some kind of registry to get the model from first, right?
Eelco
Jan Blok wrote:
Hi,
I'm investigating Wicket for possible use in Servoy
(Servoy.com is a
database development/deployment tool ala
M$-access/filemaker/4d/etc)
while going trough the JavaAPI to investigate how the
databinding is
done and how wicket is working internally I have some questions.
As we are doing some serious databinding between models and components in Servoy I really wonder why your IModel is so
high-level?
, it seems to me you need many models which are not very useful.
I noted some is already done to overcome this like:
-defined:Component(String name,Serializable object,String
expression)
-used:new MyComponent(name, new PropertyModel(new Model(model), expression));
But to give you an idea how we handle databinding inside Servoy we give all Components a "dataProviderID" so all components have get/setDataProviderID(...) methods and our model have getValue(dataProviderID) and setValue(dataProviderID,newValue), by doing so a model is always something like a row/record/non
primitive
object/map, instead of just a value wrapper.
Would it be an idea to do something similar? to overcome model in model constructs...just a thought
So far it seems to me wicket is a very cool framework!
Regards Jan Blok Servoy
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
