config/functions :: Zikula Community :: Support at your fingertips

Try Zikula 1.3.1!New core, modules & more

Download Zikula!Version 1.2.8 (stable)

config/functions

Print topic

Jusuff

Rank: Team Member

Registered: Apr 07, 2005

Last visit: Jan 18, 2010

Posts: 228
Posted: Oct 04, 2007 - 05:08 AM

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
markwest

Rank: Team Member

Registered: Mar 18, 2002

Last visit: Oct 21, 2009

Posts: 6606
Posted: Oct 04, 2007 - 05:15 AM

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

--
Visit My homepage and Zikula themes .
Jusuff

Rank: Team Member

Registered: Apr 07, 2005

Last visit: Jan 18, 2010

Posts: 228
Posted: Oct 04, 2007 - 06:07 AM

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
cgstevens

Rank: Registered User

Registered: Dec 19, 2006

Last visit: Jun 01, 2009

Posts: 33
Posted: Oct 04, 2007 - 11:32 AM

Mark,

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

Quote
modules/pnuser/[function].php

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, Consulting.
cyber_wolf

Rank: Developer

Registered: Jun 03, 2002

Last visit: Dec 21, 2009

Posts: 284
Posted: Oct 05, 2007 - 12:56 AM

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

Quote
modules/pnuser/[function].php

Chris

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.
cgstevens

Rank: Registered User

Registered: Dec 19, 2006

Last visit: Jun 01, 2009

Posts: 33
Posted: Oct 05, 2007 - 02:25 AM

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, Consulting.
cyber_wolf

Rank: Developer

Registered: Jun 03, 2002

Last visit: Dec 21, 2009

Posts: 284
Posted: Oct 05, 2007 - 02:56 AM

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.
cgstevens

Rank: Registered User

Registered: Dec 19, 2006

Last visit: Jun 01, 2009

Posts: 33
Posted: Oct 08, 2007 - 11:24 AM

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, Consulting.
markwest

Rank: Team Member

Registered: Mar 18, 2002

Last visit: Oct 21, 2009

Posts: 6606
Posted: Oct 08, 2007 - 08:44 PM

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

--
Visit My homepage and Zikula themes .
**unknown user**

Rank: Freshman

Registered: Mar 16, 2002

Last visit: Jul 26, 2008

Posts: 61
Posted: Oct 09, 2007 - 01:38 AM

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.