When To Use A Custom Function When Developing Admin App?

[mikeel100]

As to where the file(s) of function(s) reside, I have been looking at how/where they are used. For functions that are intended to be used for a single "app" (not necessarily throughout the ZC program) I may be appropriate that the function file(s) be stored in includes/functions and then loaded (include, include_once, require, or require_once) in the applicable application to be made available for operation. By placing in the includes/functions/extra_functions directory the function(s) are loaded for use at all times by all software. Placing the file(s) in this directory is another reason to possibly consider the function prefix to be other than zen_ (until such function is incorporated into the ZC "core"... Yes it can happen.)

As to the function that queries "concern", take a look through the includes/functions/functions_lookup.php file of the catalog side. Basically, nothing but query lookups or call functions that do query lookups.

Now considering that these functions are intending to access and manipulate the database, if no one else does, I suggest that the variables being used also go through some level of sanitization before applying directly to the database. For example, in the above ezfields_one_field_update function, if $set_field could be: 'field1` = \'value1\', `field2' and then the variable $value would be set to field2... maybe that's intentional, but it doesn't fit the name of the function and never know what "naughtiness" could be caused. Another thing about the function, it's termed as an update for a single field, is it intended to be a single field of a single record or perhaps a single field for all records? If possibly a field for all records, then I might suggest using some default values for provided parameters such that in their absence an appropriate portion of the query is not included.

Hmm, just also noticed, how is a null field value anticipated to be handled?

Good questions by the way. Do also understand, if haven't already, there are several ways to accomplish the same goal, and there are several different opinions in some matters. Keep up the development!

As to the function that queries "concern", take a look through the includes/functions/functions_lookup.php file of the catalog side. Basically, nothing but query lookups or call functions that do query lookups.

Is it possible to use catalog side functions within admin scripts?

[mikeel100]

Thanks, both of you, for the quick references links.

I will be reading a lot this week before proceeding.

[lat9]

Is it possible to use catalog side functions within admin scripts?

Not without including them in the admin page-load process, normally via a plugin-specific admin "init_include" script.

[mc12345678]

Not without including them in the admin page-load process, normally via a plugin-specific admin "init_include" script.

Well.... There are a few functions at least back in ZC 1.5.5 (yes I have a copy that I have not updated that is used for general "visual" review knowing that it is not up-to-date but gives a good reference point to investigate further) that are specific to the catalog side and are used within the admin side as loaded through admin/includes/init_includes/init_general_funcs.php and there are some others that are loaded via the init_special_funcs.php file in the same directory. Each of these as lat9 was pointing out are loaded as identified in the admin/includes/auto_loaders/config.core.php file (part of the admin page-load process).

I haven't checked in on it in a while, but there was/was to be some sort of "group" area where functions that were common to both catalog and admin could be placed and then loaded from either side/set. It was an "idea" a while back. The biggest issue of concern with pulling catalog functions into the admin side is if there are functions in a file in the catalog side that are not uniquely named as compared to those in the admin side. When attempting to include the file(s) (as is) an error (duplicate function related) will be generated.

[mikeel100]

When attempting to include the file(s) (as is) an error (duplicate function related) will be generated.

Thanks for that warning!

[mc12345678]

Thanks for that warning!

I'm not a fan of picking small portions that remove context. One way that the above "sentence" could be rephrased:

When attempting to include the file(s) (as is) an error (duplicate function related) will be generated, if a second file contains the same in scope function name of a function previously declared.

[carlwhat]

Is it possible to use catalog side functions within admin scripts?

excellent question!

this is one of my biggest critiques of ZC. the same named functions doing different things on the admin v catalog side. i find it onerous to maintain.

for my customized functions, i create them someplace like:

includes/extra_datafiles/custom_mods.php

and then add a line in:

admin/includes/application_top.php

to include that file.

best.

[lat9]

excellent question!

this is one of my biggest critiques of ZC. the same named functions doing different things on the admin v catalog side. i find it onerous to maintain.

for my customized functions, i create them someplace like:

includes/extra_datafiles/custom_mods.php

and then add a line in:

admin/includes/application_top.php

to include that file.

best.

That works, but requires an update to application_top.php (a core-file). A better approach is to include an admin-level auto-loader:

/admin/includes/auto_loaders/config.load_custom_mods.php

  $autoLoadConfig[200][] = array('autoType'=>'require',
                                 'loadFile'=> DIR_FS_CATALOG . 'extra_datafiles/custom_mods.php');

[mikeel100]

I think I'll just avoid using catalog side functions in admin until the powers that be decide how and when to have only one naming system for all functions.

Wouldn't classes solve that problem?

That is my conclusion after reading for hours last night on when to use a class versus a function...but I may have misunderstood.

Thanks.

[carlwhat]

That works, but requires an update to application_top.php (a core-file). A better approach is to include an admin-level auto-loader:

/admin/includes/auto_loaders/config.load_custom_mods.php

  $autoLoadConfig[200][] = array('autoType'=>'require',
                                 'loadFile'=> DIR_FS_CATALOG . 'extra_datafiles/custom_mods.php');

concur.