Build: NetBeans IDE Dev (Build 200907130200)
VM: Java HotSpot(TM) Client VM, 1.5.0_19-137, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_19-b02-304
OS: Mac OS X, 10.5.7, i386
mschovanek: Wanted to delete primary inndex at Derby DB
Created attachment 84717 [details]
Since build #1026 (Jul 1, 2009 2:00:37 PM) (#1025 was working correctly) from hlemyzd-2, is not possible to delete any
object in DB explorer due to all destroy action are currently called in AWT but api.MetadataModel.runReadAction supposes
only invocations outside AWT. It's prospective P1 problem at least in DB tooling.
I plan to add another parameter to the actions to allow them to specify asynchronicity. By default off, but when
specified and set to true, it would reschedule the execution to background thread, as used to be the case with
[JG01] Would seem simpler and clearer to me for the action to just call RequestProcessor or whatever itself; magic
attributes should be avoided unless there is a definite need for them (generally in order to defer class loading).
Anyway if you control the action execution directly in code, it is clearer how to run the body inside some lock, use a
ProgressHandle to monitor progress, etc.
Re. JG01. Your comment has been expected. You are well known for your inability to accept XYZAction.asynchronous().
Unfortunately there is no other single place to reschedule anything to RP than in Actions.callback implementation. The
original DeleteAction (and co.) seeks ActionMap and then calls an action found in there on background. It seems to me
that the same has to be done by its Action.callback replacement unless we want to face major incompatibilities (like
I don't think I followed that response. What actual change are you proposing (diff please), and what exactly is the
current incompatibility? Are you proposing an asynch flag only for Actions.callback, or for all the lazy action
factories? If the latter, I am opposed; if the former, I would rather suggest the option of a custom performer which
would be given the real Action (ActionListener? Runnable?) and asked to somehow run it.
Created attachment 85111 [details]
Almost integratable change
Diff provided. Discussion:
1. contains one failing test (marked with XXX) which shows missing implementation in already existing API. I'll deal
with it meanwhile before finishing this review.
2. compatibility - I considered Jesse's "custom performer" but that is not at all necessary to fulfil the primary
goal - e.g. allow new actions to behave the same way the old ones behaved. Actually it is more hurting this goal than
helping to achieve it. The old actions used ActionsBridge for their background execution and the simplest way to
achieve compatibility is to use ActionsBrigdge as well.
3. consistency - The expressed opinion that "for all the lazy action" is bad for "Actions.callback" is acceptable goes
imho against consistency of the API, especially given the fact that callback action is in fact extension of
alwaysEnabled one (can have fallback) and context actions is extension of callback (can have a key). Thus I am
preferring to have consistent attribute in all of these factories.
4. XML vs. Java - right now I propose only XML API for defining asynchronous actions. If I wanted to add similar Java
API compatibly, I would need to duplicate (already many argument) factory methods. That would over-complicate the API.
I do not want to do that, rather I am considering to add ActionBuilder - however that is a topic for another review
(not scheduled right now, but I can speed it up, if there is a preference to have it).
I'd like to integrate tomorrow, then I leave for vacation and I'd like this P2 bug be fixed before that.
Created attachment 85231 [details]
Adjusting the patch to recent removal of context's fallback argument
Integrated into 'main-golden', will be available in build *200907281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #168547: Support for asynchrounous declarative actions and its usage in 'delete' callback action
*** Bug 168069 has been marked as a duplicate of this bug. ***