consider also this possibility: you will end up with a new component
hierarchy on every request anyway (unless matej has been doing something
very clever).  and with the right caching in place (ORM and/or DB level),
the serialization overhead associated with your attempt at premature
optimization by using non-detachable models may actually turn out to be far
MORE expensive than "hitting the db" (which ought to be a map look up by id
when you've got a cache hit).  furthermore, you will increase your network
traffic under clustering this way.  and on top of it all, you'll wind up
with stale data problems.

can anyone think of an upside to avoiding detachable models?  cause i can't.


Jonathan Locke wrote:
> 
> 
> oh, okay.  sorry, i was speed-reading your question and misunderstood it.  
> 
> maurice and johan are correct that hybrid urls will avoid creating the
> instance.  the part i mistakenly assumed we were talking about was whether
> one can completely avoid creating a new version of the page in the page
> store during rendering.  maybe matej can verify this, but i don't think
> that is possible anymore.  wicket requests can dynamically modify the
> component hierarchy and with the new disk page store, i think you always
> end up with a new page version.  so when you hit a hybrid url and a new
> page version is created and that number at the end of the url changes
> (which i'm assuming you are assuming is a new page), that doesn't mean a
> new page was constructed (set a breakpoint in your constructor and verify
> for yourself).  it merely means that the existing page was mutated.  is
> that where your confusion is coming from?
> 
> btw, i still think you are making a big mistake if you're avoiding
> detachable models.  detachable models are the best practice.  you should
> add a database cache to make them efficient, not try to work around them. 
> early on i tried to avoid them at first and discovered dozens of ways to
> get bit by that.  don't prematurely optimize your app.  build it the right
> way first and then look at your hot spots.
> 
> 
> Jonathan Locke wrote:
>> 
>> 
>> okay, so i think the answer to your question is no, you can't optimize
>> that. you should be using detachable models and an OTS db cache. 
>> 
>> what i don't understand is why you want to do this.  if the user hits
>> refresh in their browser they are hoping to see updated data. why do you
>> want to turn that into a no-op?
>> 
>> 
>> mfs wrote:
>>> 
>>> I have the condensed version of the code here, with some comments on the
>>> top of each class..
>>> 
>>> http://papernapkin.org/pastebin/view/788/
>>> 
>>> Waiting for follow up
>>> 
>>> 
>>> Jonathan Locke wrote:
>>>> 
>>>> 
>>>> you must be making some mistake (probably conceptual).  can you create
>>>> a quickstart example of your problem and post it at some link where we
>>>> can see exactly what you're doing?
>>>> 
>>>> 
>>>> mfs wrote:
>>>>> 
>>>>> Well actually before posting this up, i did try this i.e. mounted the
>>>>> page using hybridurlcodingstrategy (with the assumption that since the
>>>>> pageId is there in the url doing a refresh would load the already
>>>>> instantiated page against the id) but at that time i had the page as
>>>>> bookmarkable (i.e. had public default and param constructors), so
>>>>> after reading maurice's post, i made it a non-bookmarkable one (by
>>>>> making both the constructors as protected) but unfortunately it still
>>>>> doesnt work, doing a refresh i still see the updated model..to be
>>>>> precise i am using a DataView which is a IDataProvider and am using
>>>>> non-detachable models.
>>>>> 
>>>>> Thanks for the follow up..
>>>>> 
>>>>> 
>>>>> 
>>>>> Johan Compagner wrote:
>>>>>> 
>>>>>> HybridUrlEnoding
>>>>>> 
>>>>>> On Sun, May 11, 2008 at 9:04 AM, mfs <[EMAIL PROTECTED]> wrote:
>>>>>> 
>>>>>>>
>>>>>>> Guys,
>>>>>>>
>>>>>>> Firstly, Is that a right understanding that doing a browser-refresh
>>>>>>> of the
>>>>>>> page would result in a new instance of the page being created
>>>>>>> everytime and
>>>>>>> similarly a new model instance would be binded to the page.
>>>>>>>
>>>>>>> Is there a way one can use the same version of the page/model (which
>>>>>>> wicket
>>>>>>> kept in the session) when the page was rendered the first time..
>>>>>>>
>>>>>>> I would want to avoid a hit to the database on refresh (since my
>>>>>>> model
>>>>>>> construction requires so)
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Load-serialized-%28or-in-session%29-page-model-on-refresh..-tp17170105p17170105.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>
>>>>>>>
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Load-serialized-%28or-in-session%29-page-model-on-refresh..-tp17170105p17181371.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to