I'm -0 to add it as enabled by default IDetachListener.
There is no big demand for this. At least I haven't seen many
mails/tickets explaining problems with detaching recently.
Additionally since there is no exact contract for the number of calls
of Component#detach() per request cycle I'd like
A bit late, but I didn't have time to reply this weekend. I think a feature
like this is realy nice, but only if it works in all cases, all the time. You
must be able to rely on Wicket to detach your IDetachable no mather where it
is in your component hierarchy, also when it's not directly
On Fri, Apr 6, 2012 at 18:42, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i wrote a IDetachListener that automatically detaches any IModel
fields found on components. is this something we would be interested
in for core? its been running in production for a while without any
noticeable
i think it would be fine to have something like this, and enabled by default
but only to have an option to turn it off
On Sat, Apr 7, 2012 at 22:30, Igor Vaynberg igor.vaynb...@gmail.com wrote:
-1 on adding it if its not enabled by default. its a trivial class
thats only about 40-50 lines of
Once this is introduced you can't turn it off.
You might use some components which depend on their models being
detached externally, without you even being aware of it.
Sven
On 04/08/2012 12:15 PM, Johan Compagner wrote:
i think it would be fine to have something like this, and enabled by
The user would have to turn it off via settings.
Sent from tablet device. Please excuse typos and brevity.
On Apr 8, 2012 6:28 AM, Sven Meier s...@meiers.net wrote:
Once this is introduced you can't turn it off.
You might use some components which depend on their models being detached
Oh, sorry I didn't understand what you meant. Yeah that is a nasty
scenario. I would much rather implement this as an aspect if it were me.
Wicket should have a library of useful aspects like this.
Sent from tablet device. Please excuse typos and brevity.
On Apr 8, 2012 10:03 AM, James Carman
like i said, this only makes sense as a core features. because
components implemented with this enabled will not work properly in an
application where this is enabled. this is an all-or-nothing feature.
-igor
On Sun, Apr 8, 2012 at 3:15 AM, Johan Compagner jcompag...@gmail.com wrote:
i think it
I think it should be an optional add-on (if included in the library at
all), so that core/extensions components won't rely on it, and
application developers may use it if they want the convenience. It is
just a convenience, after all.
If it is enabled by default, it may cause really weird,
s/where this is enabled/where this is disabled/
-igor
On Sun, Apr 8, 2012 at 8:51 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
like i said, this only makes sense as a core features. because
components implemented with this enabled will not work properly in an
application where this is
The listener won't be set in IFrameworkSettings by default, right?
IMHO it's better located in extensions then.
Sven
On 04/07/2012 01:37 AM, James Carman wrote:
Add the listener to core and if folks want to use it they can. You could
have a component instantiation listener add the detach
-1 on adding it if its not enabled by default. its a trivial class
thats only about 40-50 lines of real code. adding it into extensions
and not using it will just add to code rot because i doubt many people
will go out looking for something like this since most of them wont
even know that its
At first glance I'm torn about this, to be honest. On the one hand,
yes, not having to do that would be neat. On the other hand, that makes
models even more magic to new users, and not obvious what happens.
Especially if you create a model in e.g. your constructor and just
reference it a method of
I wish there were a way to apply this strategy to the whole object graph
(not just fields). I use local final LoadableDetachableModels on occasion,
and it'd be nice for those to magically detach too. I'm +0.
Just got Calc-Eric's message. Looks like we're on the same page.
On Fri, Apr 6, 2012 at
Sorry to double-post, but I realized it's trivial to visit the object graph
since local final variables show up as fields in the inner class. This
following snippet prints detaching. So what do you think about
generalizing the automatic detach to all objects, not just components?
final IModel
actually all variables referenced in such manner become fields of the
anonymous class and are accessible via reflection.
-igor
On Fri, Apr 6, 2012 at 10:23 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
At first glance I'm torn about this, to be honest. On the one hand,
yes, not having to
its easy to enable detaching of any IDetachable field rather then only
IModel. this code can also walk behaviors, but i dont think it should
go beyond that. walking the entire object graph will be too expensive.
right now it performs a lot of caching which makes it work well.
-igor
On Fri, Apr
+1 Having IDetachable items detached by default makes sense
On Fri, Apr 6, 2012 at 10:56 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
its easy to enable detaching of any IDetachable field rather then only
IModel. this code can also walk behaviors, but i dont think it should
go beyond
-1, what if I don't want this feature? this makes models even more complex
to understand. I would rather check, whether detachables aren't detached an
log it. but I don't like the idea of taking actions directly.
regards
martin
Am 06.04.2012 20:01 schrieb Ryan McKinley ryan...@gmail.com:
+1
Yeah, IDetachable is better. Full graph traversal is only incrementally
worse that that required for serialization. It also happens after the
request.
A negative consideration: after making a change that requires components to
redetermine their models' cached states, it's nice to rely on direct
On Fri, 6 Apr 2012 10:48:35 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:
actually all variables referenced in such manner become fields of the
anonymous class and are accessible via reflection.
I wasn't sure about that so before I posted my reply I did an
admittedly naive test. The
Add the listener to core and if folks want to use it they can. You could
have a component instantiation listener add the detach listener to the
components. Another option would be an aspect.
On Apr 6, 2012 12:43 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i wrote a IDetachListener that
22 matches
Mail list logo
