ez projects / ymclibrary
|UNIX name||Owner||Status||Version||Compatible with|
his class allows the encapsulation of any script logic into a class. Custom code can be implemented into the method doJob() of a subclass and then run via the generic starter script ymclibrary/bin/ymc-run.php.
Additionally this class provides some simple transaction support, allowing for stopping scripts using normal unix signals, thus preventing undefined states and inconsistent data.
An example can be found in the class ymcNullCLIScript.
This class provides wrapper and helper methods helpful for interacting with the ez publish kernel. Can be seen as a facade. (http://en.wikipedia.org/wiki/Facade_pattern)
Using such facade methods in custom code simplifies the task of making code work with future eZ Publish kernel versions. Furthermore, the provided methods simplify several complex ez publish kernel tasks, that speed up development.
Additionally a handler is introduced, which allows to plug in specific actions before or after common tasks are executed using the provided methods. See description of ymcEZeasyHandlers for more information.
The ymcEZeasyHandler system allows custom code to be plugged in before or after tasks are executed using the ymcEZeasy facade. None, one, or multiple handlers can be configured in ymcezeasy.ini.
Some triggers are:
For a full list of all available handler methods, take a look at the class ymcEZeasyNullHandler.
Combined with the extension- and INI-loading logic that are provided by the extension "ymcExtensionloader for ez Pubilsh", customer-specific actions can be implemented in custom handlers. Defining common sets for several customers are possible, too.
This is a generic NULL object implementation, comparable to the NULL object pattern. Using it (instead of the value NULL) makes it save to write code like the following.
$a->attribute( 'parent' )->attribute( 'object' );
Without ymcNullObject you will run into a fatal error, if the first function call does not return an object implementing a method called 'attribute'. Using the ymcNullObject you won't run in such fatal errors.
NOTE: You should still check the end result!
NOTE: You should consider using a special NULL object implemented against an interface. This can be useful if a special dummy implementation like a nullLogger or nullWriter shall simulate a special behaviour.
See http://en.wikipedia.org/wiki/Null_Object_pattern for more general information.
Provides several static functions with simple checks and logging support.
The static functions provided by this class supersede repeated blocks of
if( ... )
ymcObjectChecks::checkIsValidContentNode( $variableToTest ) checks, if $variableToTest references an object that is an instance of class eZContentObjectTreeNode.
This results in standardized logging messages and much better human readable code.
Provides an identity map for eZPersistentObject instances. See http://en.wikipedia.org/wiki/Identity_map for more general information. Additionally, it properly casts all members to their defined data type. This solves the problem that the standard ezpersistentobject.php will return anything as a string.
NOTE: To use this functionality, a small patch against the original ezpersistentobject.php is required. If you do not want to patch eZ Publish yourself you might want to take a look into the extension "ymcBootstrap for ez Pubilsh".
Extending this class, objects provide the same attribute access pattern like eZPersistentObject does. There is no need to manually code the method triple "hasAttribute, attributes, attribute" over and over again by yourself. Objects extending ymcSimpleAttributeClass therefor provide the dot notation inside templates like other built-in ez publish objects.
All you need to implement in your subclass is a function called simpleAttributes() providing a mapping of attribute names to object members or methods.