Print this page
Sunday, 20 May 2012 18:29

Put your iLance plugin code where you want

Written by
Rate this item
(1 Vote)

Over a period of years I have migrated from developing iLance plugins with the normal XML plugin structure. For a look at iLance plugins read Your First iLance Plugin. It gives a nice intro into plugins and the manner in which they can be used to customize the way iLance works and renders your material.

Like everyone else I used to plop the php into the tags in the plugin xml file. The thing is, I use Netbeans to do all of my work. That IDE has a nice PHP implementation, but when developing your plugin in an XML file, Netbeans looses its ability to render the nice visual differences and indicators which are based on PHP rules, functions and included libraries.

There is no 'red' line error indicators, no predictive variable or function suggestions and no colour differentiation between variable names and strings. It makes sense from the IDE's perspective, after all, we are editing a "string" that iLance takes to evaluate (eval(string)) when the corresponding 'api' is called.

($apihook = $ilance->api('[APIHOOKSTRING]')) ? eval($apihook): false;  

Also, when you have several different plugins firing from the same apihook and one of the xml plugin files has an error you get an error message that refers to the file that holds the apihook, i.e. main.php and the line number that the error happens on in the evaluated code, but not the actual file name where the error takes place. SO that means you need to visually inspect each of the files you have with that event starting with the most likely culprits first (i.e. the ones you have open to learn how something is done in iLance). I can tell you from experience, this can be very frustrating.

The lack of these features has been an annoying reality for some time. Recently I had the opportunity to start from scratch on a new project and so, I decided to use a pretty straight forward file include technique and I have enjoyed the results.

The first thing I did was decide what the directory structure should look like, and more specifically, where my php plugin code should go. Then define that as a Global Constant:

define("MY_PLUGIN_CODE_XMLPHP", DIR_FUNCTIONS . "custom/myapp/xmlphp/");

After I have done this, I use the exact same (almost) pattern for each of my plugin xml plugs, for example:

iLance plug example

You are more than likely better to use "include" instead of "include_once", especially if the plugin is inside a function that may get called more then once. Otherwise, the PHP interpreter will ignore the file.

This way I get to keep all my plugin specific code in one directory and edit the PHP in that file with all its error highlighted and color filled splendor.

iLance plug example

Doing it this way also has the nice side effect of orgainizing my files alphabetically in the directory. When including all my php in the plugin xml file meant that as the file grew it would become a little harder to find things.

In any case, I am not suggesting that this is best way, but it has proven to be a truly beneficial way for me to organize and fire my plugin specific code.

Good luck with your marketplaces!!!

Read 7331 times Last modified on Saturday, 11 August 2012 00:04
Cameron

Cameron is a PHP Application Developer and consultant and spends much of his time furthering the business goals of his company Magnetic Merchandising Inc. which he started in 2005.

Cameron has provided technical deployment and consultation for many entities since starting MMI. Much of that work has been in complex hosted auction platforms, professional Joomla! deployments and extension development and sales.

As such, Cameron has acquired a deep technical skill-set, a sensitivity to client needs, and the ability to produce anything those clients can visualize.

Everyday, he actively seeks out and becomes familiar technologies that will give MMI clients maximum return for their web development and general e-presence dollar.

magneticmerchandising.com

Latest from Cameron