Quote from: rf9 at May 04, 2010, 07:20 AM
I’m attempting to put together a tansport package that includes all the bits and pieces that I generally create whenever I setup a website with MODx: Templates, Wayfinder, a few chunks and TVs and a basic css file. I’ve been referring to this tutorial Creating a 3rd Party Component Build Script and I’m struggling a little and hope someone could clarify a few points. I’m also new to using SVN so this probably isn’t helping.
My first question is regarding directory structure and source files. I’ve setup my directory as explained in the tutorial. I’ve also looked at using the component-template structure. Some of the code from this template differs from that of the tutorial. Which is the latest?
Actually, component-template is a bit outdated. I recommend looking at
doodles, which is a good demo component.
Secondly, do I build my component within a MODx installation or outside as a standalone?
What do you mean by this? Do you mean where your files are located, or where they are run?
I find it easiest to build it outside the file path of MODx, and add 2 System Settings to tell MODx where the files are. For example, with quip, i have "quip.core_path" and "quip.assets_url". The first points to the directory where the core dir (/workspace/quip/trunk/core/components/quip/) is, and the second points to the URL of the (/workspace/quip/trunk/assets/components/quip/) directory (i’ve put my 3PCs in a ’workspace’ directory, which is web accessible in my localhost via http://localhost/workspace/). Then my component uses those settings to tell itself where its files are. All the snippets have this as their first line:
$quip = $modx->getService('quip','Quip',$modx->getOption('quip.core_path',null,$modx->getOption('core_path').'components/quip/').'model/quip/',$scriptProperties);
if (!($quip instanceof Quip)) return '';
The Quip class is a base class that has all the path info, etc. The Doodles class I stated above does the same. Note that this first getService call automatically instantiates a Quip class instance for me as well. It passes 2 arguments, $modx and $scriptProperties (an array of properties passed to the snippet). Note how it also checks to see if the quip.class.php file is in the ’quip.core_path’ place before checking the default MODX_CORE_PATH.’components/quip/’ location.
This is good in a couple ways - one, it allows me to do development straight from my SVN checkout of Quip (or whatever 3PC), as the files are outside the MODx webroot and are ’checked out’ by SVN. So I can work on Quip, and then immediately commit. (I’ll be speaking on this process at modxpo, btw.)
Then, in my modx install, I use an ’include’ snippet, which is:
$o = ''; $f = $scriptProperties['file'];
if (file_exists($f)) { $o = include $f; }
return $o;
Then in the Resources where I put the snippets that I’m developing:
[[!include? &file=`[[++quip.core_path]]snippets/snippet.quip.php`]]
I can also pass any other parameters to the Quip snippet in the include snippet call (as it will just pass them through the include). This allows me to develop Quip straight from outside the webroot.
Then, once I’m done building Quip, I build the Transport Package, and install it on another MODx install (/modxtest/, on mine), that is empty. This is where I test the Transport Package and see if it works correctly, and if the snippets work well outside my dev environment.
This workflow allows me to quickly and easily develop 3PCs.
Again, I’ll be speaking more on this workflow at
MODxpo, but that’s basically what I do, and I’ve found it to be a rapid and efficient workflow.
