On 10/1/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>
> Are Component.onAttach and onDetach legitimate places for customising wicket
> behaviour?
Yep.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mai
n 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
child, settting the visibility, or setting an internal none
>> wicket
>> > >> core
>> > >> >> property)
>> > >> >>
>> > >> >> johan
>> > >> >>
>> > >> >>
>> > >&
ettting the visibility, or setting an internal none wicket
> > >> core
> > >> >> property)
> > >> >>
> > >> >> johan
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 9/26/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > >> >> &g
> >> >> On 9/26/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >> >> >
> >> >> > On 9/26/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >> >> > > but this discussion is not just about getter/setters (i don't care
> >> >> about
> >> >> &g
/26/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >> >> > > but this discussion is not just about getter/setters (i don't care
> >> >> about
> >> >> > > those)
> >> >> > > but also for add and remove.
rs (i don't care
>> >> about
>> >> > > those)
>> >> > > but also for add and remove.. then we are getting into some other
>> >> stuff
>> >> >
>> >> > Yes. Getters/ setters are
t;> >> > > 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
>> >&
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.
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
remove.
> >> >
> >> > Eelco
> >> >
> >> > -
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
; >> > in sweat when I imagine removing final on add and remove.
> >> >
> >> > Eelco
> >> >
> >> >
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>
> ---
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
prob
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 <[EMAIL PROTECTED]> wrote:
> On 9/27/07, Johan Compagn
On 9/29/07, Igor Vaynberg <[EMAIL PROTECTED]> 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 ser
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 <[EMAIL PROTECTED]> wrote:
> but then still w
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() jus
or just getPage().dirty();
-igor
On 9/28/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
> newVersion();
> looks much better to me than addStateChange(new
> ChangeThatIsNotUsedAnyway() { public void undo() });
>
> -Matej
>
> On 9/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > yes we do
>
but then still we have the event..
johan
On 9/29/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
> newVersion();
> looks much better to me than addStateChange(new
> ChangeThatIsNotUsedAnyway() { public void undo() });
>
> -Matej
>
> On 9/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > ye
newVersion();
looks much better to me than addStateChange(new
ChangeThatIsNotUsedAnyway() { public void undo() });
-Matej
On 9/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yes we do
> we use it still extensively
> we dont cache the changes anymore those are gone, but we still uses it t
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 <[EMAIL PROTECTED]> wrote:
>
> On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > the problem is th
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 <[EMAIL PROTECTED]> wrote:
>
> On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > the problem is that that still not really does auto dirty..
On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> 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 to
;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.
>> >
---------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dir
ugh I'm still not breaking
> in sweat when I imagine removing final on add and remove.
>
> Eelco
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
&
t;
>> >> 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
r 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
d 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.
&g
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
componentC
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917546
> Sent fr
---
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.h
On 9/26/07, Johan Compagner <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote:
>
> On 9/26/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > I disagree. We nee
On 9/26/07, Martijn Dashorst <[EMAIL PROTECTED]> 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 th
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
On 9/26/07, Igor Vaynberg <[EMAIL PROTECTED]> 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 abou
> > 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 lis
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 fr
anel 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 compon
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 comp
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: [EMAIL PROTECTED
>> > 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 A
ntained 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
e 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 l
y 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 l
47 matches
Mail list logo
