I think you miss the point. IModel itself is never serialized as part of the change, only the object it is pointing to is. So you are free to share an imodel between two components and you will not end up with two underlying copies when undoing changes.
This is why ISortStateLocator also has a
Right your locators do not have this problem. But why don't have a plain
IFilterState{getFilterBean()} and if it implements IVersionable call
before a change beforeUpdateSave(this)?
For general IModels I think I am right. If I understand right (please
correct and forgive ignorance) I think
I think this could work and in face of sharing the IModel I think it would
be needed (not sure so).
Letting the model do it itself: I think this is more explicit and direct.
At least the users sees what is going on with versioning of Models. It
somehow takes the magic out of it and is not
Hey be nicer to yourself! This was the only thing you overlooked and don't
remind me of what you tought me;)
I think this is a good idea. Keeps the default easy go behaviour and could
be optimized.
Could there also be a way to turn modelObject versioning off just in case
I do want to do my
The problem with this is (i looked further how IVersionable should work)is that in a Model doesn't have to be ONE single object is the object to version.For exampe the HibernateObjectModel has these: private boolean unproxy;
private final Class objectClass; private final boolean
i guess the question is does calling setmodelobject on the model modify the model itself. i would think this is not a very good pattern because the model should only be responsible for locating the object. so yes, this wont work very well in a situtation where setmodelobject/getmodelobject has
I think this would be not such a big problem as long as addStateChange()
was public. A Model which needs versionioning of its internal state would
just take any component in the construtor and add the Change to it on
modification. In the end the changes will all endup in the page.
The Problem
HibernateObjectModel or better said the super class of it must be versioned!But you are right not through the setModelObject because that is illegal:throw new UnsupportedOperationException(an object can only be set through its id);
and that is the thing that must be serialized:public final void
i guess that is an example of the anti-pattern i was talking about. the model should be immutable! it should take the id in its constructor and not allow anyone to change it. if you need to change it create a new model and call setModel() that way the model with the old id gets versioned. can you
I still do not think we need to provide a public setStateChange() method, but maybe i am wrong. I think if pojo wants to implement its own versioning it is out of scope of wicket. you can always call Page.getVersion() and do your own rollback.
What may help is maybe having two interfaces
Don't know about thatWhy can i change all other models data but not that one?If i have a PersonDetailPage with that modelWhy should i constantly set a new model where i just have a different id?I just wnat to set the id of the person i want to edit.
And When you really set a complete model. Then
As far as I know all Change(s) get recorded through the component in thePage's versionManager which on the automatic version rewinde just executes
all the Change.undo(). Where the Change comes from, what it does and howit get's there is not important. IMO it would work for Models as forComponents
So to summarize your idea it would be like thisclass SingleSortState IChangeRecorder recorder; SortState(IChangeRecorder) {...} setPropertyState(...) { recorder.addChange( new Change() {...} )
}OrderByLink { onclick () { getState().setProperty(...); } }this has the same net affect as OrderByLink
ok first pass is in. filter stuff is not all there and some of it is broken, but the major idea is there. the rest should be in pretty good shape though. its mostly backwards compatible so there should not be any problems. feedback?
-IgorOn 12/4/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
I think
Hi,
I've just checked out the new version. Thanks for the work. Here is my
feedback:
I think the 'FeatureModels' like ISortState should record the StateChanges
themself or at least create the Change objects themselfs.
Imagine I have a link 'clearSort'. Than in the onClick() I'd have to
On Fri, 2 Dec 2005 22:51:05 +0100, Johan Compagner [EMAIL PROTECTED]
wrote:
Maybe we should build something that it is easier for models to version
themselfs. Like an interface IVersionable with a method Serializeable
getVersionData()
Which a model can implement. And then we don't store the
The data provider is kept as the model because that is where the
sorting state lives and that needs to be versioned. I need to refactor
that out of the dataprovider looks like.
-IgorOn 12/3/05, Christian Essl [EMAIL PROTECTED] wrote:
On Fri, 2 Dec 2005 22:51:05 +0100, Johan Compagner [EMAIL
The data provider is kept as the model because that is where the sorting
state lives and that needs to be versioned. I need to refactor that out
of
the dataprovider looks like.
I see.
Maybe an interface ISortOrderProvider which is exactly like
ISortableDataProvider but does not extend
the problem im having is that something somewhere has to version this information. if i put it back into the dataprovider then we are back to square one. the problem is compounded by the fact that i want to add toolbars (like a filter toolbar). this means that the dataprovider has to be aware of
19 matches
Mail list logo
