Johan Compagner wrote:
If they are not detachable then they are serializeable ..............
That is the whole point!
If they aren't then clustering doesn't work, The webcontainer can't store the session to disk. Look at the logging of tomcat and you will see lots of errors in the log...
And again make it an option that is default off then i don't see a problem.
so they're serializable. and this whole problem gets a lot more thorny.
what if they're serializable because wicket is being used in some huge enterprise app where there's a whole tier of servers that just edit beans and aren't even connected to the database?
i'm not arguing that we never do this feature. only that we not do it for 1.0 and that we really think through what we're doing for 1.1.
cloning models is going to be hell for some users. we want to make sure that the API pushes them in the right direction and that our solution is as automatic and pain-free as possible.
obviously. but again, what if the user has a regular old bean that's not detachable?
Then that bean (and beans are) must be serializeable,
Again this is a requirement, not by wicket but by a webcontainer.
The webcontainer can also do these things.
For example if a session is not used for a while it could dump it to disk, And when it is suddenly needed again it will it read in.
These are the things a webcontainer can do.
yes, i know. but users still may have legitimate reasons to use non-detachable objects. and then we have some serious model cloning issues. we need to step back and think about this for a while. is there anything we can do to make wicket work better with cloning non-detachable models?
also, detaching a model like the code below could be really expensive because reattaching might involve a database query, for example. should we even detach the model? if we don't is hibernate going to be happy? i suspect the answer is that we don't need to do the detach, actually. isn't hibernate designed to deal with this?
We need to detach. There is no other way. Because only deattached models are ready for serialization.
actually, you /can/ serialize non-detachable models.
No. Because we can't require that from a user. That is the whole point of detachable models. They are serializeable in a detached state but
doesn't have to be in a attached state.
the user may want or need to do this. they've got a bean they want to send off to a whole tier of web servers to edit. when it comes back they want to edit their database with that bean.
also, btw, the world is not hibernate. we need to look into jdo and other persistence solutions and make sure we understand how wicket might work with them.
i don't find stale pages acceptable in anycase. Can never happen. Should never happen. back buttons should always work work (2 deep not much more)
I currently never call invalidateModel..(now called modelChanged) Becaus that makes the page stale.. unacceptable.
but stale pages /do/ happen. if you delete the only row from a list of fields and then hit back, the model is now an empty list. what is that previous page supposed to do when you hit back, edit the field and submit your change? there's no entry in the model to edit. the page is stale because the model changed.
one way you could fix this would be by not having detachable models! then each page has its own independent model. when you hit back, you'd go back to a page editing the model that was attached to that page. i'm not suggesting this is the right thing, but it would "solve" the problem.
No not stale in my eyes
The page should still work. Only the click on the link that is deleted would throw an error. A click on a link below it should do the job just fine.
But i know this is pretty hard. But thats what people are used to.
you missed my point. it's not a link. it's a textfield. and there's only one. the user goes back to the page with the textfield /that is no longer attached to any model!!!/. when they submit their change, the list is empty []. what are you going to do other than say "the page is stale" in some way?
this is a fundamental problem with browsers and back buttons that isn't going away and wicket solves this problem. as i mentioned in an earlier email to someone else, we can do a better job of marking pages stale (right now we're marking more pages stale than need to be), but the pages really /are/ stale because the markup no longer matches the model that the markup wants to edit.
if you've got multiple rows like you're suggesting, you've got the same potential for damage. even if you sort the rows, you do. because the model and the page markup don't match and the page markup contains a mutator.
i really think we can solve this staleness problem even better than it has been. the easy case you just mentioned (when you changed the problem to a list of links) can work because the link isn't a mutating component. we can detect this situation on a form-by-form basis and decide if the page is actually invalid.
this, btw, would be a huge advantage over what i understand about tapestry.
detachable models are essentially shared because they are backed by some store like a db. if you have detachable models, you have stale pages because the state is shared! when one page changes the state, the other pages have to go stale. this is what tapestry does and it's what we have in wicket now.
like it or not, stale pages are a fact of life if you're in a multi-user environment or you have shared models like detachable models.
The problem is that yes the row that is deleted that link that is stale
The rest should work in my eyes. Why does this work when for example using struts? (i know why)
But this is also doable in wicket. It is just how you design youre ListView. (and not calling modelChanged())
no. you /do/ call modelStructureChanged(). wicket just needs to be smarter about staleness detection. for each form, we look at models that changed on that form and determine if any mutators are involved.
We should really strive for 100% back button prove in every possible way.
agree that back button should work as much as possible. but it can't always work because the structure of the old page may no longer match the structure of the model it's editing. at some point, you have to give up and show the user an error.
as i said just a matter of design.
nope. it simply cannot work in some cases.
For example you delete:
I have a list with 10 values
Then I Don't delete one of them but i click on 7.
I get an error because object is deleted because anohter users already deleted that object under my noise.
So the page was already stale in youre eyes even i didn't do anything , i just rendered it.
again, this component is not a mutator. the problem of staleness has to do with components that /edit data/. we need to examine if/how we can close down the scope of staleness detection so it doesn't include harmlessly stale data.
So i find staleness with delete examples not relevant You need to do this youre self anyway on those kind of lists.
Because they could be changed/deleted by from any other place anyway.
So i hope you get my point a bit. Staleness is a fact of live you it can happen at any time in any place even without youre doing
right after you rendered youre page. So the developer should take that into account when designing the pages.
So no i still don't like setting pages to stale. I don't want that to happen.
it's true that the model may no longer match the db. but that's true in every case. and hibernate detects that. this is a completely different problem. remember, wicket is not only about hibernate. it needs to detect stale pages. when the model matches the page, wicket can update the model. but then what you do with that model is up to you.
By the way i find modelChanged behaviour very strange by the way. In my swing experience this will not 'destroy' the components
but let the components know that they should reaquire the model for its data because the model's data is changed.
I would prefer to rename that method to what it really does: setPageState(); (or something like that)
what the component /does/ on modelChanged is an implementation detail of the component. the method is named based on is use not its implementation. i think it's aptly named.
yes i know but by default it sets the staleness.
no. it does not. it just does that /now/. i expect the implementation in the future to be smarter and /sometimes/ set the staleness.
how change unexcepectedly? that shouldn't happen: model.deatach() model.atach() model should be completely equal then right before detach().
some other thread/session can modify the database. i'm just pointing out that detach() opens a window of opportunity for these errors to come up. i think it's a problem regardless though since we always detach() at the end of rendering so session sync can be lighter weight. so it's a problem, but not anything we can fix generically.
You should always use the latest object from the database.
So the attach is a much better way anyway, because holding hibernate references over multipply request is a bad thing anyway, because they aren't attached anymore to a transaction.
And for models that just has an id stored this is not relevant at all. (just the same hibernate object but then completely fresh again is queried)
I agree for list. Those suddenly can have another entry (or lost an entry) a slightly different order ect..
But replace/removeall are called in the 'action' fase, not in the rendering.
So developers should just take this into account.
I think that if you have a link to set another tab. That almost all the models are still detached. Because in the component listener fase i don't think the data is asked from the models.
It is another store by remove all. But then the models should be required anyhow..
It will only happen once in a request.. Never anymore.
So if somehow 2 times in a same request a tabpanel is reset or removeALL is called then only the first time the 'clone' is happening.
right. because of the render count reset, right?
yes
Of course we could drop down the wantPageCloned to Page that is just fine.
but isn't it the component that wants the page cloned?
not it is the developer ;) The container is the trigger of the clone/copy Because a container has the 2 methods: removeAll and replace..
finally, maybe we should consider keeping the current stale-detection functionality via an ApplicationSetting and have the option default to this (hopefully) idiot-proof transparent copying thing... that way things work more often, but users who would rather not pay the cost of serialization OR deal with pagefactory could get the current functionality. i think this might be worth saving. we may get a lot of criticism over the performance of cloning via serialization.
one thing more.thoughts? replies?
I am searching for a better serialization for use in the same JVM. It must be much faster if the ObjectOutputstream knows that it doesn't have to store any class meta data ect.
that it only have to dump the instance data nothing more.
Anybody knows a bit optimized java serialization implementation?
i'm not sure i understand. what's an example of class meta data that's being written out by serialization that you could omit? what would you write out in its place?
i think serialization is pretty much going to be greviously slow. if there was a way to make it significantly faster, wouldn't someone have done that already?
read this:
http://www.javaworld.com/javaworld/javaqa/2003-01/02-qa-0124-clone-p3.html
quote:
"What's even worse, |ObjectOutputStream| and |ObjectInputStream| perform a lot of unnecessary work. For example, writing out class metadata (class name, field names, metadata checksum, etc.) that may need to be reconciled with a different class version on the receiving end is pure overhead when you serialize a class within the same |ClassLoader| namespace."
i don't see how this would work even in the same classloader. you've collapsed the object graph to a bunch of bytes in any case. it might as well be on another server or the moon. what are you going to do, store a reference in the byte array? the GC will move your class object!
and in any case, i'm not aware of any way to improve OIS. it's involved in a lot of language internals and does not appear to be designed for easy/reasonable extension in this way.
And we don't need that also. We just need the simplest dump of the fields.
If pages/components/models wheren't being extened ;) it would be much easier to gain speed, just use Externalizeable.....
johan
------------------------------------------------------- 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
