The architecture of Zikula modules should be changed in order to benefit from some enhanced OO abilities PHP 5 is offering, support some common best-practice pattern and do all that fitting to our existing technologies.

Primary motivation for object-oriented approaches is the possibility to *enforce* things instead of assuming them. This also results in a better navigation of new developers since errors become more obvious.

For example we can use type hints for parameters: function doSomething(MyCustomer? myCustomer). But more important are interfaces since they support polymorphism as well as separation of concerns and they make everything become more transparent.

Focus: the way modules are structured and how they are working together. If a module is representing itself as a class it can implement additional "properties" by implementing interfaces (which is actively supported by all common IDEs). A module class should be able to return lists (or arrays) with its dependencies and also its actions. An action is a class containing a particular system use case (like module_admin_view()).

If we want to have something like an event-based system, we should add a facade around all types of actions that might occur. Just take a look at sfEventDispatcher from http://www.symfony-project.org/blog/2008/06/23/the-symfony-1-1-architecture to see what I am talking about. There are "action types" like sfRequest, sfLogger and sfResponse. As our current hook system is a simple observer implementation this could be enhanced to something like "action scripts" with which developers can easily create and call operation chains. The event dispatcher then acts as central notification class. Pseudo-code: foreach(Hookable in $listeningObjects) notificate(); The different hook types are also defined as interfaces which are implemented by Action classes. Example: the Transformable interface would require implementing a transform() method.

I also think that we should enhance the Loader class to provide a factory for easy instantiation of new objects. Perhaps the autoload functionality of php can be used for that. Getting a new object should if possible not be more than Factory::createNewObject('AutoCustomer?', 'customer'); When you have the object most things you might want to do with it are already possible. But we must ask at which points we can help developers building up powerful structures without much effort.

Another place where interfaces might be really useful is the ObjectUtil? service. If a particular object type does support attributes, categories, object logging or something else can be expressed with implementing an interface. When you are processing an array with different object you can then say something like foreach(Attributable in $myObjects) listUpAttributes() whereby listUpAttributes is a method which is defined by the Attributable interface. Polymorphism rocks :-)

We have to decide what we do centrally and what we should do per module. Example: ObjectListUtil::getObjectList('AutoCustomer?', 'customer') vs. ModAutoCustomer::getObjectList('customer') *gg

There are many other many possibilities, for example we could take profit from reflection with PNObject classes. Furthermore we should think about introducing Exceptions for processing and especially handling errors.

IMHO this is a central feature like user handling, search and forms validation.

Ephemerids should move into separate project. There other users can give their input and it won't be a small module in a big project.

IMHO FAQs have been widely replaced by Wikis. This module shouldn't be dragged around by the core team. But maybe somebody else likes to pick it up.

This module is important in conjunction with Workflows and PNObject. Every module that uses workflows rely on this.

Recommend_Us is a nice hook that could be maintained in an extra project. I guess it does already a lot and maybe Frank S. is willing ti maintain it (keep up functionaltity that is basically)

the thumbnail module doesn't seems to work with alias

for instance, my website is located on http://localhost/mysite where mysite is an alias to c:/myfolder/

document_root is c:\wamp\www

when i upload a picture, i got a Populating $rawimagedata in file "phpthumb.class.php" on line 3168

cannot fopen(C:/wamp/www/mysite/images/theme/qgo8u4v9e7d9iylqrhd7u7fedjepd0.jpg) in file "phpthumb.class.php" on line 3179

Security enhancement:

The SecurityCenter? should (perhaps optionally?) integrate an Intrusion Detection System.

See http://php-ids.org/

http://www.firephp.org/

The pn prefix needs to be removed/replaced from all custom classes/ids

-Mark

by default a class loader is already implemented with zikula

with this tree

myModule/
myModule/classes
myModule/classes/myPackage/MaClasse.class.php
myModule/pnuser.php
myModule/pnuserapi.php

you can load class like this

Loader::loadClassFromModule("MyModule","myPackage/MaClasse",false,false,"");

if possible, i would like to have a feature to load the class like this

Loader::import("MyModule.myPackage.MaClasse");

with eventualy an "importCore" to load the class from /includes/pnobjlib

AND better like this

Loader::import("MyModule.myPackage.*");

where all the class under "myPackage" will be loaded at once.

thanks in advance

Please remove all hard-coded text from all files in the pnoblib, and use pnLangLoad() instead to load the text.

Sometime I forget to remove pndebug from a template - then it's really hard to find the right template. There should be the information in pndebug's popup which template opened it, and in which line it is there to be found.

Please modify the pnRender/Custom Block so that a Module name is not required for it to function. It should default to /config/templates/ if no module name is given. Also a further suggestion - allow the entry of a directory name within the /config/templates/* directory (eg. /config/templates/myfoldername) this would allow admins to organize their templates.

Admin messages, while surly a useful module, does not deserve to be a system module.

This may go for Profile as well. I cannot comment on dependencies though.

While, I could probably make the argument for others, SystemInfo?,et cetera, I will spare the debate.

Admin messages can easily be replaced an html block that says the same thing.