Tuesday 02 February 2010 1:26:18 am

Here's the diff on eZModule:

 --- a/lib/ezutils/classes/ezmodule.php
+++ b/lib/ezutils/classes/ezmodule.php
@@ -32,7 +32,6 @@
   \brief Allows execution of modules and functions
 
 */
-
 class eZModule
 {
     const STATUS_IDLE = 0;
@@ -45,6 +44,8 @@ class eZModule
     const HOOK_STATUS_CANCEL_RUN = 1;
     const HOOK_STATUS_FAILED = 2;
 
+    const CLASS_POSTFIX = '_eZModule';
+
     function eZModule( $path, $file, $moduleName, $checkFileExistence = true )
     {
         $this->initialize( $path, $file, $moduleName, $checkFileExistence);
@@ -64,7 +65,28 @@ class eZModule
             unset( $FunctionList );
             unset( $Module );
             unset( $ViewList );
-            include( $file );
+
+            $moduleClass = $moduleName . self::CLASS_POSTFIX;
+            if ( !in_array( $moduleClass, get_declared_classes() ) )
+            {
+                include( $file );
+            }
+
+            if ( in_array($moduleClass, get_declared_classes() ) )
+            {
+                $moduleObject = new $moduleClass();
+
+                if ( !$moduleObject instanceof eZModuleInterface )
+                {
+                    $this->ExitStatus = eZModule::STATUS_FAILED;
+                    return;
+                }
+
+                $Module = $moduleObject->getModule();
+                $ViewList = $moduleObject->getViewList();
+                $FunctionList = $moduleObject->getFunctionList();
+            }
+
             $this->Functions = $ViewList;
             if ( isset( $FunctionList ) and
                  is_array( $FunctionList ) and

Tuesday 02 February 2010 1:48:33 am

Hey Nicolas!

I haven't pushed this into production, as I wanted to post it here first to see if there was any interest in this.

There's probably even more to gain by adding support for object-oriented views as well, but that looks like a bit more work. I'll take a look at it and see if I can come up with a suggestion.

Any ideas to how that could be implemented?

I'm tracking this post now, btw :)

Tuesday 02 February 2010 5:27:06 am

I like this, too.

Then it is also easier to write a global phpdoc for a module.

http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com

CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter

Tuesday 02 February 2010 2:19:25 pm

I like this idea too.

The current interface of ezmodule is also a bit limited, as you usually end up coing the extension/module/view names a lot of times in the $Results var at the bottom of your views and in the template code.

While at it, why not removing the eztemplateautoload.php file, and other such redundant definition of stuff that can be

-neatly wrapped in php classes and methods

- can thus take advantage of autoload magic instead of having ezp scanning frantically directories to find the proper xxx-handler php class file?

I think the answer we all know, and it is: because we like to keep our binary compatibility...

Principal Consultant International Business
Member of the Community Project Board

Saturday 24 April 2010 5:01:52 am

Maybe it would be worth investigating as well if it would be beneficial to move away from PHP for this kind of (sometimes deeply nested) definition arrays and go for XML instead. A big advantage you will have is that if you provide a proper XML schema, it's easier for developers to create their module definition (xml intellisense/autocompletion provided by IDE's), as well as to validate it. IMHO the current nested array structures are very unhandy.

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

Saturday 24 April 2010 2:15:29 pm

Regarding the module that dynamically created the available views, can you give us some more insight in what had to be accomplished this way what could not be accomplished with view parameters instead?

The validation you would get for free if you use XML, once you agree on the grammar through a XML schema. You need a blue print of the elements that can/should be there anyway, and better to do it formally following a W3C recommendation than with (often incomplete and out to date) documentation and some custom PHP code that checks for the existence of specific array keys.

There is some sort of schema validator as well for YAML, Kwalify, but afaik only Ruby and Java versions exist.

YAML might be less verbose to create by hand, but with an IDE with good XML schema support you're able to get equal results in no time.

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

Sunday 25 April 2010 4:00:14 am

@kristof: I agree that validating xml is currently easier because of a wide array of tools available.

But I think that the validation part is not what is hampering development currently. The DOCS are. And no, saying that docs get outdated is not a good reason to avoid producing docs altogether.

Take for a simple example the following parameter in a module.php file:

 $Module = array( 'name' => 'So what?',

              'variable_params' => true );

raise your hands if you know what 'variable_params' does (ps: I am sure that Kristof does, but how many besides him do?).

And honestly, tell me if validating that to check that it is either true or false helps you a bit.

I'm not against using existing schema languages; it is of course faster than writing a custom php validator from scratch, but what we should achieve is rather making sure that the docs are embedded in the validation definition. And afaik, niether relax-ng nor xsd mandate that you document elements.

In my experience the best (basically the only) way to make sure that doc is always up-to-date is to

a - use meaningful names for variables, methods, classes, and a clean design, and

b - embedding comments in the doc

For point b, while sticking to the current php-based definition, we could add phpdoc comments to a "blueprint" module definition, and voilà, zero impact and a large gain. We could of course also add php classes that act as blueprint for those arrays ('struct' classes), similar to the way that ezc define options...

Principal Consultant International Business
Member of the Community Project Board

Sunday 25 April 2010 4:30:44 am

@Jerome: writing stub code is a chore I agree;

But I think that copying and pasting xml would be no better than copying and pasting php code.

And even if we made a GUI wizard like the one that exists for tpl ops, it would not be much faster for the developer in the end.

What we need otoh is reverse engineering of existing php code that creates the stubs automatically.

I think it would make for a nice extension: scripts/php classes to wrap an existing php function/object into a template operator stub, a template fetch function stub, etc...

Willing to join?

Been there, done that, btw: http://phpxmlrpc.svn.sourceforge.net/viewvc/phpxmlrpc/trunk/xmlrpc/lib/xmlrpc_wrappers.inc

Principal Consultant International Business
Member of the Community Project Board

Sunday 25 April 2010 10:04:43 am

Willing to join?

Sure ! :)

Monday 26 April 2010 11:17:26 am

Yes, that sounds like a good plan.

Will it be in the core of 4^.4?

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