Dizkus

I have some questions and some doubts about custom functions in pn8. There is no documentation on this topic so I can only guess after some look to source.

So - we have now dirs:
config/functions
themes/{some_theme}/functions
New function calls (through ModuleUtil::exec, pnModFuncExec in RC1) looks to this dirs.
It works when we add new function to existing type (eg "Admin_admin_mynewfunction")
Won't work attempt to overwrite existing function (because it's already loaded).

Also won't work when we try to add own type for module - eg we want to add to module Admin type "custom" function "clearAllCache".

Both issues come out from ModuleUtil::load method (pnModLoadGeneric in RC1).
This method (function) doesn't look for files to config and theme dirs.

First "issue" is not a problem. But second one... It would be nice to have possibility to create own type of functions :)

So my question is: should it work as is working now, or described "issues" are defects?

Uff - this problem is too complicated for my poor English
Thanks in advance for replays.

--
Polish Zikula Team

Bianor Works - my Zikula works on CoZi

This only works if the original module is split down into seperate files. Without this you end up with duplicate function names. This is unavoidable.

i.e. modules//pnuser/[function].php

There are only a few modules written this way currently - mostly mine.

-Mark

In first case (overwriting existing functions in modules, where all function of one type are in one file) I understand that it is problem.

But is second case - adding own types of functions - this shouldn't be a problem.
If we add two new directories in ModuleUtil::load (config/functions and theme/some_theme/functions) and check them in the same place where are checked dirs like "modules/modname/pn{ftyype}{API}/" we could load from config and themes own function types.
This also shouldn't cause much overhead, because there are loaded only few modules, and more of them will be loaded before this checkings.



--
Polish Zikula Team

Bianor Works - my Zikula works on CoZi

Mark,

Is this going to be the recommended layout for module development in the future?


I've always thought that the performance hit for dozens (or hundreds) of include_once/require_once calls was worse than dealing with all the functions of a particular type (pnuser, pnadmiapi, etc...) in a single file.

Chris

--
Chris Stevens, CEO
OpenTaxi Systems LLC
866.OPENTAXI
www.opentaxi.com
On-Demand Air Taxi Reservations Platform, Flight Reservations,and Consulting.

This is how I've been writing my modules since this was implemented in .750. I find it easier to deal with then having all functions in one file. Esp when trying to debug an error.

--
cyber_wolf
www.bkbsolutions.com - My Zikula module development site.

I can definitely see the benefits for both development and maintenance and the capability to override certain functions. I may try it on a rather large module and see if I can see any penalty.

So cyber_wolf, do you do a big list of include_once calls in your top-level pnuser.php and pnuserapi.php files or do you only include the required functions in each function-specific file?

I think the latter would lead to a leaner module if the overhead of including those functions all over the place doesn't slow it down and you don't change function names too often.

Chris

--
Chris Stevens, CEO
OpenTaxi Systems LLC
866.OPENTAXI
www.opentaxi.com
On-Demand Air Taxi Reservations Platform, Flight Reservations,and Consulting.

You don't use the pnuser.php, pnuserapi.php, pnadmin.php, or pnadminapi.php files.

e.g. you have function modname_admin_view in modname/pnadmin.php. You would place this function in its own file in modname/pnadmin/view.php.

The core functions will automatically look in modname/pnadmin directory for file view.php when the pnModFunc('modname', 'admin', 'view') function is called.

This means none of the PN function files need to be in the modname directory anymore, nor do you need any include/require commands to make sure they get loaded. This is all taken care of automatically.



edited by: cyber_wolf, Oct 05, 2007 - 09:58 AM

--
cyber_wolf
www.bkbsolutions.com - My Zikula module development site.

Very nice, I'll have to try that out.

Is there a normal convention for "file-global" define statements for enumerations?

Right now, I have all relevant define statements at the top of file that uses them (i.e. modname/subsectiondirectory/pnuserapi.php contains all defines for subsectiondirectory).

Chris



--
Chris Stevens, CEO
OpenTaxi Systems LLC
866.OPENTAXI
www.opentaxi.com
On-Demand Air Taxi Reservations Platform, Flight Reservations,and Consulting.

To answer the question about if this'll be the recommended method for modules... I think that it's a balance and that there is no right or wrong way. For smaller modules keeping things in single file(s) has an advantage in terms of performance. The server needs less file system operations since all functions are in one file.

The bigger the module theres more code that needs interpreting, more time spent by the developer managing the larger single files etc.

My general approach is to keep smaller utility modules (or at least the user API parts) in a single file (pnuserapi.php) but split the GUI parts and bigger modules.

With regard to a file used to hold constants - no the core doesn't look for or attempt to load any file specifically for constants; Outside of language files of course.

-Mark

This brings me to a question: Is there a smart caching system for php/apache?

APC and other cache systems are dealing with the compiled PHP code -
is there a cache system for the uncompiled one and one on "include
compile step"?

Would be a apache/php module - but to hold the sources pre-pre-compiled
in the memory, i mean complete, would make alot sense on every dedicated
server, eating only a few MB. Well, even 50mb of something would be fine
and acceptable.