ext direct
2.0.0
Eine Basiskomponente zur Integration von Sencha Ext JS Ext.direct in eine PHP-Anwendung
Diese Bibliothek bietet eine serverseitige Implementierung für Sencha Ext.direct, eine Kommunikationskomponente im RPC-Stil, die Teil von Senchas Ext JS und Sencha Touch ist.
ext direct ist ein plattform- und sprachunabhängiges RPC-Protokoll (Remote Procedure Call). ext direct ermöglicht eine nahtlose Kommunikation zwischen der Clientseite einer Ext JS-Anwendung und jeder Serverplattform, die der Spezifikation entspricht. ext direct ist zustandslos und leichtgewichtig und unterstützt Funktionen wie API-Erkennung, Aufruf-Batching und Server-zu-Client-Ereignisse.
Derzeit wird diese Bibliothek nur als Grundlage von teqneers/ext-direct-bundle verwendet, einem Symfony-Bundle, das * Ext.direct* in eine Symfony-basierte Anwendung integriert. Wir haben nicht versucht, die Bibliothek als eigenständige Komponente oder in einem anderen Kontext als einer Symfony-Umgebung zu verwenden. Im Folgenden erfahren Sie daher nur, wie sie theoretisch ohne das Bundle funktionieren sollte. Wir würden uns über jede Hilfe und jeden Beitrag freuen, um die Bibliothek außerhalb des Pakets nützlicher zu machen.
Sie können diese Bibliothek mit Composer installieren
composer require teqneers/ext-direct
oder fügen Sie das Paket direkt zu Ihrer Composer.json-Datei hinzu.
Die Benennungsstrategie bestimmt, wie PHP-Klassennamen und Namespaces in Javascript-kompatible Ext.direct- Aktionsnamen übersetzt werden. Die Standardbenennungsstrategie übersetzt das Trennzeichen namspapce in ein . . Also wird MyNamespaceService in My.namespace.Service übersetzt. Bitte beachten Sie, dass die Transformation umkehrbar sein muss ( My.namespace.Service => MyNamespaceService ).
$ namingStrategy = new TQ ExtDirect Service DefaultNamingStrategy (); Die Dienstregistrierung verwendet eine Metadatenfabrik aus der jms/metadata Bibliothek und einen zugehörigen Annotationstreiber (der wiederum einen doctrine/annotations Annotationsreader verwendet), um Metainformationen über mögliche annotierte Serviceklassen zu lesen.
$ serviceRegistry = new TQ ExtDirect Service DefaultServiceRegistry (
new Metadata MetadataFactory (
new TQ ExtDirect Metadata Driver AnnotationDriver (
new Doctrine Common Annotations AnnotationReader ()
)
),
$ namingStrategy
); Die Dienstregistrierung kann manuell durch Aufrufen addServices() oder addService() oder durch Importieren von Diensten mithilfe eines TQExtDirectServiceServiceLoader gefüllt werden. Die Standardimplementierung TQExtDirectServicePathServiceLoader kann Klassen aus einem Satz gegebener Pfade lesen.
Der Ereignis-Dispatcher ist optional, ist jedoch erforderlich, um Funktionen wie Argumentkonvertierung und -validierung sowie Ergebniskonvertierung des Profiling-Listeners zu verwenden.
$ eventDispatcher = new Symfony Component EventDispatcher EventDispatcher (); Der Router wird verwendet, um eingehende Ext.direct- Anfragen in PHP-Methodenaufrufe an die richtige Serviceklasse zu übersetzen. Die ContainerServiceFactory unterstützt das Abrufen von Diensten aus einem Symfony-Abhängigkeitsinjektionscontainer oder das Instanziieren einfacher Dienste, die überhaupt keine Konstruktorargumente benötigen. Statische Serviceaufrufe umgehen die Service Factory.
$ router = new TQ ExtDirect Router Router (
new TQ ExtDirect Router ServiceResolver (
$ serviceRegistry ,
new TQ ExtDirect Service ContainerServiceFactory (
/* a SymfonyComponentDependencyInjectionContainerInterface */
)
),
$ eventDispatcher
); Das Endpunktobjekt ist eine Fassade vor allen serverseitigen Ext.direct -Komponenten. Mit seiner Methode createServiceDescription() kann man eine standardkonforme API-Beschreibung erhalten, während handleRequest() einen SymfonyComponentHttpFoundationRequest entgegennimmt und einen SymfonyComponentHttpFoundationResponse zurückgibt, der die Ext.direct -Antwort für die Serviceaufrufe enthält erhalten.
$ endpoint = TQ ExtDirect Service Endpoint (
' default ' , // endpoint id
new TQ ExtDirect Description ServiceDescriptionFactory (
$ serviceRegistry ,
' My.api ' ,
$ router ,
new TQ ExtDirect Router RequestFactory (),
' My.api.REMOTING_API '
)
);Der Endpunkt-Manager ist lediglich eine einfache Sammlung von Endpunkten, die den Abruf mithilfe der Endpunkt-ID ermöglichen. Dies ermöglicht die einfache Bereitstellung mehrerer unabhängiger APIs.
$ manager = new TQ ExtDirect Service EndpointManager ();
$ manager -> addEndpoint ( $ endpoint );
$ defaultEndpoint = $ manager -> getEndpoint ( ' default ' );
$ apiResponse = $ defaultEndpoint -> createServiceDescription ( ' /path/to/router ' );
$ apiResponse -> send ();
$ request = Symfony Component HttpFoundation Request:: createFromGlobals ();
$ response = $ defaultEndpoint -> handleRequest ( $ request );
$ response -> send ();Der Routing-Prozess kann manipuliert und erweitert werden, indem Ereignis-Listener für den an den Router übergebenen Ereignis-Dispatcher verwendet werden. Die Bibliothek stellt vier Ereignisabonnenten bereit, die dies ermöglichen
Die mitgelieferten Argument- und Ergebniskonverter nutzen die Bibliothek jms/serializer , um erweiterte (De-)Serialisierungsfunktionen bereitzustellen, während der Standardargumentvalidator die Bibliothek symfony/validator nutzt.
$ eventDispatcher -> addSubscriber (
new TQ ExtDirect Router EventListener ArgumentConversionListener (
new TQ ExtDirect Router ArgumentConverter ( /* a JMSSerializerSerializer */ )
)
);
$ eventDispatcher -> addSubscriber (
new TQ ExtDirect Router EventListener ArgumentValidationListener (
new TQ ExtDirect Router ArgumentValidator ( /* a SymfonyComponentValidatorValidatorValidatorInterface */ )
)
);
$ eventDispatcher -> addSubscriber (
new TQ ExtDirect Router EventListener ResultConversionListener (
new TQ ExtDirect Router ResultConverter ( /* a JMSSerializerSerializer */ )
)
);
$ eventDispatcher -> addSubscriber (
new TQ ExtDirect Router EventListener StopwatchListener (
/* a SymfonyComponentStopwatchStopwatch */
)
);Dienste, die über die Ext.direct -API verfügbar gemacht werden sollen, müssen mit entsprechenden Metainformationen versehen sein. Derzeit ist dies nur mithilfe von Annotationen (wie man sie aus Doctrine, Symfony oder anderen modernen PHP-Bibliotheken kennt) möglich.
Jede Serviceklasse, die als Ext.direct -Aktion verfügbar gemacht wird, muss mit TQExtDirectAnnotationAction annotiert werden. Die Action Annotation akzeptiert optional einen Service-ID-Parameter für Services, die weder statisch sind noch mit einem Konstruktor ohne Parameter instanziiert werden können.
use TQ ExtDirect Annotation as Direct ;
/**
* @DirectAction()
*/
class Service1
{
// service will be instantiated using the parameter-less constructor if called method is not static
}
/**
* @DirectAction("app.direct.service2")
*/
class Service2
{
// service will be retrieved from the dependency injection container using id "app.direct.service2" if called method is not static
} Darüber hinaus muss jede Methode, die bei einer Ext.direct -Aktion verfügbar gemacht werden soll, mit TQExtDirectAnnotationMethod annotiert werden. Die Method nimmt optional entweder true an, um die Methode als Formularhandler zu kennzeichnen (der reguläre Formularbeiträge entgegennimmt), oder false , um die Methode als reguläre Ext.direct- Methode zu kennzeichnen (dies ist die Standardeinstellung).
/**
* @DirectAction("app.direct.service3")
*/
class Service3
{
/**
* @DirectMethod()
*/
public function methodA ()
{
// regular method
}
/**
* @DirectMethod(true)
*/
public function methodB ()
{
// form handler method
}
}Erweiterte Funktionen wie benannte Parameter und streng benannte Parameter, die in der Ext.direct- Spezifikation beschrieben werden, werden derzeit nicht über das Annotationssystem verfügbar gemacht.
Parameter, die in eine Methode eingehen, die über eine Ext.direct -Anfrage aufgerufen wird, können ebenfalls mit Anmerkungen versehen werden, um eine Parametervalidierung anzuwenden. Dies erfordert, dass TQExtDirectRouterEventListenerArgumentValidationListener beim entsprechenden Ereignis-Dispatcher registriert ist.
use Symfony Component Validator Constraints as Assert ;
/**
* @DirectAction("app.direct.service4")
*/
class Service4
{
/**
* @DirectMethod()
* @DirectParameter("a", { @AssertNotNull(), @AssertType("int") })
*
* @param int $a
*/
public function methodA ( $ a )
{
}
} Wenn die Signatur der aufgerufenen Methode Parameter mit einem Typhinweis für SymfonyComponentHttpFoundationRequest und/oder TQExtDirectRouterRequest , die eingehende Symfony-HTTP-Anfrage und/oder das rohe Ext.direct offenlegt Die Anfrage wird automatisch in den Methodenaufruf eingefügt. Dies ist besonders wichtig für Formularverarbeitungsmethoden, da es keine andere Möglichkeit gibt, auf die eingehenden HTTP-Anfrageparameter (Formularpost) zuzugreifen.
Sobald der TQExtDirectRouterEventListenerArgumentConversionListener aktiviert ist, können streng typisierte Objektparameter für Dienstmethoden verwendet werden. Diese Argumente werden automatisch aus der eingehenden JSON-Anfrage deserialisiert und in den Methodenaufruf eingefügt.
Das Gleiche gilt für die Rückgabe von Objekten aus einem Dienstmethodenaufruf. Wenn TQExtDirectRouterEventListenerResultConversionListener aktiviert ist, werden Rückgabewerte automatisch in JSON serialisiert, auch wenn es sich um nicht triviale Objekte handelt.
Sowohl das Argument als auch die Rückgabewertkonvertierung basieren auf der hervorragenden jms/serializer -Bibliothek von Johannes Schmitt. Weitere Informationen finden Sie in der Dokumentation.
Die ext direct -Spezifikation finden Sie auf der Dokumentationswebsite von Sencha.
Die MIT-Lizenz (MIT)
Copyright (c) 2015 TEQneers GmbH & Co. KG
Hiermit wird jeder Person, die eine Kopie dieser Software und der zugehörigen Dokumentationsdateien (die „Software“) erhält, kostenlos die Erlaubnis erteilt, mit der Software ohne Einschränkung zu handeln, einschließlich und ohne Einschränkung der Rechte zur Nutzung, zum Kopieren, Ändern und Zusammenführen , Kopien der Software zu veröffentlichen, zu verteilen, unterzulizenzieren und/oder zu verkaufen und Personen, denen die Software zur Verfügung gestellt wird, dies zu gestatten, vorbehaltlich der folgenden Bedingungen:
Der obige Urheberrechtshinweis und dieser Genehmigungshinweis müssen in allen Kopien oder wesentlichen Teilen der Software enthalten sein.
DIE SOFTWARE WIRD „WIE BESEHEN“ ZUR VERFÜGUNG GESTELLT, OHNE JEGLICHE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GEWÄHRLEISTUNG, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG. IN KEINEM FALL SIND DIE AUTOREN ODER URHEBERRECHTSINHABER HAFTBAR FÜR JEGLICHE ANSPRÜCHE, SCHÄDEN ODER ANDERE HAFTUNG, WEDER AUS EINER VERTRAGLICHEN HANDLUNG, AUS HANDLUNG ODER ANDERWEITIG, DIE SICH AUS, AUS ODER IN ZUSAMMENHANG MIT DER SOFTWARE ODER DER NUTZUNG ODER ANDEREN HANDELN IN DER SOFTWARE ERGEBEN SOFTWARE.
