One way to address the problems you mention would be to actually tie IModel to Component instead of using a String id. This might give us quite a lot of flexibility because the whole point of getObject() 99.9% of the time is to produce an Object for a Component. in fact, one could argue that IModel should be a subinterface of Component (Component.IModel), but i think that gets too verbose.
NOTE: in the code below, it would still be possible to ignore Component if you wanted to, so current IModel functionality can be roughly retained (although we might get rid of a bunch of those extra constructors... which I never liked either!)
public class PropertyModel implements IModel
{
final Object object; public PropertyModel(Object object)
{
this.object = object;
}public Object getObject(Component component)
{
return Ognl.getValue(expression(component), getContext(), modelObject, propertyType)
}
public void setObject(Component component, Object value)
{
Ognl.setValue(expression(component), getContext(), target, object);
}
public String expression(Component component)
{
return component.propertyExpression();
}...
}
public String propertyExpression()
{
return ((PropertyMappings)mappings.get(getPage().getClass())).expressionFor(this);
}
public class PropertyMappings
{
// Properties file with OGNL mappings sits next to Page like markup file does...
private Properties properties;
...
public String expressionFor(Component component)
{
String expression = properties.get(component.getClassRelativePath());
return expression != null ? expression : component.getName();
} }
the method getClassRelativePath() would return the concatenation of Classes.getName(getClass()) for the Page (yielding the subclass name like MyPage) and the page relative path to the component. in other words, you might get something back like: "MyPage.Form1.user.name".
Chris Turner wrote:
This approach would certainly work quite well and would reduce the number of models and temporary strings we need to create (i.e. to access simple model attributes with property models). The only potential issue I can see with it is that there is probably not a direct one-to-one mapping between component name and model object property. There may be cases where I wish two components to refer to the same model property or I may have a page where I have to give the component a name that doesn't match the model property because there is already a component with that name already on the page. If we were to support passing id's to models then we would also need a way of mapping multiple ids to one model property (e.g. registerPropertyMapping(String id, String modelProperty). Additionally, property model should still have a way of taking expressions because ognl expressions do not only have to be a simple as just the name of a property (they can support nested properties "user.address.zip" or even call to methods and do indexing into arrays).
regards, Chris
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
------------------------------------------------------- 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
