On 9/19/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
Person person = new Person();
CompoundPropertyModel personModel = new CompoundPropertyModel(person);
Component parent = new Component(personPanel, personModel);
Component child = new Component(addressPanel, new CompoundPropertyModel(new
Person person = new Person();
CompoundPropertyModel personModel = new CompoundPropertyModel(person);
Component parent = new Component(personPanel, personModel);
Component child = new Component(addressPanel, new CompoundPropertyModel(new PropertyModel(address, personModel)));
Just for my
On 9/19/06, Johan Compagner [EMAIL PROTECTED] wrote:
yeah thats nice, but you just lost the flexibility of where the address can come from (no imodel indirection - yeah you can make yet another constructor) and more importantly the short hand compound property model notation. if i can use the
and there is another problem with the automatic-versioning-that-would-make-your-life-as-a-wicket-developer-much-more-easier because now form components don't do version of there models.. Because it is data and we most likely don't want to version that
But with our
hmm but form components are written by us, we can make those fields transient?i dont know, for 2.0 it might be cool to just clone the page every time - we already do this anyways when storing to disk. the change thing is pretty error prone and hard for n00bz and even not so n00bz. the other big
form components transient fields?where are you talking about?I was talking about the models under the form components which now are not causing a model change even if new data is comming inbut if we do a complete capture i see those model changes and i say he it is changed, now create a new
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;No but what does that solve?
It will save a lot of complexity for the serialization because you can delegate to the
but you know they are formcomponents, so the versioning thing can skip models of formcomponents-IgorOn 9/19/06, Johan Compagner
[EMAIL PROTECTED] wrote:form components transient fields?where are you talking about?
I was talking about the models under the form components which now are not causing
Especially the determination of differences between object graphs might
get complex. By the way, it might be useful to look at Hibernate and
JDO because these tools do something similar, detecting changes made to
an object-graph and performing the appropriate (minimal) updates
(changes) towards a
And the problem is.. When they can't use the dump to disk approache, what then?I agree we can do without the undo buffer, but not with the version number. (because that pin points the right file on disk)so we still need the completely modelChanging() and so on. because we need to update the
As igor says. getters and setters are not needed. I do it purely on the none final and none static fields.It is not really an own serialization. Just our own way of creating a snapshot (but not serialize everything)
And a completely page is already done in 2.0. That one is saved to disk. So yes in
is the reflection stuff working out?i guess if a property is an IModel you need to keep the reference AND recurse into it? just in case the reference changes?-Igor
On 9/18/06, Johan Compagner [EMAIL PROTECTED] wrote:
As igor says. getters and setters are not needed. I do it purely on the none
But then what will be the solution?
cloning pages and keeping them in memory is not an option
saving pages to disk is also not an option for performance
reasons and because it will not work in a cluster where the nodes of
the cluster do not share a common fiile system.
only storing
saving pages to disk is also not an option for performance
reasons and because it will not work in a cluster where the nodes of
the cluster do not share a common fiile system.it is not really a peformace hit. And if working in a cluster it still works fine, because sticky sessions is really the
Person person = new Person();CompoundPropertyModel personModel = new CompoundPropertyModel(person);
Component parent = new Component(personPanel, personModel);
Component child = new Component(addressPanel, new CompoundPropertyModel(new PropertyModel(address, personModel)));i dont think this is
Yes thats the idea.look at the main modelread all the fieldsmake copy of the fields references if they are: primitives or immutable (strings)make a clone of the fields objects if they are muttable and not an imodel instance
make a copy of the field reference if it is an IModel instance and recurse
And i only stop at Strings, Numbers and primitives.But i don't know if that can currently really work (enums?)
i think it might, but i dont think it is something we will know for sure until we build it. there are always those little pesky things you didnt think of that really get in the way.why
I find this extremely ugly..And totallly unreadable, i really had to think about this one. My first reaction was that won't workBut then i though ahh 2.0 so first you go to the init model.. getting the model from the parent
and then quickly set that model (which is then a Inheritable) as the root
On 9/18/06, Johan Compagner [EMAIL PROTECTED] wrote:
I find this extremely ugly..And totallly unreadable, i really had to think about this one. My first reaction was that won't workthat hurt! i think it is rather clever! if i ever see any code by you using this trick i am kicking your ass!
But
i agree with igor. What does this really gain?How will versioning and then the undo to that version work???johanOn 9/17/06, Erik Brakkee
[EMAIL PROTECTED] wrote:
One of the things I was thinking of is actually sharing the same
CompoundPropertyModel but then requesting a child model of the
On 9/17/06, Johan Compagner [EMAIL PROTECTED] wrote:
i agree with igor. What does this really gain?How will versioning and then the undo to that version work???
Child components will not do versioning. Only the top-level parent will. The child components simply delegate to their parent.
Or is
I just looked a bit at the code for ModelChange.java in wicket 2. I see
the problem now. The CompoundPropertyModel is being cloned so if there
is another model referring to that model, it will always refer to the
wrong version of the model in case an old version of the page is
requested.
A
What is that ModelRegistry thing?Does that return a model? So models are not attached to components?That won't work in clustering or serialization of the http sessions.The only thing i can think of is having a method on an interface (that extends IModel)
that is something like: getChangeState()And
On 9/17/06, Johan Compagner [EMAIL PROTECTED] wrote:
What is that ModelRegistry thing?
That is something which I just thought of. The only thing that would manage is a mapping of model to ids.
Does that return a model? So models are not attached to components?
Models are still attached to
how is a model attached to the component if they have to be looked up from somewhere?Where i that lookup being done? And where is the looked up model comming from?remeber Models can also be used over more then one page.
i am still looking into a third alternative. And that is doing the
On 9/17/06, Johan Compagner [EMAIL PROTECTED] wrote:
how is a model attached to the component if they have to be looked up from somewhere?Where i that lookup being done? And where is the looked up model comming from?
The model is attached to a component. It just has a unique id which
must be
When we get an undo we go use our PropertyResolver to set all the properties back into the current model.
That only works if all manipulation is done through getters and setters. not exactly true. you can read and set fields, even if they are private (depending on the security manager which 99%
On a totally different note, generalizing a bit, what we are trying to
do is to version an object-graph (in-memory). Arent' there any tools
available that already do this? In particular, all we want to do is to
version the page object together with all components, models, and
instance variables it
here are just some thoughts _off the top of my head_maybe instead of doing this: ModelChange:68+ what we need to do is make our cloning even smarter.as we are cloning the model we need ot check if the internal state contains an instance of IModel - when we see that we need to traverse the upwords
public class AddressPanel extends Panel {
public AddressPanel(MarkupContainer parent, String id,
IModelAddress AddressModel) {
...
}
new AddressPanel(this, ap, new AddressModel(employeeModel));
new AddressPanel(this, ap, new AddressModel(employerModel));
And all the other variations
no, this is not what he means. i have these types of panels all the time in my app as well, it works like thisAddressEditor(..., IModel addressModel) { super(...) setModel(new CompoundPropertyModel(addressModel));
that setmodel is what breaks things. you wrap the model you get in a
how i read his mail is a bit differentDoes he reallyv do it with a inner model?i think he does this:AddressEditor(..., Address address) { super(...) setModel(new CompoundPropertyModel(address));
and address i get from person that is in a CompoundPropertyModel of the addresseditors parent..And i
On 9/16/06, Johan Compagner [EMAIL PROTECTED]
wrote:
how i read his mail is a bit differentDoes he reallyv do it with a inner model?i think he does this:AddressEditor(..., Address address) { super(...) setModel(new CompoundPropertyModel(address));
if you do the above then we cannot do much,
Lets make an example thenCompoundPropertyModel modelParent = new CompoundPropertyModel(new Person());Panel parent = new Panel(xx, modelParent);CompoundPropertyModel modelChild = new CompoundPropertyModel(new PropertyModel(address,modelParent));
Panel child = new Panel(yy,modelChild);now a change
One of the things I was thinking of is actually sharing the same
CompoundPropertyModel but then requesting a child model of the
CompoundPropertyModel using a new API call, for instance:
CompoundPropertyModel personModel = new CompoundPropertyModel(person);
CompoundPropertyModel addressModel =
i think all this will do is add a buch of more checks into the core for the ChildCompoundPropertyModel, or whatever it ends up being called. the internal implementation of it will be almost identical to new PropertyModel(compoundmode, foo)
the problem is, as i said, that the model is so opaq from
36 matches
Mail list logo
