Ideas for an eZModuleInterface

Tuesday 02 February 2010 1:14:03 am

First, I'd point out that I'm quite new to eZ Publish, and I only have experience with 4.2.

But one of the first things I thought of when creating my first module, was "why do I have to declare all this variables, why not just declare a class that implements a eZModuleInterface?".

I did a few changes in the eZModule class that enables a class definition in module.php instead of the normal variables (Module, ViewList and FunctionList).

The class is very simple, it implements eZModuleInterface with three public methods: getModule, getViewList and getFunctionList, which should all return arrays with the usual content, nnd the name of the class has to follow the convention modulename_ezModule.

Here's the interface:

interface eZModuleInterface
{
    public function getModule();

    public function getViewList();

    public function getFunctionList();
}

And an example class:

class my_module_eZModule implements eZModuleInterface
{

    public function getModule()
    {
        return array( 'name' => 'Module name' );
    }

    public function getViewList()
    {
        return array(
                'main' => array(
                    'functions' => array(  ),
                    'script' => 'main.php'
                ));
    }

    public function getFunctionList()
    {
        return array();
    }
}

The change in ezmodule.php is quite minor, and I can post that as well if there's any interest in it, but the important thing is that the change is and should be compatible with the normal way of defining modules.

This is just a quick outline, I'm sure a module class/interface can do a lot more than the above, but my experience is limited, and I could use some input on this.

What do you think? Any point in spending any more time on this?

Tuesday 02 February 2010 1:34:59 am

Hallo Peter !

Welcome aboard the eZ Community, and thanks for this awesome post :)

I love this idea. This actually turns the currently 'include'-based module definitions into a proper object-oriented system, and this is not nothing. One of the immediate consequences is that it reduces the amount of required workarounds and hacks in the kernel, which leaves a larger room for maintenance-peace and tranquility: upgrades, automatic bugfixing (eZ Premium).

Have you pushed this in production yet ? Any other magical enhancements proposals like this one ?

Cheers,
PS : not sure you already did this, but check the "Track this reply" checkbox next to the "OK | "Cancel" buttons below, so that you are automatically notified when someone replies to your threads. You can also check your notification settings there : http://share.ez.no/notification/settings

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Tuesday 02 February 2010 2:08:07 am

That's a great idea !

Methods to hook easily could be great too !

--
eZ certified developer: http://ez.no/certification/verify/346216

Tuesday 02 February 2010 5:46:16 am

Another ting... aren't the 'views' of eZ Publish more like a 'controller' if you think about the traditional sense of MVC?

So why not create some type of controller class with actions and have eZProcess execute them as objects instead? Or just leave eZProcess alone and write another class, say eZDispatch, that's used if the 'view' file contains a class.

Guess you should be careful with tampering with the terminology, but at least I think it's easier to think of the views as controllers.

I searched around a bit and found a few MVC tools in ez components. Is that something that could be used for this, or would that introduce too many unwanted dependencies to ezc?

Friday 23 April 2010 1:53:13 pm

@Peter I played a bit more with module introspection, and I think I might have missed the overall sense in your original post.

The first thing I want to say is that the current ezmodule class has attributes that can be used to retrieve from it the list of views; it really misses one to retrieve the list of fetch functions though!

To have a module defined via a php class, we should, imho

- rename your interface to ezmoduleimplementorInterface or ezmoduleDefinitionInterface, as it is not a module in itself you are implementing, the module being the instance of ezmodule

- maybe add a new ini setting to declare which modules use the new interface instead of module.php, instead of using the automatic 'try loading class first' approach

Principal Consultant International Business
Member of the Community Project Board

Saturday 24 April 2010 10:37:58 am

@kristof: I longed a while ago for replacing module.php and also the definition of template operators and functions with ini files. Then I stumbled upon some module that dynamically created the available views and I understood the benefit of having it done in php.

I personally am not a big fan of xml - a hybrid format too hard and verbose to be read/written by humans and too complex to be efficiently parsed by machines. In 2010 you see more and more json, yaml and other simpler markup formats that are suited to represent data and less and less xml.

But moving between a php array and json/xml is a matter of 2 lines of code

What I'd like instead is

- more docs on the possible values for those arrays - most of those are hidden and never documented anywhere

- some validator script / function

Principal Consultant International Business
Member of the Community Project Board

Sunday 25 April 2010 2:20:04 am

I just LOVE your idea Peter !

Besides, you're right, module views are MVC controllers and they also should be classes (like in Symfony framework). It would be much cleaner IMHO !

@Kristof : Your idea is really interesting too ;). Writing module definition is really annoying, such as for template operators, fetch functions or operations ! From this point of view I'd rather prefer YAML vs XML, plus a PHP class (extending eZModule and implementing an interface) for module views (we really should call them controllers as it's quite confusing).

Sunday 25 April 2010 4:08:15 am

Ps: my fave one: json + jsonschema

Principal Consultant International Business
Member of the Community Project Board

Sunday 25 April 2010 6:21:47 am

@Gaetano: I am not talking here about copying and pasting code, but about making it possible to use auto completion in your favorite (intelligent) editor according to a defined grammar: in the case of PHP code, methods and properties of your classes and objects; in case of XML, elements and attributes defined in the schema. AFAIK there is no good auto completion support for JSON / YAML in most popular enterprise-level open source editors (just to name 2 I am using: Eclipse, Netbeans) yet. If you know existing tools to do this, let me know and I'll be happy to try them.

I would like the approach of Zeta Components' struct classes a lot more than YAML/JSON then, because of auto completion possibilities.

By the way, there is some documentation available at http://ezpedia.org/en/ez/module for a long time already, might be improved heavily language-wise though.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Monday 26 April 2010 9:05:04 am

Excellent page on ezpedia, thanks kristof!

Summing it up, to get the power of ide introspection without hacking the kernel code, we might define new 'struct' classes for module def, view def, fetch_function def, that implement the arrayaccess interface (http://php.net/manual/en/class.arrayaccess.php) and everybody's happy.

Principal Consultant International Business
Member of the Community Project Board