You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Hough <sa...@redspr.com> on 2007/09/11 11:01:06 UTC
auto dirty and widget factory
Apologies in advance as I'm a newbie harking on about my pet topic again
but...
Taking the example of TabbedPanel and AjaxTabbedPanel (only in extensions
but a common UI concept) I think it shows why it would be good to use the
factory pattern to generate elemental widgets (like button, panel etc
assuming people want AjaxFallbackButton or Button) and automatically track
dirty components.
I first got this bee in my bonnet about higher level application code
because I didn't think I should be messing about working out which
components were dirty when I just want the result of pressing a button to
fiddle with the model and change the ui state a bit. However looking at
*TabbedPanel I think it would also make sense for pure UI components. Using
inheritance to add Ajax to TabbedPanel means any other variations also have
to be doubled (e.g. AjaxFancyTabbedPanel and FancyTabbedPanel etc). Perhaps
the bigger problem is that if a Panel that is meant to be inside a
TabbedPanel and needs to alter another component (e.g. update navigation
component) the TabbedPanel has to ask it for changes. Presumably a component
should be self contained as possible so it doesn't matter what other
component it is contained within.
Factory pattern is a pain but presumably many people don't want the overhead
of AjaxFallbackXXX. It would also make it possible to program against
interfaces which might give more power to Igor, Eelco etc
Please don't get me wrong GWT is still my true love but Wicket is a fabulous
framework taking us out of the dark ages of struts.
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12610663
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
http://wicket.apache.org/vision.html
http://cwiki.apache.org/WICKET/faqs.html#FAQs-Whyaresomanymethodsfinal%253F
Martijn
On 9/27/07, Sam Hough <sa...@redspr.com> wrote:
>
> Is this coding style documented anywhere? I have a vague memory that spring
> pushes towards composition not extension but that is obviously not the
> wicket way.
>
> Did the people behind javax.swing, java.util make a mistake being light with
> final or is their task different?
>
> The Lucene people seem to make classes final presumably because extension is
> not meant to be done at all.
>
>
>
>
> Eelco Hillenius wrote:
> >
> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> but this discussion is not just about getter/setters (i don't care about
> >> those)
> >> but also for add and remove.. then we are getting into some other stuff
> >
> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > in sweat when I imagine removing final on add and remove.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917546
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Is this coding style documented anywhere? I have a vague memory that spring
pushes towards composition not extension but that is obviously not the
wicket way.
Did the people behind javax.swing, java.util make a mistake being light with
final or is their task different?
The Lucene people seem to make classes final presumably because extension is
not meant to be done at all.
Eelco Hillenius wrote:
>
> On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> but this discussion is not just about getter/setters (i don't care about
>> those)
>> but also for add and remove.. then we are getting into some other stuff
>
> Yes. Getters/ setters are less tricky. Though I'm still not breaking
> in sweat when I imagine removing final on add and remove.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917546
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't locate an image file...
Posted by "Neil B. Cohen" <nc...@verisign.com>.
Martijn Dashorst wrote:
> You need to tell wicket to search for the image. So you have to either:
>
> 1. add an Image component to the signin page/panel
> 2. surround (at least) the img tag with <wicket:link></wicket:link>
>
> Otherwise WIcket will not know that it should look for the image on
> the classpath.
>
>
Got it - I added an Image component in the java file and that worked.
Thanks!
nbc
> Martijn
>
> On 10/1/07, Neil B. Cohen <nc...@verisign.com> wrote:
>
>> I am experimenting with the simplest of the Wicket examples. I was
>> trying to add an image to the SignIn
>> example page. My html code looks like this:
>>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>> <html xmlns:wicket="http://wicket.apache.org/"><head><title>Wicket
>> Examples - si
>> gnin</title>
>>
>> <link rel="stylesheet" type="text/css" href="style.css">
>> </head>
>> <body style="color: rgb(0, 0, 0); background-color: silver;"
>> alink="#000099" lin
>> k="#000099" vlink="#990099">
>> <br>
>> <span wicket:id="feedback"> <br>
>> </span>
>> <br>
>> <img style="width: 96px; height: 42px;" alt="" src="My_logo.gif">
>> < <<**** New image added...
>> big><big><span style="font-weight: bold; font-style: italic;">Program
>> Title...</
>> span></big></big><br>
>> <br>
>> <form wicket:id="signInForm">
>> <table>
>> ..... rest of the signin.html code is unchanged...
>>
>> When I load the war file, the image does not show - there is a box where
>> it should be, followed by the
>> 'Program Title' text. I put the My_logo.gif file in the same directory
>> as the SignIn.java/SignIn.html files.
>>
>> Questions:
>> 1) Do I need to put something in the SignIn.java file to tell it to load
>> the image?
>>
>> 2) Do I need to add something to a config file somewhere to tell it
>> where to locate the image file? Do the image files have to be in the
>> same src directory as the html/java files or can they be moved somewhere
>> else (like src/images for example)?
>>
>> Thanks very much,
>>
>> nbc
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't locate an image file...
Posted by Martijn Dashorst <ma...@gmail.com>.
You need to tell wicket to search for the image. So you have to either:
1. add an Image component to the signin page/panel
2. surround (at least) the img tag with <wicket:link></wicket:link>
Otherwise WIcket will not know that it should look for the image on
the classpath.
Martijn
On 10/1/07, Neil B. Cohen <nc...@verisign.com> wrote:
> I am experimenting with the simplest of the Wicket examples. I was
> trying to add an image to the SignIn
> example page. My html code looks like this:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html xmlns:wicket="http://wicket.apache.org/"><head><title>Wicket
> Examples - si
> gnin</title>
>
> <link rel="stylesheet" type="text/css" href="style.css">
> </head>
> <body style="color: rgb(0, 0, 0); background-color: silver;"
> alink="#000099" lin
> k="#000099" vlink="#990099">
> <br>
> <span wicket:id="feedback"> <br>
> </span>
> <br>
> <img style="width: 96px; height: 42px;" alt="" src="My_logo.gif">
> < <<**** New image added...
> big><big><span style="font-weight: bold; font-style: italic;">Program
> Title...</
> span></big></big><br>
> <br>
> <form wicket:id="signInForm">
> <table>
> ..... rest of the signin.html code is unchanged...
>
> When I load the war file, the image does not show - there is a box where
> it should be, followed by the
> 'Program Title' text. I put the My_logo.gif file in the same directory
> as the SignIn.java/SignIn.html files.
>
> Questions:
> 1) Do I need to put something in the SignIn.java file to tell it to load
> the image?
>
> 2) Do I need to add something to a config file somewhere to tell it
> where to locate the image file? Do the image files have to be in the
> same src directory as the html/java files or can they be moved somewhere
> else (like src/images for example)?
>
> Thanks very much,
>
> nbc
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Can't locate an image file...
Posted by "Neil B. Cohen" <nc...@verisign.com>.
I am experimenting with the simplest of the Wicket examples. I was
trying to add an image to the SignIn
example page. My html code looks like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:wicket="http://wicket.apache.org/"><head><title>Wicket
Examples - si
gnin</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body style="color: rgb(0, 0, 0); background-color: silver;"
alink="#000099" lin
k="#000099" vlink="#990099">
<br>
<span wicket:id="feedback"> <br>
</span>
<br>
<img style="width: 96px; height: 42px;" alt="" src="My_logo.gif">
< <<**** New image added...
big><big><span style="font-weight: bold; font-style: italic;">Program
Title...</
span></big></big><br>
<br>
<form wicket:id="signInForm">
<table>
..... rest of the signin.html code is unchanged...
When I load the war file, the image does not show - there is a box where
it should be, followed by the
'Program Title' text. I put the My_logo.gif file in the same directory
as the SignIn.java/SignIn.html files.
Questions:
1) Do I need to put something in the SignIn.java file to tell it to load
the image?
2) Do I need to add something to a config file somewhere to tell it
where to locate the image file? Do the image files have to be in the
same src directory as the html/java files or can they be moved somewhere
else (like src/images for example)?
Thanks very much,
nbc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Eelco Hillenius <ee...@gmail.com>.
On 10/1/07, Sam Hough <sa...@redspr.com> wrote:
>
> Are Component.onAttach and onDetach legitimate places for customising wicket
> behaviour?
Yep.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Are Component.onAttach and onDetach legitimate places for customising wicket
behaviour?
Johan Compagner wrote:
>
> i think thatwe will change the interface of the change tracker but we
> will keep it at some level for page versions (and abusing dirty() for
> that doesn't have my vote) But something like:
> Page.componentChanged(Component) looks nice to me and then auto dirty
> of components is also possible
>
> On 9/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> The jury is still out on the change tracker. It will at least be part
>> of Wicket 1.3 and our JDK 1.5 release, as that one should only be
>> about generics (at least that is still the plan). So it will be there
>> for at least 1.3 and the next one.
>>
>> If your application is still dependent on that functionality, then
>> raise the concern when we are going to remove it. If we have usecases
>> for a particular functionality, then we are not going to remove it on
>> a whim. According to this thread, at least Johan is quite keen to keep
>> it in place :)
>>
>> Please note also that maybe in the version after the generics version,
>> we may come up with a way to do what you want, and provide that
>> functionality out-of-the-box. But currently we are trying to finalize
>> a release and ship it.
>>
>> Martijn
>>
>> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>> >
>> > I would be happy with a 90% solution that was very simple and that was
>> what I
>> > was after. Something like the change tracker would be lovely but it
>> seems
>> in
>> > doubt if that will even exist for long. I won't raise this issue again.
>> >
>> > Thanks for your time.
>> >
>> >
>> > Johan Compagner wrote:
>> > >
>> > > i have told you now i think at least 3 times
>> > > only be able to override those methods WONT i repeat again WONT help
>> you
>> > > completely
>> > > those are not the only events that could get a component to be dirty.
>> > > there are lots more especially when you also take into account the
>> none
>> > > core
>> > > stuff.
>> > >
>> > > Something like the change tracker is the way to go.
>> > >
>> > >
>> > > johan
>> > >
>> > >
>> > >
>> > > On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>> > >>
>> > >>
>> > >> Errr. Should I take from all this not to use the page versioning and
>> that
>> > >> I
>> > >> shouldn't hold my breath for final being removed from anywhere?
>> > >>
>> > >> I know you are all sick of this topic, poor old Eelco, but seems
>> like a
>> > >> simple, efficient and flexible way for me to add hooks is to extend
>> > >> objects.
>> > >> If you mark methods as "extend at own risk" and I go down a stupid
>> route
>> > >> that is my own stupidity. At least I can get something reasonable
>> working
>> > >> in
>> > >> the short term even if it can be done better later. I'm a good boy
>> so I
>> > >> have
>> > >> lots of unit and functional tests to catch mistakes later.
>> > >>
>> > >> Sorry that I'm struggling with the wicket way. To add to my
>> confusion
>> I'd
>> > >> rather onClick, onSubmit etc were interfaces so I could choose if I
>> > >> wanted
>> > >> them in the component (to reduce numbers of objects) or anywhere I
>> like.
>> > >>
>> > >>
>> > >> Matej Knopp-2 wrote:
>> > >> >
>> > >> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
>> > >> >> the problem is that that still not really does auto dirty..
>> > >> >> Because where does it end? just add/remove/visitble/enable?
>> > >> >> The nice thing is we have already something like that: thats page
>> > >> >> versioning
>> > >> >> with the undo/change map.
>> > >> > Don't get too attached to it :) We should remove it in the next
>> > >> > version, doesn't make much sense for 2nd level cache session store
>> :)
>> > >> >
>> > >> > -Matej
>> > >> >
>> > >> >> If we extend that a little bit then we could have something like
>> > >> >> componentChanged(component) on a page (or somekind of listener)
>> > >> >> and that component did trigger it self what ever did happen on it
>> > >> >> (getting a
>> > >> >> child, settting the visibility, or setting an internal none
>> wicket
>> > >> core
>> > >> >> property)
>> > >> >>
>> > >> >> johan
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> > >> >> >
>> > >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> > >> >> > > but this discussion is not just about getter/setters (i don't
>> care
>> > >> >> about
>> > >> >> > > those)
>> > >> >> > > but also for add and remove.. then we are getting into some
>> other
>> > >> >> stuff
>> > >> >> >
>> > >> >> > Yes. Getters/ setters are less tricky. Though I'm still not
>> breaking
>> > >> >> > in sweat when I imagine removing final on add and remove.
>> > >> >> >
>> > >> >> > Eelco
>> > >> >> >
>> > >> >> >
>> > >>
>> ---------------------------------------------------------------------
>> > >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> View this message in context:
>> > >>
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
>> > >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> > >>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > --
>> > View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648
>> > Sent from the Wicket - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>> --
>> Buy Wicket in Action: http://manning.com/dashorst
>> Apache Wicket 1.3.0-beta3 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12977670
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Can I use:
Component.checkHierarchyChange(final Component c)
or should that really have been marked final?
On the "what if they don't call super". Has anybody seen anywhere some
annotation that insists that people who override that method call super?
Seems like a common problem. I have often spent time wondering why my
servlet wasn't getting config because I was stupid... @Override is really
nice but maybe need an annotation for super class method? e.g.
@MustCallSuper
Johan Compagner wrote:
>
> i think thatwe will change the interface of the change tracker but we
> will keep it at some level for page versions (and abusing dirty() for
> that doesn't have my vote) But something like:
> Page.componentChanged(Component) looks nice to me and then auto dirty
> of components is also possible
>
> On 9/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> The jury is still out on the change tracker. It will at least be part
>> of Wicket 1.3 and our JDK 1.5 release, as that one should only be
>> about generics (at least that is still the plan). So it will be there
>> for at least 1.3 and the next one.
>>
>> If your application is still dependent on that functionality, then
>> raise the concern when we are going to remove it. If we have usecases
>> for a particular functionality, then we are not going to remove it on
>> a whim. According to this thread, at least Johan is quite keen to keep
>> it in place :)
>>
>> Please note also that maybe in the version after the generics version,
>> we may come up with a way to do what you want, and provide that
>> functionality out-of-the-box. But currently we are trying to finalize
>> a release and ship it.
>>
>> Martijn
>>
>> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>> >
>> > I would be happy with a 90% solution that was very simple and that was
>> what I
>> > was after. Something like the change tracker would be lovely but it
>> seems
>> in
>> > doubt if that will even exist for long. I won't raise this issue again.
>> >
>> > Thanks for your time.
>> >
>> >
>> > Johan Compagner wrote:
>> > >
>> > > i have told you now i think at least 3 times
>> > > only be able to override those methods WONT i repeat again WONT help
>> you
>> > > completely
>> > > those are not the only events that could get a component to be dirty.
>> > > there are lots more especially when you also take into account the
>> none
>> > > core
>> > > stuff.
>> > >
>> > > Something like the change tracker is the way to go.
>> > >
>> > >
>> > > johan
>> > >
>> > >
>> > >
>> > > On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>> > >>
>> > >>
>> > >> Errr. Should I take from all this not to use the page versioning and
>> that
>> > >> I
>> > >> shouldn't hold my breath for final being removed from anywhere?
>> > >>
>> > >> I know you are all sick of this topic, poor old Eelco, but seems
>> like a
>> > >> simple, efficient and flexible way for me to add hooks is to extend
>> > >> objects.
>> > >> If you mark methods as "extend at own risk" and I go down a stupid
>> route
>> > >> that is my own stupidity. At least I can get something reasonable
>> working
>> > >> in
>> > >> the short term even if it can be done better later. I'm a good boy
>> so I
>> > >> have
>> > >> lots of unit and functional tests to catch mistakes later.
>> > >>
>> > >> Sorry that I'm struggling with the wicket way. To add to my
>> confusion
>> I'd
>> > >> rather onClick, onSubmit etc were interfaces so I could choose if I
>> > >> wanted
>> > >> them in the component (to reduce numbers of objects) or anywhere I
>> like.
>> > >>
>> > >>
>> > >> Matej Knopp-2 wrote:
>> > >> >
>> > >> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
>> > >> >> the problem is that that still not really does auto dirty..
>> > >> >> Because where does it end? just add/remove/visitble/enable?
>> > >> >> The nice thing is we have already something like that: thats page
>> > >> >> versioning
>> > >> >> with the undo/change map.
>> > >> > Don't get too attached to it :) We should remove it in the next
>> > >> > version, doesn't make much sense for 2nd level cache session store
>> :)
>> > >> >
>> > >> > -Matej
>> > >> >
>> > >> >> If we extend that a little bit then we could have something like
>> > >> >> componentChanged(component) on a page (or somekind of listener)
>> > >> >> and that component did trigger it self what ever did happen on it
>> > >> >> (getting a
>> > >> >> child, settting the visibility, or setting an internal none
>> wicket
>> > >> core
>> > >> >> property)
>> > >> >>
>> > >> >> johan
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> > >> >> >
>> > >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> > >> >> > > but this discussion is not just about getter/setters (i don't
>> care
>> > >> >> about
>> > >> >> > > those)
>> > >> >> > > but also for add and remove.. then we are getting into some
>> other
>> > >> >> stuff
>> > >> >> >
>> > >> >> > Yes. Getters/ setters are less tricky. Though I'm still not
>> breaking
>> > >> >> > in sweat when I imagine removing final on add and remove.
>> > >> >> >
>> > >> >> > Eelco
>> > >> >> >
>> > >> >> >
>> > >>
>> ---------------------------------------------------------------------
>> > >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> View this message in context:
>> > >>
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
>> > >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> > >>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > --
>> > View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648
>> > Sent from the Wicket - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>> --
>> Buy Wicket in Action: http://manning.com/dashorst
>> Apache Wicket 1.3.0-beta3 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12977564
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
i think thatwe will change the interface of the change tracker but we
will keep it at some level for page versions (and abusing dirty() for
that doesn't have my vote) But something like:
Page.componentChanged(Component) looks nice to me and then auto dirty
of components is also possible
On 9/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
> The jury is still out on the change tracker. It will at least be part
> of Wicket 1.3 and our JDK 1.5 release, as that one should only be
> about generics (at least that is still the plan). So it will be there
> for at least 1.3 and the next one.
>
> If your application is still dependent on that functionality, then
> raise the concern when we are going to remove it. If we have usecases
> for a particular functionality, then we are not going to remove it on
> a whim. According to this thread, at least Johan is quite keen to keep
> it in place :)
>
> Please note also that maybe in the version after the generics version,
> we may come up with a way to do what you want, and provide that
> functionality out-of-the-box. But currently we are trying to finalize
> a release and ship it.
>
> Martijn
>
> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
> >
> > I would be happy with a 90% solution that was very simple and that was
> what I
> > was after. Something like the change tracker would be lovely but it seems
> in
> > doubt if that will even exist for long. I won't raise this issue again.
> >
> > Thanks for your time.
> >
> >
> > Johan Compagner wrote:
> > >
> > > i have told you now i think at least 3 times
> > > only be able to override those methods WONT i repeat again WONT help you
> > > completely
> > > those are not the only events that could get a component to be dirty.
> > > there are lots more especially when you also take into account the none
> > > core
> > > stuff.
> > >
> > > Something like the change tracker is the way to go.
> > >
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
> > >>
> > >>
> > >> Errr. Should I take from all this not to use the page versioning and
> that
> > >> I
> > >> shouldn't hold my breath for final being removed from anywhere?
> > >>
> > >> I know you are all sick of this topic, poor old Eelco, but seems like a
> > >> simple, efficient and flexible way for me to add hooks is to extend
> > >> objects.
> > >> If you mark methods as "extend at own risk" and I go down a stupid
> route
> > >> that is my own stupidity. At least I can get something reasonable
> working
> > >> in
> > >> the short term even if it can be done better later. I'm a good boy so I
> > >> have
> > >> lots of unit and functional tests to catch mistakes later.
> > >>
> > >> Sorry that I'm struggling with the wicket way. To add to my confusion
> I'd
> > >> rather onClick, onSubmit etc were interfaces so I could choose if I
> > >> wanted
> > >> them in the component (to reduce numbers of objects) or anywhere I
> like.
> > >>
> > >>
> > >> Matej Knopp-2 wrote:
> > >> >
> > >> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > >> >> the problem is that that still not really does auto dirty..
> > >> >> Because where does it end? just add/remove/visitble/enable?
> > >> >> The nice thing is we have already something like that: thats page
> > >> >> versioning
> > >> >> with the undo/change map.
> > >> > Don't get too attached to it :) We should remove it in the next
> > >> > version, doesn't make much sense for 2nd level cache session store :)
> > >> >
> > >> > -Matej
> > >> >
> > >> >> If we extend that a little bit then we could have something like
> > >> >> componentChanged(component) on a page (or somekind of listener)
> > >> >> and that component did trigger it self what ever did happen on it
> > >> >> (getting a
> > >> >> child, settting the visibility, or setting an internal none wicket
> > >> core
> > >> >> property)
> > >> >>
> > >> >> johan
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >> >> >
> > >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > >> >> > > but this discussion is not just about getter/setters (i don't
> care
> > >> >> about
> > >> >> > > those)
> > >> >> > > but also for add and remove.. then we are getting into some
> other
> > >> >> stuff
> > >> >> >
> > >> >> > Yes. Getters/ setters are less tricky. Though I'm still not
> breaking
> > >> >> > in sweat when I imagine removing final on add and remove.
> > >> >> >
> > >> >> > Eelco
> > >> >> >
> > >> >> >
> > >> ---------------------------------------------------------------------
> > >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> >
> > >> >
> > >> >
> > >>
> > >> --
> > >> View this message in context:
> > >>
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
> > >> Sent from the Wicket - User mailing list archive at Nabble.com.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
The jury is still out on the change tracker. It will at least be part
of Wicket 1.3 and our JDK 1.5 release, as that one should only be
about generics (at least that is still the plan). So it will be there
for at least 1.3 and the next one.
If your application is still dependent on that functionality, then
raise the concern when we are going to remove it. If we have usecases
for a particular functionality, then we are not going to remove it on
a whim. According to this thread, at least Johan is quite keen to keep
it in place :)
Please note also that maybe in the version after the generics version,
we may come up with a way to do what you want, and provide that
functionality out-of-the-box. But currently we are trying to finalize
a release and ship it.
Martijn
On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>
> I would be happy with a 90% solution that was very simple and that was what I
> was after. Something like the change tracker would be lovely but it seems in
> doubt if that will even exist for long. I won't raise this issue again.
>
> Thanks for your time.
>
>
> Johan Compagner wrote:
> >
> > i have told you now i think at least 3 times
> > only be able to override those methods WONT i repeat again WONT help you
> > completely
> > those are not the only events that could get a component to be dirty.
> > there are lots more especially when you also take into account the none
> > core
> > stuff.
> >
> > Something like the change tracker is the way to go.
> >
> >
> > johan
> >
> >
> >
> > On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >>
> >> Errr. Should I take from all this not to use the page versioning and that
> >> I
> >> shouldn't hold my breath for final being removed from anywhere?
> >>
> >> I know you are all sick of this topic, poor old Eelco, but seems like a
> >> simple, efficient and flexible way for me to add hooks is to extend
> >> objects.
> >> If you mark methods as "extend at own risk" and I go down a stupid route
> >> that is my own stupidity. At least I can get something reasonable working
> >> in
> >> the short term even if it can be done better later. I'm a good boy so I
> >> have
> >> lots of unit and functional tests to catch mistakes later.
> >>
> >> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
> >> rather onClick, onSubmit etc were interfaces so I could choose if I
> >> wanted
> >> them in the component (to reduce numbers of objects) or anywhere I like.
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> >> >> the problem is that that still not really does auto dirty..
> >> >> Because where does it end? just add/remove/visitble/enable?
> >> >> The nice thing is we have already something like that: thats page
> >> >> versioning
> >> >> with the undo/change map.
> >> > Don't get too attached to it :) We should remove it in the next
> >> > version, doesn't make much sense for 2nd level cache session store :)
> >> >
> >> > -Matej
> >> >
> >> >> If we extend that a little bit then we could have something like
> >> >> componentChanged(component) on a page (or somekind of listener)
> >> >> and that component did trigger it self what ever did happen on it
> >> >> (getting a
> >> >> child, settting the visibility, or setting an internal none wicket
> >> core
> >> >> property)
> >> >>
> >> >> johan
> >> >>
> >> >>
> >> >>
> >> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >> >> >
> >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> >> > > but this discussion is not just about getter/setters (i don't care
> >> >> about
> >> >> > > those)
> >> >> > > but also for add and remove.. then we are getting into some other
> >> >> stuff
> >> >> >
> >> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> >> >> > in sweat when I imagine removing final on add and remove.
> >> >> >
> >> >> > Eelco
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
I would be happy with a 90% solution that was very simple and that was what I
was after. Something like the change tracker would be lovely but it seems in
doubt if that will even exist for long. I won't raise this issue again.
Thanks for your time.
Johan Compagner wrote:
>
> i have told you now i think at least 3 times
> only be able to override those methods WONT i repeat again WONT help you
> completely
> those are not the only events that could get a component to be dirty.
> there are lots more especially when you also take into account the none
> core
> stuff.
>
> Something like the change tracker is the way to go.
>
>
> johan
>
>
>
> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Errr. Should I take from all this not to use the page versioning and that
>> I
>> shouldn't hold my breath for final being removed from anywhere?
>>
>> I know you are all sick of this topic, poor old Eelco, but seems like a
>> simple, efficient and flexible way for me to add hooks is to extend
>> objects.
>> If you mark methods as "extend at own risk" and I go down a stupid route
>> that is my own stupidity. At least I can get something reasonable working
>> in
>> the short term even if it can be done better later. I'm a good boy so I
>> have
>> lots of unit and functional tests to catch mistakes later.
>>
>> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
>> rather onClick, onSubmit etc were interfaces so I could choose if I
>> wanted
>> them in the component (to reduce numbers of objects) or anywhere I like.
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
>> >> the problem is that that still not really does auto dirty..
>> >> Because where does it end? just add/remove/visitble/enable?
>> >> The nice thing is we have already something like that: thats page
>> >> versioning
>> >> with the undo/change map.
>> > Don't get too attached to it :) We should remove it in the next
>> > version, doesn't make much sense for 2nd level cache session store :)
>> >
>> > -Matej
>> >
>> >> If we extend that a little bit then we could have something like
>> >> componentChanged(component) on a page (or somekind of listener)
>> >> and that component did trigger it self what ever did happen on it
>> >> (getting a
>> >> child, settting the visibility, or setting an internal none wicket
>> core
>> >> property)
>> >>
>> >> johan
>> >>
>> >>
>> >>
>> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> >> >
>> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> >> > > but this discussion is not just about getter/setters (i don't care
>> >> about
>> >> > > those)
>> >> > > but also for add and remove.. then we are getting into some other
>> >> stuff
>> >> >
>> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
>> >> > in sweat when I imagine removing final on add and remove.
>> >> >
>> >> > Eelco
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
i have told you now i think at least 3 times
only be able to override those methods WONT i repeat again WONT help you
completely
those are not the only events that could get a component to be dirty.
there are lots more especially when you also take into account the none core
stuff.
Something like the change tracker is the way to go.
johan
On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Errr. Should I take from all this not to use the page versioning and that
> I
> shouldn't hold my breath for final being removed from anywhere?
>
> I know you are all sick of this topic, poor old Eelco, but seems like a
> simple, efficient and flexible way for me to add hooks is to extend
> objects.
> If you mark methods as "extend at own risk" and I go down a stupid route
> that is my own stupidity. At least I can get something reasonable working
> in
> the short term even if it can be done better later. I'm a good boy so I
> have
> lots of unit and functional tests to catch mistakes later.
>
> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
> rather onClick, onSubmit etc were interfaces so I could choose if I wanted
> them in the component (to reduce numbers of objects) or anywhere I like.
>
>
> Matej Knopp-2 wrote:
> >
> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> >> the problem is that that still not really does auto dirty..
> >> Because where does it end? just add/remove/visitble/enable?
> >> The nice thing is we have already something like that: thats page
> >> versioning
> >> with the undo/change map.
> > Don't get too attached to it :) We should remove it in the next
> > version, doesn't make much sense for 2nd level cache session store :)
> >
> > -Matej
> >
> >> If we extend that a little bit then we could have something like
> >> componentChanged(component) on a page (or somekind of listener)
> >> and that component did trigger it self what ever did happen on it
> >> (getting a
> >> child, settting the visibility, or setting an internal none wicket core
> >> property)
> >>
> >> johan
> >>
> >>
> >>
> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >> >
> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> > > but this discussion is not just about getter/setters (i don't care
> >> about
> >> > > those)
> >> > > but also for add and remove.. then we are getting into some other
> >> stuff
> >> >
> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> >> > in sweat when I imagine removing final on add and remove.
> >> >
> >> > Eelco
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
I didn't want to sound to harsh, but I do think that opening up such a
basic, core feature to overriding is something not taken lightly.
There is a whole world of beginning Wicket users that need protection
from abusing the API.
Opening up this for your specific usecase would open up a whole can of
worms: not only add, but also replace, replaceWith, etc need to be
monitored.
If we are going to support your usecase, I'd rather do it in a way
that is sustainable, and not by just randomly removing final keywords.
Martijn
On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>
> I've put at the start of most questions that I've not got my head around
> Wicket yet and so it is probably me not seeing the obvious Wicket way to do
> something.
>
> I'm sorry if I've gone on about this too much but I thought I had
> encouragement to raise this as a JIRA issue so at least I could be told no
> for good.
>
> I probably won't be a long term supporter of Wicket but I've honestly tried
> to help out as much as I can while I'm here.
>
> Thanks for all your efforts.
>
> Bye.
>
>
>
> Martijn Dashorst wrote:
> >
> > I am getting more convinced that you are trying to shoehorn wicket in
> > a way it is not intended. Wicket is not GWT. Repeat after me: Wicket
> > is not GWT.
> >
> > Yes I trust *you* will will not f*ck up overriding the methods. But
> > there are about a thousand other developers for you that are more
> > likely to do awful things if we open up our api for your usecase.
> >
> > Wicket is open source, so you have the ability to remove the final
> > clauses in your own version. It is not *that* hard to remove them
> > yourself and keep up with our releases.
> >
> > I'd rather not accomodate you and leave you to your true love than
> > open up our api so that we can receive hell if we change something
> > internally, or have constant issues on the user list that something
> > doesn't work because someone forget to call super. Are *you* going to
> > provide the support on this list for all those cases? Helping out
> > those that are a bad boy and don't write unit tests? And how about in
> > a year when you are on your next project? Will you still help out on
> > the lists?
> >
> > Martijn
> >
> > On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >> Errr. Should I take from all this not to use the page versioning and that
> >> I
> >> shouldn't hold my breath for final being removed from anywhere?
> >>
> >> I know you are all sick of this topic, poor old Eelco, but seems like a
> >> simple, efficient and flexible way for me to add hooks is to extend
> >> objects.
> >> If you mark methods as "extend at own risk" and I go down a stupid route
> >> that is my own stupidity. At least I can get something reasonable working
> >> in
> >> the short term even if it can be done better later. I'm a good boy so I
> >> have
> >> lots of unit and functional tests to catch mistakes later.
> >>
> >> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
> >> rather onClick, onSubmit etc were interfaces so I could choose if I
> >> wanted
> >> them in the component (to reduce numbers of objects) or anywhere I like.
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> >> >> the problem is that that still not really does auto dirty..
> >> >> Because where does it end? just add/remove/visitble/enable?
> >> >> The nice thing is we have already something like that: thats page
> >> >> versioning
> >> >> with the undo/change map.
> >> > Don't get too attached to it :) We should remove it in the next
> >> > version, doesn't make much sense for 2nd level cache session store :)
> >> >
> >> > -Matej
> >> >
> >> >> If we extend that a little bit then we could have something like
> >> >> componentChanged(component) on a page (or somekind of listener)
> >> >> and that component did trigger it self what ever did happen on it
> >> >> (getting a
> >> >> child, settting the visibility, or setting an internal none wicket
> >> core
> >> >> property)
> >> >>
> >> >> johan
> >> >>
> >> >>
> >> >>
> >> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >> >> >
> >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> >> > > but this discussion is not just about getter/setters (i don't care
> >> >> about
> >> >> > > those)
> >> >> > > but also for add and remove.. then we are getting into some other
> >> >> stuff
> >> >> >
> >> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> >> >> > in sweat when I imagine removing final on add and remove.
> >> >> >
> >> >> > Eelco
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-beta3 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955683
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
I've put at the start of most questions that I've not got my head around
Wicket yet and so it is probably me not seeing the obvious Wicket way to do
something.
I'm sorry if I've gone on about this too much but I thought I had
encouragement to raise this as a JIRA issue so at least I could be told no
for good.
I probably won't be a long term supporter of Wicket but I've honestly tried
to help out as much as I can while I'm here.
Thanks for all your efforts.
Bye.
Martijn Dashorst wrote:
>
> I am getting more convinced that you are trying to shoehorn wicket in
> a way it is not intended. Wicket is not GWT. Repeat after me: Wicket
> is not GWT.
>
> Yes I trust *you* will will not f*ck up overriding the methods. But
> there are about a thousand other developers for you that are more
> likely to do awful things if we open up our api for your usecase.
>
> Wicket is open source, so you have the ability to remove the final
> clauses in your own version. It is not *that* hard to remove them
> yourself and keep up with our releases.
>
> I'd rather not accomodate you and leave you to your true love than
> open up our api so that we can receive hell if we change something
> internally, or have constant issues on the user list that something
> doesn't work because someone forget to call super. Are *you* going to
> provide the support on this list for all those cases? Helping out
> those that are a bad boy and don't write unit tests? And how about in
> a year when you are on your next project? Will you still help out on
> the lists?
>
> Martijn
>
> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>>
>> Errr. Should I take from all this not to use the page versioning and that
>> I
>> shouldn't hold my breath for final being removed from anywhere?
>>
>> I know you are all sick of this topic, poor old Eelco, but seems like a
>> simple, efficient and flexible way for me to add hooks is to extend
>> objects.
>> If you mark methods as "extend at own risk" and I go down a stupid route
>> that is my own stupidity. At least I can get something reasonable working
>> in
>> the short term even if it can be done better later. I'm a good boy so I
>> have
>> lots of unit and functional tests to catch mistakes later.
>>
>> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
>> rather onClick, onSubmit etc were interfaces so I could choose if I
>> wanted
>> them in the component (to reduce numbers of objects) or anywhere I like.
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
>> >> the problem is that that still not really does auto dirty..
>> >> Because where does it end? just add/remove/visitble/enable?
>> >> The nice thing is we have already something like that: thats page
>> >> versioning
>> >> with the undo/change map.
>> > Don't get too attached to it :) We should remove it in the next
>> > version, doesn't make much sense for 2nd level cache session store :)
>> >
>> > -Matej
>> >
>> >> If we extend that a little bit then we could have something like
>> >> componentChanged(component) on a page (or somekind of listener)
>> >> and that component did trigger it self what ever did happen on it
>> >> (getting a
>> >> child, settting the visibility, or setting an internal none wicket
>> core
>> >> property)
>> >>
>> >> johan
>> >>
>> >>
>> >>
>> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> >> >
>> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> >> > > but this discussion is not just about getter/setters (i don't care
>> >> about
>> >> > > those)
>> >> > > but also for add and remove.. then we are getting into some other
>> >> stuff
>> >> >
>> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
>> >> > in sweat when I imagine removing final on add and remove.
>> >> >
>> >> > Eelco
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955683
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
I am getting more convinced that you are trying to shoehorn wicket in
a way it is not intended. Wicket is not GWT. Repeat after me: Wicket
is not GWT.
Yes I trust *you* will will not f*ck up overriding the methods. But
there are about a thousand other developers for you that are more
likely to do awful things if we open up our api for your usecase.
Wicket is open source, so you have the ability to remove the final
clauses in your own version. It is not *that* hard to remove them
yourself and keep up with our releases.
I'd rather not accomodate you and leave you to your true love than
open up our api so that we can receive hell if we change something
internally, or have constant issues on the user list that something
doesn't work because someone forget to call super. Are *you* going to
provide the support on this list for all those cases? Helping out
those that are a bad boy and don't write unit tests? And how about in
a year when you are on your next project? Will you still help out on
the lists?
Martijn
On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>
> Errr. Should I take from all this not to use the page versioning and that I
> shouldn't hold my breath for final being removed from anywhere?
>
> I know you are all sick of this topic, poor old Eelco, but seems like a
> simple, efficient and flexible way for me to add hooks is to extend objects.
> If you mark methods as "extend at own risk" and I go down a stupid route
> that is my own stupidity. At least I can get something reasonable working in
> the short term even if it can be done better later. I'm a good boy so I have
> lots of unit and functional tests to catch mistakes later.
>
> Sorry that I'm struggling with the wicket way. To add to my confusion I'd
> rather onClick, onSubmit etc were interfaces so I could choose if I wanted
> them in the component (to reduce numbers of objects) or anywhere I like.
>
>
> Matej Knopp-2 wrote:
> >
> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> >> the problem is that that still not really does auto dirty..
> >> Because where does it end? just add/remove/visitble/enable?
> >> The nice thing is we have already something like that: thats page
> >> versioning
> >> with the undo/change map.
> > Don't get too attached to it :) We should remove it in the next
> > version, doesn't make much sense for 2nd level cache session store :)
> >
> > -Matej
> >
> >> If we extend that a little bit then we could have something like
> >> componentChanged(component) on a page (or somekind of listener)
> >> and that component did trigger it self what ever did happen on it
> >> (getting a
> >> child, settting the visibility, or setting an internal none wicket core
> >> property)
> >>
> >> johan
> >>
> >>
> >>
> >> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >> >
> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> > > but this discussion is not just about getter/setters (i don't care
> >> about
> >> > > those)
> >> > > but also for add and remove.. then we are getting into some other
> >> stuff
> >> >
> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> >> > in sweat when I imagine removing final on add and remove.
> >> >
> >> > Eelco
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Errr. Should I take from all this not to use the page versioning and that I
shouldn't hold my breath for final being removed from anywhere?
I know you are all sick of this topic, poor old Eelco, but seems like a
simple, efficient and flexible way for me to add hooks is to extend objects.
If you mark methods as "extend at own risk" and I go down a stupid route
that is my own stupidity. At least I can get something reasonable working in
the short term even if it can be done better later. I'm a good boy so I have
lots of unit and functional tests to catch mistakes later.
Sorry that I'm struggling with the wicket way. To add to my confusion I'd
rather onClick, onSubmit etc were interfaces so I could choose if I wanted
them in the component (to reduce numbers of objects) or anywhere I like.
Matej Knopp-2 wrote:
>
> On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
>> the problem is that that still not really does auto dirty..
>> Because where does it end? just add/remove/visitble/enable?
>> The nice thing is we have already something like that: thats page
>> versioning
>> with the undo/change map.
> Don't get too attached to it :) We should remove it in the next
> version, doesn't make much sense for 2nd level cache session store :)
>
> -Matej
>
>> If we extend that a little bit then we could have something like
>> componentChanged(component) on a page (or somekind of listener)
>> and that component did trigger it self what ever did happen on it
>> (getting a
>> child, settting the visibility, or setting an internal none wicket core
>> property)
>>
>> johan
>>
>>
>>
>> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> >
>> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> > > but this discussion is not just about getter/setters (i don't care
>> about
>> > > those)
>> > > but also for add and remove.. then we are getting into some other
>> stuff
>> >
>> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
>> > in sweat when I imagine removing final on add and remove.
>> >
>> > Eelco
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
Much more performant is very relative. Not to mention that it's much
more memory heavy, and when GC starts to kick in, the performance is
decreased significantly.
Apart from that, HTTP session store has significant undo/redo
problems, and accessstackpagemap leads to unexpected page expiration
problem. So should we support httpsessionstore in future, we need to
either fix the undo/redo problem (thus increasing complexity for a
very rare used feature), or make all pages non-versioned when using
httpsessionstore (this would work for me).
-Matej
On 9/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
> But the second level cache session store is not the only viable
> option: we still have the HTTP session store, which clearly is much
> more performant than any other store, especially if you don't have to
> cluster.
>
> Martijn
>
> On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > the problem is that that still not really does auto dirty..
> > > Because where does it end? just add/remove/visitble/enable?
> > > The nice thing is we have already something like that: thats page versioning
> > > with the undo/change map.
> > Don't get too attached to it :) We should remove it in the next
> > version, doesn't make much sense for 2nd level cache session store :)
> >
> > -Matej
> >
> > > If we extend that a little bit then we could have something like
> > > componentChanged(component) on a page (or somekind of listener)
> > > and that component did trigger it self what ever did happen on it (getting a
> > > child, settting the visibility, or setting an internal none wicket core
> > > property)
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > but this discussion is not just about getter/setters (i don't care about
> > > > > those)
> > > > > but also for add and remove.. then we are getting into some other stuff
> > > >
> > > > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > > > in sweat when I imagine removing final on add and remove.
> > > >
> > > > Eelco
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
But the second level cache session store is not the only viable
option: we still have the HTTP session store, which clearly is much
more performant than any other store, especially if you don't have to
cluster.
Martijn
On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > the problem is that that still not really does auto dirty..
> > Because where does it end? just add/remove/visitble/enable?
> > The nice thing is we have already something like that: thats page versioning
> > with the undo/change map.
> Don't get too attached to it :) We should remove it in the next
> version, doesn't make much sense for 2nd level cache session store :)
>
> -Matej
>
> > If we extend that a little bit then we could have something like
> > componentChanged(component) on a page (or somekind of listener)
> > and that component did trigger it self what ever did happen on it (getting a
> > child, settting the visibility, or setting an internal none wicket core
> > property)
> >
> > johan
> >
> >
> >
> > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > but this discussion is not just about getter/setters (i don't care about
> > > > those)
> > > > but also for add and remove.. then we are getting into some other stuff
> > >
> > > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > > in sweat when I imagine removing final on add and remove.
> > >
> > > Eelco
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
or just getPage().dirty();
-igor
On 9/28/07, Matej Knopp <ma...@gmail.com> wrote:
>
> newVersion();
> looks much better to me than addStateChange(new
> ChangeThatIsNotUsedAnyway() { public void undo().... });
>
> -Matej
>
> On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > yes we do
> > we use it still extensively
> > we dont cache the changes anymore those are gone, but we still uses it
> to
> > bump up the versions
> > else how can we do that?
> >
> > johan
> >
> >
> >
> > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > >
> > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > the problem is that that still not really does auto dirty..
> > > > Because where does it end? just add/remove/visitble/enable?
> > > > The nice thing is we have already something like that: thats page
> > > versioning
> > > > with the undo/change map.
> > > Don't get too attached to it :) We should remove it in the next
> > > version, doesn't make much sense for 2nd level cache session store :)
> > >
> > > -Matej
> > >
> > > > If we extend that a little bit then we could have something like
> > > > componentChanged(component) on a page (or somekind of listener)
> > > > and that component did trigger it self what ever did happen on it
> > > (getting a
> > > > child, settting the visibility, or setting an internal none wicket
> core
> > > > property)
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > but this discussion is not just about getter/setters (i don't
> care
> > > about
> > > > > > those)
> > > > > > but also for add and remove.. then we are getting into some
> other
> > > stuff
> > > > >
> > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> breaking
> > > > > in sweat when I imagine removing final on add and remove.
> > > > >
> > > > > Eelco
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
Yeah, something like that. either dirty() or something else. Point it
it would be just one call without tracking each change. And for
HttpSessionStore, we could still support it, but only with one (most
recent) version per page instance. Thus no page versioning without
secondlevelcachesessionstore. But that is for 1.4 or later of course.
-Matej
On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> And then dirty bumps up the version number?
>
> again VersionManager is still used extensively even with the slc
> It takes care of the version numbers (normal and ajax)
>
> so if you have page.dirty() which contracts is now update in the session
> then we also suddenly bump up the version number??
> of course component.setVersioned() can't be ditched because developers
> should be able to disable versioning (backbutton support) for a page
>
>
> johan
>
>
> On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > On 9/29/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > yeah, so we keep the actual core events we support in the interface,
> > like
> > > oncomponentadded(component) but remove all the Change objects.
> > >
> > > when a user changes the property they then have to call dirty();
> > personally
> > > i think we can just serialize every time and not require the user to
> > call
> > > dirty() just assume it is after every request. not sure how wasteful
> > that
> > > is...maybe if the user sets a different response page we assume the
> > previous
> > > page is not dirty unless dirty() was called explicitly...
> > Yeah, that's a good point. Current state is as if dirty() was called
> > every request. I think if anyone needs to tune this, we should provide
> > way of marking page not dirty, which people who really have lot of
> > small request that don't do anything (e.g. polling) could use. I
> > remember doing such thing for thoof to suppress page serialization for
> > ajax polling, but that was rather trivial to do.
> >
> > -Matej
> > >
> > > -igor
> > >
> > >
> > > On 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > but then still we have the event..
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > >
> > > > > newVersion();
> > > > > looks much better to me than addStateChange(new
> > > > > ChangeThatIsNotUsedAnyway() { public void undo().... });
> > > > >
> > > > > -Matej
> > > > >
> > > > > On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > yes we do
> > > > > > we use it still extensively
> > > > > > we dont cache the changes anymore those are gone, but we still
> > uses it
> > > > > to
> > > > > > bump up the versions
> > > > > > else how can we do that?
> > > > > >
> > > > > > johan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > > the problem is that that still not really does auto dirty..
> > > > > > > > Because where does it end? just add/remove/visitble/enable?
> > > > > > > > The nice thing is we have already something like that: thats
> > page
> > > > > > > versioning
> > > > > > > > with the undo/change map.
> > > > > > > Don't get too attached to it :) We should remove it in the next
> > > > > > > version, doesn't make much sense for 2nd level cache session
> > store
> > > > :)
> > > > > > >
> > > > > > > -Matej
> > > > > > >
> > > > > > > > If we extend that a little bit then we could have something
> > like
> > > > > > > > componentChanged(component) on a page (or somekind of
> > listener)
> > > > > > > > and that component did trigger it self what ever did happen on
> > it
> > > > > > > (getting a
> > > > > > > > child, settting the visibility, or setting an internal none
> > wicket
> > > > > core
> > > > > > > > property)
> > > > > > > >
> > > > > > > > johan
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > > > > but this discussion is not just about getter/setters (i
> > don't
> > > > > care
> > > > > > > about
> > > > > > > > > > those)
> > > > > > > > > > but also for add and remove.. then we are getting into
> > some
> > > > > other
> > > > > > > stuff
> > > > > > > > >
> > > > > > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> > > > > breaking
> > > > > > > > > in sweat when I imagine removing final on add and remove.
> > > > > > > > >
> > > > > > > > > Eelco
> > > > > > > > >
> > > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > > > For additional commands, e-mail:
> > users-help@wicket.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
And then dirty bumps up the version number?
again VersionManager is still used extensively even with the slc
It takes care of the version numbers (normal and ajax)
so if you have page.dirty() which contracts is now update in the session
then we also suddenly bump up the version number??
of course component.setVersioned() can't be ditched because developers
should be able to disable versioning (backbutton support) for a page
johan
On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
>
> On 9/29/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > yeah, so we keep the actual core events we support in the interface,
> like
> > oncomponentadded(component) but remove all the Change objects.
> >
> > when a user changes the property they then have to call dirty();
> personally
> > i think we can just serialize every time and not require the user to
> call
> > dirty() just assume it is after every request. not sure how wasteful
> that
> > is...maybe if the user sets a different response page we assume the
> previous
> > page is not dirty unless dirty() was called explicitly...
> Yeah, that's a good point. Current state is as if dirty() was called
> every request. I think if anyone needs to tune this, we should provide
> way of marking page not dirty, which people who really have lot of
> small request that don't do anything (e.g. polling) could use. I
> remember doing such thing for thoof to suppress page serialization for
> ajax polling, but that was rather trivial to do.
>
> -Matej
> >
> > -igor
> >
> >
> > On 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > but then still we have the event..
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > >
> > > > newVersion();
> > > > looks much better to me than addStateChange(new
> > > > ChangeThatIsNotUsedAnyway() { public void undo().... });
> > > >
> > > > -Matej
> > > >
> > > > On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > yes we do
> > > > > we use it still extensively
> > > > > we dont cache the changes anymore those are gone, but we still
> uses it
> > > > to
> > > > > bump up the versions
> > > > > else how can we do that?
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > >
> > > > > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > the problem is that that still not really does auto dirty..
> > > > > > > Because where does it end? just add/remove/visitble/enable?
> > > > > > > The nice thing is we have already something like that: thats
> page
> > > > > > versioning
> > > > > > > with the undo/change map.
> > > > > > Don't get too attached to it :) We should remove it in the next
> > > > > > version, doesn't make much sense for 2nd level cache session
> store
> > > :)
> > > > > >
> > > > > > -Matej
> > > > > >
> > > > > > > If we extend that a little bit then we could have something
> like
> > > > > > > componentChanged(component) on a page (or somekind of
> listener)
> > > > > > > and that component did trigger it self what ever did happen on
> it
> > > > > > (getting a
> > > > > > > child, settting the visibility, or setting an internal none
> wicket
> > > > core
> > > > > > > property)
> > > > > > >
> > > > > > > johan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > > > but this discussion is not just about getter/setters (i
> don't
> > > > care
> > > > > > about
> > > > > > > > > those)
> > > > > > > > > but also for add and remove.. then we are getting into
> some
> > > > other
> > > > > > stuff
> > > > > > > >
> > > > > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> > > > breaking
> > > > > > > > in sweat when I imagine removing final on add and remove.
> > > > > > > >
> > > > > > > > Eelco
> > > > > > > >
> > > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > > For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
On 9/29/07, Igor Vaynberg <ig...@gmail.com> wrote:
> yeah, so we keep the actual core events we support in the interface, like
> oncomponentadded(component) but remove all the Change objects.
>
> when a user changes the property they then have to call dirty(); personally
> i think we can just serialize every time and not require the user to call
> dirty() just assume it is after every request. not sure how wasteful that
> is...maybe if the user sets a different response page we assume the previous
> page is not dirty unless dirty() was called explicitly...
Yeah, that's a good point. Current state is as if dirty() was called
every request. I think if anyone needs to tune this, we should provide
way of marking page not dirty, which people who really have lot of
small request that don't do anything (e.g. polling) could use. I
remember doing such thing for thoof to suppress page serialization for
ajax polling, but that was rather trivial to do.
-Matej
>
> -igor
>
>
> On 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > but then still we have the event..
> >
> > johan
> >
> >
> >
> > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > >
> > > newVersion();
> > > looks much better to me than addStateChange(new
> > > ChangeThatIsNotUsedAnyway() { public void undo().... });
> > >
> > > -Matej
> > >
> > > On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > yes we do
> > > > we use it still extensively
> > > > we dont cache the changes anymore those are gone, but we still uses it
> > > to
> > > > bump up the versions
> > > > else how can we do that?
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > >
> > > > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > the problem is that that still not really does auto dirty..
> > > > > > Because where does it end? just add/remove/visitble/enable?
> > > > > > The nice thing is we have already something like that: thats page
> > > > > versioning
> > > > > > with the undo/change map.
> > > > > Don't get too attached to it :) We should remove it in the next
> > > > > version, doesn't make much sense for 2nd level cache session store
> > :)
> > > > >
> > > > > -Matej
> > > > >
> > > > > > If we extend that a little bit then we could have something like
> > > > > > componentChanged(component) on a page (or somekind of listener)
> > > > > > and that component did trigger it self what ever did happen on it
> > > > > (getting a
> > > > > > child, settting the visibility, or setting an internal none wicket
> > > core
> > > > > > property)
> > > > > >
> > > > > > johan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > > but this discussion is not just about getter/setters (i don't
> > > care
> > > > > about
> > > > > > > > those)
> > > > > > > > but also for add and remove.. then we are getting into some
> > > other
> > > > > stuff
> > > > > > >
> > > > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> > > breaking
> > > > > > > in sweat when I imagine removing final on add and remove.
> > > > > > >
> > > > > > > Eelco
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
yeah, so we keep the actual core events we support in the interface, like
oncomponentadded(component) but remove all the Change objects.
when a user changes the property they then have to call dirty(); personally
i think we can just serialize every time and not require the user to call
dirty() just assume it is after every request. not sure how wasteful that
is...maybe if the user sets a different response page we assume the previous
page is not dirty unless dirty() was called explicitly...
-igor
On 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
>
> but then still we have the event..
>
> johan
>
>
>
> On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > newVersion();
> > looks much better to me than addStateChange(new
> > ChangeThatIsNotUsedAnyway() { public void undo().... });
> >
> > -Matej
> >
> > On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > > yes we do
> > > we use it still extensively
> > > we dont cache the changes anymore those are gone, but we still uses it
> > to
> > > bump up the versions
> > > else how can we do that?
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > >
> > > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > the problem is that that still not really does auto dirty..
> > > > > Because where does it end? just add/remove/visitble/enable?
> > > > > The nice thing is we have already something like that: thats page
> > > > versioning
> > > > > with the undo/change map.
> > > > Don't get too attached to it :) We should remove it in the next
> > > > version, doesn't make much sense for 2nd level cache session store
> :)
> > > >
> > > > -Matej
> > > >
> > > > > If we extend that a little bit then we could have something like
> > > > > componentChanged(component) on a page (or somekind of listener)
> > > > > and that component did trigger it self what ever did happen on it
> > > > (getting a
> > > > > child, settting the visibility, or setting an internal none wicket
> > core
> > > > > property)
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > but this discussion is not just about getter/setters (i don't
> > care
> > > > about
> > > > > > > those)
> > > > > > > but also for add and remove.. then we are getting into some
> > other
> > > > stuff
> > > > > >
> > > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> > breaking
> > > > > > in sweat when I imagine removing final on add and remove.
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
sure. you can hook whatever you want there. My remark was solely about
ditching the version manager. Unless someone really wants it there,
but then we have to fix it to support redo, etc. I dont' think it's
worth it.
-Matej
On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> but then still we have the event..
>
> johan
>
>
>
> On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > newVersion();
> > looks much better to me than addStateChange(new
> > ChangeThatIsNotUsedAnyway() { public void undo().... });
> >
> > -Matej
> >
> > On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > > yes we do
> > > we use it still extensively
> > > we dont cache the changes anymore those are gone, but we still uses it
> > to
> > > bump up the versions
> > > else how can we do that?
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > > >
> > > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > the problem is that that still not really does auto dirty..
> > > > > Because where does it end? just add/remove/visitble/enable?
> > > > > The nice thing is we have already something like that: thats page
> > > > versioning
> > > > > with the undo/change map.
> > > > Don't get too attached to it :) We should remove it in the next
> > > > version, doesn't make much sense for 2nd level cache session store :)
> > > >
> > > > -Matej
> > > >
> > > > > If we extend that a little bit then we could have something like
> > > > > componentChanged(component) on a page (or somekind of listener)
> > > > > and that component did trigger it self what ever did happen on it
> > > > (getting a
> > > > > child, settting the visibility, or setting an internal none wicket
> > core
> > > > > property)
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > > but this discussion is not just about getter/setters (i don't
> > care
> > > > about
> > > > > > > those)
> > > > > > > but also for add and remove.. then we are getting into some
> > other
> > > > stuff
> > > > > >
> > > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> > breaking
> > > > > > in sweat when I imagine removing final on add and remove.
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
but then still we have the event..
johan
On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
>
> newVersion();
> looks much better to me than addStateChange(new
> ChangeThatIsNotUsedAnyway() { public void undo().... });
>
> -Matej
>
> On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> > yes we do
> > we use it still extensively
> > we dont cache the changes anymore those are gone, but we still uses it
> to
> > bump up the versions
> > else how can we do that?
> >
> > johan
> >
> >
> >
> > On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> > >
> > > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > the problem is that that still not really does auto dirty..
> > > > Because where does it end? just add/remove/visitble/enable?
> > > > The nice thing is we have already something like that: thats page
> > > versioning
> > > > with the undo/change map.
> > > Don't get too attached to it :) We should remove it in the next
> > > version, doesn't make much sense for 2nd level cache session store :)
> > >
> > > -Matej
> > >
> > > > If we extend that a little bit then we could have something like
> > > > componentChanged(component) on a page (or somekind of listener)
> > > > and that component did trigger it self what ever did happen on it
> > > (getting a
> > > > child, settting the visibility, or setting an internal none wicket
> core
> > > > property)
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > > but this discussion is not just about getter/setters (i don't
> care
> > > about
> > > > > > those)
> > > > > > but also for add and remove.. then we are getting into some
> other
> > > stuff
> > > > >
> > > > > Yes. Getters/ setters are less tricky. Though I'm still not
> breaking
> > > > > in sweat when I imagine removing final on add and remove.
> > > > >
> > > > > Eelco
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
newVersion();
looks much better to me than addStateChange(new
ChangeThatIsNotUsedAnyway() { public void undo().... });
-Matej
On 9/29/07, Johan Compagner <jc...@gmail.com> wrote:
> yes we do
> we use it still extensively
> we dont cache the changes anymore those are gone, but we still uses it to
> bump up the versions
> else how can we do that?
>
> johan
>
>
>
> On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > > the problem is that that still not really does auto dirty..
> > > Because where does it end? just add/remove/visitble/enable?
> > > The nice thing is we have already something like that: thats page
> > versioning
> > > with the undo/change map.
> > Don't get too attached to it :) We should remove it in the next
> > version, doesn't make much sense for 2nd level cache session store :)
> >
> > -Matej
> >
> > > If we extend that a little bit then we could have something like
> > > componentChanged(component) on a page (or somekind of listener)
> > > and that component did trigger it self what ever did happen on it
> > (getting a
> > > child, settting the visibility, or setting an internal none wicket core
> > > property)
> > >
> > > johan
> > >
> > >
> > >
> > > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > but this discussion is not just about getter/setters (i don't care
> > about
> > > > > those)
> > > > > but also for add and remove.. then we are getting into some other
> > stuff
> > > >
> > > > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > > > in sweat when I imagine removing final on add and remove.
> > > >
> > > > Eelco
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
yes we do
we use it still extensively
we dont cache the changes anymore those are gone, but we still uses it to
bump up the versions
else how can we do that?
johan
On 9/29/07, Matej Knopp <ma...@gmail.com> wrote:
>
> On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > the problem is that that still not really does auto dirty..
> > Because where does it end? just add/remove/visitble/enable?
> > The nice thing is we have already something like that: thats page
> versioning
> > with the undo/change map.
> Don't get too attached to it :) We should remove it in the next
> version, doesn't make much sense for 2nd level cache session store :)
>
> -Matej
>
> > If we extend that a little bit then we could have something like
> > componentChanged(component) on a page (or somekind of listener)
> > and that component did trigger it self what ever did happen on it
> (getting a
> > child, settting the visibility, or setting an internal none wicket core
> > property)
> >
> > johan
> >
> >
> >
> > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > but this discussion is not just about getter/setters (i don't care
> about
> > > > those)
> > > > but also for add and remove.. then we are getting into some other
> stuff
> > >
> > > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > > in sweat when I imagine removing final on add and remove.
> > >
> > > Eelco
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
we might remove the change tracking, but the interface can stay. maybe it
wont be called a versionmanager anymore...
-igor
On 9/28/07, Matej Knopp <ma...@gmail.com> wrote:
>
> On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> > the problem is that that still not really does auto dirty..
> > Because where does it end? just add/remove/visitble/enable?
> > The nice thing is we have already something like that: thats page
> versioning
> > with the undo/change map.
> Don't get too attached to it :) We should remove it in the next
> version, doesn't make much sense for 2nd level cache session store :)
>
> -Matej
>
> > If we extend that a little bit then we could have something like
> > componentChanged(component) on a page (or somekind of listener)
> > and that component did trigger it self what ever did happen on it
> (getting a
> > child, settting the visibility, or setting an internal none wicket core
> > property)
> >
> > johan
> >
> >
> >
> > On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > but this discussion is not just about getter/setters (i don't care
> about
> > > > those)
> > > > but also for add and remove.. then we are getting into some other
> stuff
> > >
> > > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > > in sweat when I imagine removing final on add and remove.
> > >
> > > Eelco
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Matej Knopp <ma...@gmail.com>.
On 9/27/07, Johan Compagner <jc...@gmail.com> wrote:
> the problem is that that still not really does auto dirty..
> Because where does it end? just add/remove/visitble/enable?
> The nice thing is we have already something like that: thats page versioning
> with the undo/change map.
Don't get too attached to it :) We should remove it in the next
version, doesn't make much sense for 2nd level cache session store :)
-Matej
> If we extend that a little bit then we could have something like
> componentChanged(component) on a page (or somekind of listener)
> and that component did trigger it self what ever did happen on it (getting a
> child, settting the visibility, or setting an internal none wicket core
> property)
>
> johan
>
>
>
> On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > > but this discussion is not just about getter/setters (i don't care about
> > > those)
> > > but also for add and remove.. then we are getting into some other stuff
> >
> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > in sweat when I imagine removing final on add and remove.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
the problem is that that still not really does auto dirty..
Because where does it end? just add/remove/visitble/enable?
The nice thing is we have already something like that: thats page versioning
with the undo/change map.
If we extend that a little bit then we could have something like
componentChanged(component) on a page (or somekind of listener)
and that component did trigger it self what ever did happen on it (getting a
child, settting the visibility, or setting an internal none wicket core
property)
johan
On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> > but this discussion is not just about getter/setters (i don't care about
> > those)
> > but also for add and remove.. then we are getting into some other stuff
>
> Yes. Getters/ setters are less tricky. Though I'm still not breaking
> in sweat when I imagine removing final on add and remove.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Is there a jira issue already for that or should I try and come up with one?
Thanks
Sam
Johan Compagner wrote:
>
> as i said before removing those files will not really help you
> the current change tracker/listener we have is the way to go.
> We just need to refactor it a little bit and create an extra method where
> people can hook up in.
>
> johan
>
>
>
> On 9/28/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> The nicest way I can think of to solve:
>>
>> http://www.nabble.com/Reach-into-a-component-to-change-XML-attribute-tf4527906.html
>>
>> Would be to override add, removeAll, remove etc to manage
>> AttributeModifier
>> when the children change rather than every time the components render
>> etc...
>>
>> So I'm not being won over by the final thing since I'd like them gone for
>> my
>> auto-dirty, first/last class attribute and so I can keep using onClick
>> and
>> onSubmit...
>>
>> If I'm hitting an imaginery brick wall then I'd be delighted to be shown
>> the
>> light.
>>
>> Cheers
>>
>> Sam
>>
>>
>>
>> Eelco Hillenius wrote:
>> >
>> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> >> but this discussion is not just about getter/setters (i don't care
>> about
>> >> those)
>> >> but also for add and remove.. then we are getting into some other
>> stuff
>> >
>> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
>> > in sweat when I imagine removing final on add and remove.
>> >
>> > Eelco
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12940572
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12942608
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
as i said before removing those files will not really help you
the current change tracker/listener we have is the way to go.
We just need to refactor it a little bit and create an extra method where
people can hook up in.
johan
On 9/28/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> The nicest way I can think of to solve:
>
> http://www.nabble.com/Reach-into-a-component-to-change-XML-attribute-tf4527906.html
>
> Would be to override add, removeAll, remove etc to manage
> AttributeModifier
> when the children change rather than every time the components render
> etc...
>
> So I'm not being won over by the final thing since I'd like them gone for
> my
> auto-dirty, first/last class attribute and so I can keep using onClick and
> onSubmit...
>
> If I'm hitting an imaginery brick wall then I'd be delighted to be shown
> the
> light.
>
> Cheers
>
> Sam
>
>
>
> Eelco Hillenius wrote:
> >
> > On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> >> but this discussion is not just about getter/setters (i don't care
> about
> >> those)
> >> but also for add and remove.. then we are getting into some other stuff
> >
> > Yes. Getters/ setters are less tricky. Though I'm still not breaking
> > in sweat when I imagine removing final on add and remove.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12940572
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
The nicest way I can think of to solve:
http://www.nabble.com/Reach-into-a-component-to-change-XML-attribute-tf4527906.html
Would be to override add, removeAll, remove etc to manage AttributeModifier
when the children change rather than every time the components render etc...
So I'm not being won over by the final thing since I'd like them gone for my
auto-dirty, first/last class attribute and so I can keep using onClick and
onSubmit...
If I'm hitting an imaginery brick wall then I'd be delighted to be shown the
light.
Cheers
Sam
Eelco Hillenius wrote:
>
> On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>> but this discussion is not just about getter/setters (i don't care about
>> those)
>> but also for add and remove.. then we are getting into some other stuff
>
> Yes. Getters/ setters are less tricky. Though I'm still not breaking
> in sweat when I imagine removing final on add and remove.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12940572
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
> but this discussion is not just about getter/setters (i don't care about
> those)
> but also for add and remove.. then we are getting into some other stuff
Yes. Getters/ setters are less tricky. Though I'm still not breaking
in sweat when I imagine removing final on add and remove.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
but this discussion is not just about getter/setters (i don't care about
those)
but also for add and remove.. then we are getting into some other stuff
johan
On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 9/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > I disagree. We need to keep an eye out for those that begin to use the
> > framework. We have seen enough people that randomly start to override
> > methods just to work around some perceived wall that typically isn't
> > there if they actually thought about their problem in the first place.
>
> Well yeah, in general that is true. For setters... I've grown tired of
> the many discussions here I guess.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> I disagree. We need to keep an eye out for those that begin to use the
> framework. We have seen enough people that randomly start to override
> methods just to work around some perceived wall that typically isn't
> there if they actually thought about their problem in the first place.
Well yeah, in general that is true. For setters... I've grown tired of
the many discussions here I guess.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Martijn Dashorst <ma...@gmail.com>.
I disagree. We need to keep an eye out for those that begin to use the
framework. We have seen enough people that randomly start to override
methods just to work around some perceived wall that typically isn't
there if they actually thought about their problem in the first place.
I am glad we are protective, and stubborn in that regard. It is better
to err on the safe side.
Martijn
On 9/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 9/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > yep, a nicer way to support this might be to add recordenablechange, record
> > visibilitychange to version manager interface
>
> I have very mixed feelings about this as well. Maybe we're too
> spastic/ protective sometimes. Another way of going about this is to
> expect people to know what they're doing when they override those
> sets. I think that would be good enough for me.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> yep, a nicer way to support this might be to add recordenablechange, record
> visibilitychange to version manager interface
I have very mixed feelings about this as well. Maybe we're too
spastic/ protective sometimes. Another way of going about this is to
expect people to know what they're doing when they override those
sets. I think that would be good enough for me.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
yep, a nicer way to support this might be to add recordenablechange, record
visibilitychange to version manager interface
-igor
On 9/26/07, Johan Compagner <jc...@gmail.com> wrote:
>
> we already have a change recorder on a page for its components, all
> the methods you mention should also call that.
Then it can also be
> made much more fail prove because a component should just 'fire' call
> the change method. because state is not just those what you mention
> but could be anything
>
> On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
> >
> > Eelco,
> >
> > Meant to say we have our first case where we want a component to update
> > because the model has changed. It is a field that only gets updated on
> the
> > server not directly through an HTML form... Since it is only one so far
> a
> > hand coded Dirty.mark(this) is not too evil.
> >
> > Sorry, talking to myself again.
> > --
> > View this message in context:
> >
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
So the Wicket dev team commits to supporting that as a legitimate extension
point? ;) It shouldn't be too painful for me to switch whatever method I use
as it will be encapsulated in a very small portion of code. Just really
didn't want to use AOP, our own version of wicket or something stupidly
slow.
Cheers
Sam
Johan Compagner wrote:
>
> that doesn't matter,
> We don't store them (the changes for rollback) anymore but the page still
> gets the events.
> Because we still have to know it so that we can increment the page
> counter...
>
> johan
>
>
>
> On 9/27/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> This posting put me off using the change recorder:
>>
>> http://www.nabble.com/forum/ViewPost.jtp?post=12473029&framed=y
>>
>> Did I get the wrong end of the stick?
>>
>>
>>
>> Johan Compagner wrote:
>> >
>> > we already have a change recorder on a page for its components, all
>> > the methods you mention should also call that.
Then it can also be
>> > made much more fail prove because a component should just 'fire' call
>> > the change method. because state is not just those what you mention
>> > but could be anything
>> >
>> > On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
>> >>
>> >> Eelco,
>> >>
>> >> Meant to say we have our first case where we want a component to
>> update
>> >> because the model has changed. It is a field that only gets updated on
>> >> the
>> >> server not directly through an HTML form... Since it is only one so
>> far
>> a
>> >> hand coded Dirty.mark(this) is not too evil.
>> >>
>> >> Sorry, talking to myself again.
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917688
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917892
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
that doesn't matter,
We don't store them (the changes for rollback) anymore but the page still
gets the events.
Because we still have to know it so that we can increment the page
counter...
johan
On 9/27/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> This posting put me off using the change recorder:
>
> http://www.nabble.com/forum/ViewPost.jtp?post=12473029&framed=y
>
> Did I get the wrong end of the stick?
>
>
>
> Johan Compagner wrote:
> >
> > we already have a change recorder on a page for its components, all
> > the methods you mention should also call that.
Then it can also be
> > made much more fail prove because a component should just 'fire' call
> > the change method. because state is not just those what you mention
> > but could be anything
> >
> > On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >> Eelco,
> >>
> >> Meant to say we have our first case where we want a component to update
> >> because the model has changed. It is a field that only gets updated on
> >> the
> >> server not directly through an HTML form... Since it is only one so far
> a
> >> hand coded Dirty.mark(this) is not too evil.
> >>
> >> Sorry, talking to myself again.
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917688
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
This posting put me off using the change recorder:
http://www.nabble.com/forum/ViewPost.jtp?post=12473029&framed=y
Did I get the wrong end of the stick?
Johan Compagner wrote:
>
> we already have a change recorder on a page for its components, all
> the methods you mention should also call that.
Then it can also be
> made much more fail prove because a component should just 'fire' call
> the change method. because state is not just those what you mention
> but could be anything
>
> On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
>>
>> Eelco,
>>
>> Meant to say we have our first case where we want a component to update
>> because the model has changed. It is a field that only gets updated on
>> the
>> server not directly through an HTML form... Since it is only one so far a
>> hand coded Dirty.mark(this) is not too evil.
>>
>> Sorry, talking to myself again.
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917688
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Johan Compagner <jc...@gmail.com>.
we already have a change recorder on a page for its components, all
the methods you mention should also call that.
Then it can also be
made much more fail prove because a component should just 'fire' call
the change method. because state is not just those what you mention
but could be anything
On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
>
> Eelco,
>
> Meant to say we have our first case where we want a component to update
> because the model has changed. It is a field that only gets updated on the
> server not directly through an HTML form... Since it is only one so far a
> hand coded Dirty.mark(this) is not too evil.
>
> Sorry, talking to myself again.
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Eelco,
Meant to say we have our first case where we want a component to update
because the model has changed. It is a field that only gets updated on the
server not directly through an HTML form... Since it is only one so far a
hand coded Dirty.mark(this) is not too evil.
Sorry, talking to myself again.
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
https://issues.apache.org/jira/browse/WICKET-1012
Cheers Igor
igor.vaynberg wrote:
>
> these are all sensitive methods where an override can break a contract, so
> i
> dont know what your chances are. the thing to do is to create a jira issue
> and then we can discuss/vote on it on the list.
>
> personally i do not like making add/remove nonfinal, but maybe we can
> provide additional hooks. i have mixed feelings about set* methods.
>
> -igor
>
>
> On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Igor,
>>
>> What are my chances of getting setVisible, setEnabled, add, addOrReplace
>> and
>> remove, removeAll made non-final?
>>
>> I'd like to hook into them to track dirty components... The best
>> alternative
>> I've come up with so far is to iterate through all the components and
>> keep
>> a
>> copy of their old state :( Nice in that it will be smart about
>> setVisible(false); setVisible(true) but not sure that is worth it.
>>
>> btw I still love Wicket and the kids even if my true love, that can never
>> be, is GWT. AjaxFallbackX works very nicely.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > looks reasonable.
>> >
>> > -igor
>> >
>> >
>> > On 9/12/07, Sam Hough <sa...@redspr.com> wrote:
>> >>
>> >>
>> >> Would RequestCycle be the place to keep track of dirty widgets?
>> >>
>> >> Presumably Session can be shared by more than one session and my be
>> used
>> >> by
>> >> multiple threads at the same time?
>> >>
>> >>
>> >>
>> >> Sam Hough wrote:
>> >> >
>> >> > Apologies in advance as I'm a newbie harking on about my pet topic
>> >> again
>> >> > but...
>> >> >
>> >> > Taking the example of TabbedPanel and AjaxTabbedPanel (only in
>> >> extensions
>> >> > but a common UI concept) I think it shows why it would be good to
>> use
>> >> the
>> >> > factory pattern to generate elemental widgets (like button, panel
>> etc
>> >> > assuming people want AjaxFallbackButton or Button) and automatically
>> >> track
>> >> > dirty components.
>> >> >
>> >> > I first got this bee in my bonnet about higher level application
>> code
>> >> > because I didn't think I should be messing about working out which
>> >> > components were dirty when I just want the result of pressing a
>> button
>> >> to
>> >> > fiddle with the model and change the ui state a bit. However looking
>> at
>> >> > *TabbedPanel I think it would also make sense for pure UI
>> components.
>> >> > Using inheritance to add Ajax to TabbedPanel means any other
>> variations
>> >> > also have to be doubled (e.g. AjaxFancyTabbedPanel and
>> FancyTabbedPanel
>> >> > etc). Perhaps the bigger problem is that if a Panel that is meant to
>> be
>> >> > inside a TabbedPanel and needs to alter another component (e.g.
>> update
>> >> > navigation component) the TabbedPanel has to ask it for changes.
>> >> > Presumably a component should be self contained as possible so it
>> >> doesn't
>> >> > matter what other component it is contained within.
>> >> >
>> >> > Factory pattern is a pain but presumably many people don't want the
>> >> > overhead of AjaxFallbackXXX. It would also make it possible to
>> program
>> >> > against interfaces which might give more power to Igor, Eelco etc
>> >> >
>> >> > Please don't get me wrong GWT is still my true love but Wicket is a
>> >> > fabulous framework taking us out of the dark ages of struts.
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12895965
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12902181
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
these are all sensitive methods where an override can break a contract, so i
dont know what your chances are. the thing to do is to create a jira issue
and then we can discuss/vote on it on the list.
personally i do not like making add/remove nonfinal, but maybe we can
provide additional hooks. i have mixed feelings about set* methods.
-igor
On 9/26/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Igor,
>
> What are my chances of getting setVisible, setEnabled, add, addOrReplace
> and
> remove, removeAll made non-final?
>
> I'd like to hook into them to track dirty components... The best
> alternative
> I've come up with so far is to iterate through all the components and keep
> a
> copy of their old state :( Nice in that it will be smart about
> setVisible(false); setVisible(true) but not sure that is worth it.
>
> btw I still love Wicket and the kids even if my true love, that can never
> be, is GWT. AjaxFallbackX works very nicely.
>
>
> igor.vaynberg wrote:
> >
> > looks reasonable.
> >
> > -igor
> >
> >
> > On 9/12/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >>
> >> Would RequestCycle be the place to keep track of dirty widgets?
> >>
> >> Presumably Session can be shared by more than one session and my be
> used
> >> by
> >> multiple threads at the same time?
> >>
> >>
> >>
> >> Sam Hough wrote:
> >> >
> >> > Apologies in advance as I'm a newbie harking on about my pet topic
> >> again
> >> > but...
> >> >
> >> > Taking the example of TabbedPanel and AjaxTabbedPanel (only in
> >> extensions
> >> > but a common UI concept) I think it shows why it would be good to use
> >> the
> >> > factory pattern to generate elemental widgets (like button, panel etc
> >> > assuming people want AjaxFallbackButton or Button) and automatically
> >> track
> >> > dirty components.
> >> >
> >> > I first got this bee in my bonnet about higher level application code
> >> > because I didn't think I should be messing about working out which
> >> > components were dirty when I just want the result of pressing a
> button
> >> to
> >> > fiddle with the model and change the ui state a bit. However looking
> at
> >> > *TabbedPanel I think it would also make sense for pure UI components.
> >> > Using inheritance to add Ajax to TabbedPanel means any other
> variations
> >> > also have to be doubled (e.g. AjaxFancyTabbedPanel and
> FancyTabbedPanel
> >> > etc). Perhaps the bigger problem is that if a Panel that is meant to
> be
> >> > inside a TabbedPanel and needs to alter another component (e.g.
> update
> >> > navigation component) the TabbedPanel has to ask it for changes.
> >> > Presumably a component should be self contained as possible so it
> >> doesn't
> >> > matter what other component it is contained within.
> >> >
> >> > Factory pattern is a pain but presumably many people don't want the
> >> > overhead of AjaxFallbackXXX. It would also make it possible to
> program
> >> > against interfaces which might give more power to Igor, Eelco etc
> >> >
> >> > Please don't get me wrong GWT is still my true love but Wicket is a
> >> > fabulous framework taking us out of the dark ages of struts.
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12895965
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Igor,
What are my chances of getting setVisible, setEnabled, add, addOrReplace and
remove, removeAll made non-final?
I'd like to hook into them to track dirty components... The best alternative
I've come up with so far is to iterate through all the components and keep a
copy of their old state :( Nice in that it will be smart about
setVisible(false); setVisible(true) but not sure that is worth it.
btw I still love Wicket and the kids even if my true love, that can never
be, is GWT. AjaxFallbackX works very nicely.
igor.vaynberg wrote:
>
> looks reasonable.
>
> -igor
>
>
> On 9/12/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Would RequestCycle be the place to keep track of dirty widgets?
>>
>> Presumably Session can be shared by more than one session and my be used
>> by
>> multiple threads at the same time?
>>
>>
>>
>> Sam Hough wrote:
>> >
>> > Apologies in advance as I'm a newbie harking on about my pet topic
>> again
>> > but...
>> >
>> > Taking the example of TabbedPanel and AjaxTabbedPanel (only in
>> extensions
>> > but a common UI concept) I think it shows why it would be good to use
>> the
>> > factory pattern to generate elemental widgets (like button, panel etc
>> > assuming people want AjaxFallbackButton or Button) and automatically
>> track
>> > dirty components.
>> >
>> > I first got this bee in my bonnet about higher level application code
>> > because I didn't think I should be messing about working out which
>> > components were dirty when I just want the result of pressing a button
>> to
>> > fiddle with the model and change the ui state a bit. However looking at
>> > *TabbedPanel I think it would also make sense for pure UI components.
>> > Using inheritance to add Ajax to TabbedPanel means any other variations
>> > also have to be doubled (e.g. AjaxFancyTabbedPanel and FancyTabbedPanel
>> > etc). Perhaps the bigger problem is that if a Panel that is meant to be
>> > inside a TabbedPanel and needs to alter another component (e.g. update
>> > navigation component) the TabbedPanel has to ask it for changes.
>> > Presumably a component should be self contained as possible so it
>> doesn't
>> > matter what other component it is contained within.
>> >
>> > Factory pattern is a pain but presumably many people don't want the
>> > overhead of AjaxFallbackXXX. It would also make it possible to program
>> > against interfaces which might give more power to Igor, Eelco etc
>> >
>> > Please don't get me wrong GWT is still my true love but Wicket is a
>> > fabulous framework taking us out of the dark ages of struts.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12895965
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: auto dirty and widget factory
Posted by Igor Vaynberg <ig...@gmail.com>.
looks reasonable.
-igor
On 9/12/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Would RequestCycle be the place to keep track of dirty widgets?
>
> Presumably Session can be shared by more than one session and my be used
> by
> multiple threads at the same time?
>
>
>
> Sam Hough wrote:
> >
> > Apologies in advance as I'm a newbie harking on about my pet topic again
> > but...
> >
> > Taking the example of TabbedPanel and AjaxTabbedPanel (only in
> extensions
> > but a common UI concept) I think it shows why it would be good to use
> the
> > factory pattern to generate elemental widgets (like button, panel etc
> > assuming people want AjaxFallbackButton or Button) and automatically
> track
> > dirty components.
> >
> > I first got this bee in my bonnet about higher level application code
> > because I didn't think I should be messing about working out which
> > components were dirty when I just want the result of pressing a button
> to
> > fiddle with the model and change the ui state a bit. However looking at
> > *TabbedPanel I think it would also make sense for pure UI components.
> > Using inheritance to add Ajax to TabbedPanel means any other variations
> > also have to be doubled (e.g. AjaxFancyTabbedPanel and FancyTabbedPanel
> > etc). Perhaps the bigger problem is that if a Panel that is meant to be
> > inside a TabbedPanel and needs to alter another component (e.g. update
> > navigation component) the TabbedPanel has to ask it for changes.
> > Presumably a component should be self contained as possible so it
> doesn't
> > matter what other component it is contained within.
> >
> > Factory pattern is a pain but presumably many people don't want the
> > overhead of AjaxFallbackXXX. It would also make it possible to program
> > against interfaces which might give more power to Igor, Eelco etc
> >
> > Please don't get me wrong GWT is still my true love but Wicket is a
> > fabulous framework taking us out of the dark ages of struts.
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: auto dirty and widget factory
Posted by Sam Hough <sa...@redspr.com>.
Would RequestCycle be the place to keep track of dirty widgets?
Presumably Session can be shared by more than one session and my be used by
multiple threads at the same time?
Sam Hough wrote:
>
> Apologies in advance as I'm a newbie harking on about my pet topic again
> but...
>
> Taking the example of TabbedPanel and AjaxTabbedPanel (only in extensions
> but a common UI concept) I think it shows why it would be good to use the
> factory pattern to generate elemental widgets (like button, panel etc
> assuming people want AjaxFallbackButton or Button) and automatically track
> dirty components.
>
> I first got this bee in my bonnet about higher level application code
> because I didn't think I should be messing about working out which
> components were dirty when I just want the result of pressing a button to
> fiddle with the model and change the ui state a bit. However looking at
> *TabbedPanel I think it would also make sense for pure UI components.
> Using inheritance to add Ajax to TabbedPanel means any other variations
> also have to be doubled (e.g. AjaxFancyTabbedPanel and FancyTabbedPanel
> etc). Perhaps the bigger problem is that if a Panel that is meant to be
> inside a TabbedPanel and needs to alter another component (e.g. update
> navigation component) the TabbedPanel has to ask it for changes.
> Presumably a component should be self contained as possible so it doesn't
> matter what other component it is contained within.
>
> Factory pattern is a pain but presumably many people don't want the
> overhead of AjaxFallbackXXX. It would also make it possible to program
> against interfaces which might give more power to Igor, Eelco etc
>
> Please don't get me wrong GWT is still my true love but Wicket is a
> fabulous framework taking us out of the dark ages of struts.
>
>
>
--
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org