Thanks Johan and Eelco,
I'm going to consider the model as opaque as far as change tracking is
concerned. I just want an easy way to track dirty components so looks like
this is the way to go unless it is going away completely. Since so many
methods are final the only options I can think of are polling components for
change, our own build of Wicket, explicit marking or AOP. None of which
sound attractive.
btw Using wicket is so so nice compared to struts etc. Turns out I'm the
weakest link trying to remember how to program in OO ;) Many thanks to you
and the other developers.
Johan Compagner wrote:
>
> a bit more info: in wicket 1.3 (default with SLC) the change objects
> aren't
> really used anymore
> (they are not stored). They only cause an increment of the page version
> number..
>
> johan
>
> On 9/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>>
>> > igor.vaynberg wrote:
>> > >
>> > > On 8/23/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>> > >
>> > >> heh, there is nothing that automatically marks components as dirty()
>> > >> because
>> > >> wicket doesnt know what you do inside your components. wicket is
>> > >> unmanaged.
>> > >
>> > If I do Component.setVersioned(true) and hook in my own
>> IPageVersionManager
>> > won't Wicket effectively track dirty components for me? In a lot of
>> user
>> > interactions very few components will change so presumably using Wicket
>> > component level versioning would be more effecient for us? It won't
>> track
>> > everything but since setEnabled, setVisible etc are final I've not that
>> many
>> > choices...
>>
>> Wicket's change tracking is only done for explicit changes though. For
>> instance:
>>
>> private class CurrentPageChange extends Change {
>> private final int currentPage;
>>
>> CurrentPageChange(int currentPage) {
>> this.currentPage = currentPage;
>> }
>>
>> public void undo() {
>> setCurrentPage(currentPage);
>> }
>> }
>>
>> ...
>> addStateChange(new CurrentPageChange(this.currentPage));
>>
>>
>> You can definitively use this for your own purposes. However, I would
>> think that the typical thing *you* want to react on are model changes.
>> You can use this mechanism for it as well, but it might be heavier
>> than you'd like.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12473771
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
