2016-07-11 9 views
0

Ich biete eine Spring State Machine mit grundlegenden Programmzuständen in einer Bibliothek als Basis für verschiedene Implementierungen. Hinzufügen von benutzerdefinierten Übergangsaktionen abhängig von der aktuellen Implementierung mit der grundlegenden StateMachine, scheint einfach zu sein wegen der bereitgestellten .Wie erreicht man implementierungsabhängige Übergangswächter für eine Spring-Maschine in einer Bibliothek?

Jetzt möchte ich etwas ähnliches mit Wachen, d. H. bieten einen Übergangswächter je nach dem aktuellen Nutzungsszenario innerhalb der Implementierung mit der grundlegenden StateMachine.

Eine Idee ist configure ein Standard-guard innerhalb der Grundstate die das Decorator-Muster Umsetzung ist, das heißt, es ist ein Wrapper die Wache Schnittstelle um eine andere Wache gewickelt zu implementieren. Als Standardwächter wird eine einfache Wächterimplementierung verwendet, die für die Auswertemethode immer wahr zurückgibt.

-Code-Schnipsel in etwa so aussehen ... zuerst die Wachen:

import org.springframework.statemachine.StateContext; 
import org.springframework.statemachine.guard.Guard; 
// ... custom States and Events imports 

public class GuardDecorator implements Guard<States, Events> { 

    private Guard<States, Events> guard; 

    public GuardDecorator() { 
     this.guard = new DefaultGuard(); 
    } 

    public GuardDecorator(Guard<States, Events> guard) { 
     this.guard = guard; 
    } 

    public void setGuard(Guard<States, Events> guard) { 
     this.guard = guard; 
    } 

    public String wrappedGuardInfo() { 
     return this.guard.toString(); 
    } 

    @Override 
    public boolean evaluate(StateContext<States, Events> context) { 
     return this.guard.evaluate(context); 
    } 
} 

public class DefaultGuard implements Guard<States, Events> { 
    @Override 
    public boolean evaluate(StateContext<States, Events> context) { 
     return true; 
    } 
} 

nun den GuardDecorator im State Konfigurator (Auszug nur) mit:

// ... 
@Bean 
public GuardDecorator guard() { 
    return new GuardDecorator(); 
} 
// ... 
@Override 
public void configure(
    StateMachineTransitionConfigurer<States, Events> transitions) 
    throws Exception { 

    transitions.withExternal() 
     .source(States.S1) 
     .target(States.S2) 
     .event(Events.E1) 
     .guard(guard()); 
    } 
// ... 

Meine Fragen sind nun:

  • Habe ich etwas in der Dokumentation vermisst, ist das e ein eingebauter Weg, dies zu tun?
  • Beliebige andere Lösungen, um eine Implementierung abhängige Schutz für eine grundlegende StateMachine innerhalb einer Bibliothek zur Verfügung gestellt bekommen?

Antwort

1

Es gibt nichts eingebaut, aber nicht sicher, ob es sein muss. Wenn Sie diese Konfiguration auf JavaConfig basiert tun, könnten Sie Standard Wache dort erstellen und erlaubt dem Anwender optional überschriebene Implementierung

Autowired(required=false) 
@Qualifier("myGuard") 
Guard<States, Events> guard; 

Oder so dass Benutzer autowire Bean Definition selbst außer Kraft zu setzen. Wenn dieselbe Bean in mehreren Konfigurationsklassen erstellt wird, gewinnt die letzte aufgelöste Reihenfolge. Dieses Konzept wird in Spring-Umbrella-Projekten häufig verwendet, wo Standard-Bean existiert, aber von einem Benutzer überschrieben werden darf.

@Bean(name="myGuard") 
public GuardDecorator guard() { 
    return new GuardDecorator(); 
} 
+0

Vielen Dank, ich war auf der Suche nach so etwas! Die Verwendung einer Standard-Bean ist eine praktikable Option für mich und wahrscheinlich einfacher zu verstehen und zu warten. Ich wusste es bis jetzt nicht. Meiner Meinung nach macht dies eine Art Federspeichereinbau-Lösung überflüssig, da es bereits einen allgemeineren Weg gibt. – l00tr