Instead of defining a class for each Action, they can be derived from methods signatures.
Then hanlder of those actions then destructs the objects onto the parameters.9
Action requests are prepared, executed and then either the result is shown or the user is redirected to the last Action.6
An Action gets published over the ActionDispatcher and the result is passed back.5
The Representer of class
null is the root Representer. It's actions are listed by IndexResource.
Actions can have properties which have to be filled before executing the Action.
This is done by assigning request parameters to the properties of the Action. Missing properties are requested from the user. Properties are determined with public instance variables and setter methods.9
Actions are executed and the object or array ob objects presented together with their actions.9
The only reason a form is ever presented is to fill the missing properties of an Action during preparation.10
This project was replaced by rtens/domin and will no longer be maintained.
Administration interface using the Command Object pattern.
For a detailed overview of qrator's features and API, check out its executable documentation.
The project completely functional but still under heavy development which is driven by a project I'm currently working on. Once I deem qrator as stable enough I'll tag a release and provide some documentation on how to use it.
Until then check out the Demo project.
A couple of weeks ago a client asked me to find a general purpose administration interface that could be used for several projects. But I couldn't find a single one that wouldn't just bypass my application and domain layers completely and talk directly to the storage system.
So I started designing an admin interface that was compatible with Domain-Driven Design and hence could also manage entities in projects that implemented Command/Query Segregation or Event Sourcing. Born was qrator.
These are the building blocks and their meanings in qrator.
An entity is any class that represents a part of your system whose state you would like to manage. Its properties are derived from the instance variables, getter and setter methods, and displayed whenever one or several entities is the result of an action.
Actions are something you can do with an entity. They are always attached to some entity and displayed whenever the entity is displayed. If an action returns something, it is displayed as the query's result.
Usually, an action either changes the state of an entity and returns nothing (i.e. Command) or returns one or several entities but changes no state (i.e. Query).
Actions can have properties as well which are rendered as form fields for the user to fill out if necessary.
Since Entities and Actions belong to the Domain layer and are thus independent of qrator, EntityRepresenters and ActionRepresenters bind them together. It knows what Actions belong to what Entities, how to instantiate and execute them, how to print them and so on.
The RepresenterRegistry knows what Representers represent which class of the Domain layer. It is the single place for the whole qrator configuration.