if im not mistaken we are cloning the model now so how is it any more waste of space if you are doing the exact same thing?-IgorOn 12/7/05, Johan Compagner
<[EMAIL PROTECTED]> wrote:Don't know about that
Why can i change all other models data but not that one?If i have a PersonDetailPage with that
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 we
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 IModelVers
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 e
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 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
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 non-
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 createNew
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 o
heh, excuse me while i pull my head out of my ass. maybe i should stop staying up till 1am every day working on this stuff and go to bed earlier :)i was under the impression that we handle setmodelobject differently in that a call to that would only clone the object the model is pointing to and not
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 that
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 you
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 sett
I think they are wicket-specific, because where outside of wicket would
you need a wicket interface?
And if you implement it yourself you will have to think of versioning,
otherwise you will have to think of versioning everytime you just use it.
For now I'd say have for POJO IFilterLocator a
r
I still think we need just an interface:IVersionablewith 2 methods:Serializeable getVersionObjectsetVersionObject(Serializeable)Then we must make a choice.. Models that don't implement this are cloned like we currently do or don't we do anything?
Most models in a detached state just (or should) sto
I guess the question is do we want to infact make it something wicket-specific. right now its just an ordinary pojo you can use anywhere you like. but if we roll the versioning logic into it, it really does become locked to wicket. that is why i struggled to find a way to keep versioning out of it
On Tue, 6 Dec 2005 12:25:23 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
So to summarize your idea it would be like this
class SingleSortState
IChangeRecorder recorder;
SortState(IChangeRecorder) {...}
setPropertyState(...) {
recorder.addChange( new Change() {...} )
}
Order
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 Or
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 (
On Tue, 6 Dec 2005 08:47:23 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
On 12/5/05, Christian Essl <[EMAIL PROTECTED]> wrote:
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
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 call
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
I think an even cleaner solution would be to turn this idea inside out. have the dataprovider act as a locator for toolbar models, and let the toolbars version changes themselves. instead of the locator interfaces having only a get method they will have a set method as well, essentially they become
On Sat, 3 Dec 2005 13:21:15 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
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.
I hope that it does not cause any problems when a DataView hold
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 di
I dont think that you'll need to change IDataProvider. If a concrete
DataProvider class would support sorting than it should just take ie in
the constructor an ISortOrderProvider. Maybe you could even keep the
ISortableDataProvider. It just implements IDataProvider and
ISortOderProvider and a d
already on it. havent figured it all out yet. the problem is i think i will have to change IDataProvider to take extra parameters. this will break all the clients, but i dont see another way around it yet. im also modularizing datatable so that navigation/headers are toolbars that can be added or n
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 IDa
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 PRO
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 c
because of this i like to have a some kind of preference.I do want versioning of all my state changes of component (remove/add or visiblitiy that kind of stuff)But i am mostly not interested in versioning model data. Because that is mostly database data anyway (So it is "versionend" in the database
If you want to see the impact of serialization, turn on some debugging info:
log4j.logger.wicket.protocol.http.WebSession=DEBUG
serializes state and dumps results of that just like it would do in a
clustered (with the heaviest variant, HTTP session replication)
environment.
log4j.logger.wicket.v
when a component is versioned and its model is changed it makes a backup of the previous model value by serializing it.in case of the dataview when you change the sort that change is recorded inside the SortableDataProvider which is the model of the dataview. this causes the dataview to make a clon
This came up before when I was trying to track down why reversing the
sort order of a DataView was bringing down my test application.
(http://thread.gmane.org/gmane.comp.java.wicket.user/4309) It turned out
that the page versioning code was serializing the entire view hierarchy,
recursively, be
34 matches
Mail list logo
