Clean-up registries in dispatch

[GoogleCodeExporter]

The dispatch module uses a registry mechanism to map actions to handlers 
(and, soon, actions to security validators).

This mechanism is built to allow the user to choose between a lazy registry 
(where handlers and validators are only instantiated when needed) and a 
simple registry (where they are instantiated right away). By default, the 
simple registry is used.

This has a drawback however: all actions and/or all validators must use the 
same registry mechanism. Moreover, it results in a bunch of classes and 
interfaces that are difficult to track and the need for "instanceof" checks 
in the linkers. Given the current API, I think it is very unlikely somebody 
will switch to a lazy registry.

I have an idea to radically simplify this however, here's how:
- Have a single registry type (same registry for handlers and validators)
- The registry will have different methods for the different types of 
registration:
    addHandler( h );     // NonLazy handler, no validator
    addHandler( h, v );  // NonLazy handler, NonLazy validator
    addHandler( hC );    // Lazy handler, no validator
    addHandler( hC, v ); // Lazy handler, NonLazy validator
    addHandler( h, vC ); // NonLazy handler, Lazy validator
    addHandler( hC, vC );// Lazy handler, Lazy validator

Original issue reported on code.google.com by philippe.beaudoin on 23 Apr 2010 at 11:21

[GoogleCodeExporter]

The current implementation of the lazy registry need to be reworked, though. As 
it is, 
it will create a new instance of the handler every time it is needed, unless 
its 
explicitely marked as @Singleton.

Original comment by philippe.beaudoin on 23 Apr 2010 at 11:31

[GoogleCodeExporter]

Something that would simplifies things a lot is to bind validator at startup 
instead 
of lazily instantiate them.

There is two question I asked myself to come to this conclusion. How many 
validators 
I user would likely have ? 2-3 max. Personnaly I use two secure context and one 
unsecure.  Admins, users, guest.

Second questin, are validators expensive to create ? Not really. Maybe a right 
system 
would be more expensive to create, but even then, we don't do any validation 
when the 
class is first loaded. So every "expensive" action are done while validating 
the user 
action through execute.

Original comment by goudreau...@gmail.com on 24 Apr 2010 at 12:33

[GoogleCodeExporter]

Yes, I'm not convinced lazy validators are required. It probably make sense for 
actions, though, as there will likely be a lot and you want to reduce cold 
start, so 
I still want to figure a nicer solution than the actual one, which is "all 
lazy" or 
"all standard".

Here is another possible cleanup:

Right now, DispatchModule.bindHandler() binds multiple objects to 
ActionHandlerMap 
(via a UniqueAnnotations). The Linker then uses injector.findBindingsByType to 
identify all the ActionHandlerMap bindings and register them with the registry.

There is probably a way to get rid of this double process and register objects 
directly in bindHandler()... Although it might force us to _only_ use lazy 
validators 
and lazy handlers. If we really want nonlazy, then the linker could simply go 
through 
the list of registered handlers/validators and instantiate the nonlazy ones. 
I.e. 
Everything would be lazy, but some lazy would be instantiated at app start.

Original comment by philippe.beaudoin on 24 Apr 2010 at 5:08

[GoogleCodeExporter]

I really think uniqueAnnotation is something we must keep. With that, we can 
bind every 
different action to every different actionhandler while using the same 
Interface for 
every single one of them while keeping the right binding.

If we get rid of that, how would you do that instead ?

Original comment by goudreau...@gmail.com on 24 Apr 2010 at 6:46

[GoogleCodeExporter]

The unique annotation is just a way to pass information from the binder to the 
linker. 
I don't think it's the best way to do this, and David Peterson seems to agree:
http://groups.google.com/group/gwt-dispatch/browse_frm/thread/ce1dd9c91d9e0b4b

Original comment by philippe.beaudoin on 24 Apr 2010 at 6:55

[GoogleCodeExporter]

Original comment by goudreau...@gmail.com on 17 May 2010 at 12:03

• Changed state: Started

[GoogleCodeExporter]

Original comment by goudreau...@gmail.com on 18 May 2010 at 6:45

• Added labels: needReview

[GoogleCodeExporter]

Original comment by goudreau...@gmail.com on 18 May 2010 at 6:52

[GoogleCodeExporter]

Original comment by goudreau...@gmail.com on 25 May 2010 at 6:39

• Changed state: Done