FlyLoader @ GitHub: Source (temporary location)

The FlyLoaderComponent will import and load Helpers, Components and Behaviors on the fly. Cases in which this may because useful is if the Helper/Component/Behavior is only needed in certain cases/actions.

The FlyLoader Component

The FlyLoaderComponent consists of the following functions:

load($type, $name)
The load() function will import and initialize your Helper/Component/Behavior accordingly.

$type is the type of object you wish to load, as expected by the $type value in App::import(). The values currently supported are “Component”, “Helper” and “Behavior”.

$name is the name of the Component/Helper/Behavior you wish to load. $name can be String value or a key/value array where the key is the key is the Component/Helper/Behavior name and the value is a key/value array of options/settings passed to the Component/Helper/Behavior.

For example, if you wanted to load my BibleComponent/BibleHelper on the fly (shameless plug), it would look like the following:

class PassageController extends AppController {
    function passages($passage) {
        //load BibleComponent
        $this->FlyLoader->load("Component", 
                array("Bible.Bible" => 
                        array("Esv" => array("key" => "<your key>"))));
 
        //load BibleHelper
        $this->FlyLoader->load("Helper", "Bible.Bible");
 
        $passages = $this->Bible->get_passage($passage);
 
        $this->set("passages", $passages);
    }
}

unload($type, $name)
The unload() function will unload your Helper/Component/Behavior accordingly. Currently, it will only unload Behaviors… Any other $type will simply do nothing. But the placeholders are there in the event that we find reasoning to unload a Helper/Component.

$type is the type of object you wish to unload. The values supported are “Component”, “Helper” and “Behavior”.

$name is the name of the Component/Helper/Behavior you wish to unload. $name is expected to be a String value.

I’m happy to announce the release of the alpha version of my Bible plugin for CakePHP! It’s alpha because, well, it’s really limited right now… but if all you want is to retrieve passages from the Bible, this does the job.

The Bible plugin was created with the intentions of expanding support for various translations of the Bible. However, as it stands, it currently only supports the English Standard Version (ESV).

What’s in the Bible plugin?

App::import("Component", "Bible.Bible");
App::import("Helper", "Bible.Bible");
class SermonsController extends AppController {
    var $components = array("Bible" => array(
            "Esv" => array("key" => "<your key>"),
    ));
 
    var $helpers = array("Bible");
    ...
 
    function passages($passage) {
        $this->layout = "ajax";
        $passages = $this->Bible->get_passage($passage);
 
        $this->set("passages", $passages);
    }
}

The Bible component

The Bible component is a dispatching component which will provide your controller with the functionality to lookup passages in the bible.

The Bible component’s $settings array is a key/value array where the key is the name of the translation-specific component and the value is said component’s $settings array. The purpose of this is to allow for us to easily add new translations in the future.

The “Esv” key refers to the EsvBibleComponent that the BibleComponent will dispatch its calls to when specified. Adding suport for “Niv”, “Nlt”, “Kjv” and so on would be as simple as creating NivBibleComponent, NltBibleComponent, KjvBibleComponent and implementing the functions dispatched by BibleComponent.

Currently, the only translation implemented is ESV. The component is basically a wrapper for the ESV Bible Web Service (ESVBWS), so make sure to follow all of its conditions before using this plugin.

One of the conditions placed by the ESVBWS is that you can make no more than 5000 queries per day. The way they determine how many queries you’ve made is by your server’s IP or by requesting an API Key with them. As you can see from the example above, the EsvBibleComponent takes a “key” parameter in its $settings array as well. The key field is optional and it will default to “IP” (meaning that the ESVBWS will log your query count by the querying server’s IP). They say that this is typically sufficient, but if you’re on a shared server and share your IP with many other sites (who also happen to use the ESVBWS or the mighty Bible plugin) then all your request counts will be summed up together. So, you can request an API key to make sure you get your 5000 queries a day (or an annual price of $100 for more than 5000 queries a day).

The Bible helper

Currently, all the Bible helper contains is a method to encode passages to be sent back to the controller’s actions.

<?php echo $this->Html->link("[ESV]", "/sermons/passages/" . 
        $this->Bible->encode_passage("John 3:16")); ?>

Due to CakePHP’s named parameters, passing passages with colons is not possible (it will think you’re trying to pass a named parameter). As a result, you can use the Bible helper’s encode_passage($passage) function in order to encode the passage to be passed to your controller. Essentially, all this does is replace any occurrence of “:” with “|”.

To see a working example, unpack this plugin in your plugins directory and go to /bible/examples in your browser.

Cuploadify @ GitHub: Repository | Download

To install this plugin, simply unzip the latest stable build into your /app/plugins/cuploadify directory.

In my attempt to decouple all of my CakePHP projects into separate, reusable plugins, I’ve created a CakePHP plugin for Uploadify. For those of you who aren’t familiar with Uploadify, they describe themselves as “a powerful and highly-customizable file upload script.”

The Uploadify Element

At the heart of Cuploadify is the uploadify element which can be used in your views to quickly create a real-time file upload input box.

An Uploadify file input box can be inserted into your view like so:

$this->element("uploadify", array(
    "plugin" => "cuploadify",
    "dom_id" => "file_upload",
    "session_id" => $this->Session->id(),
    "include_scripts" => array($string...),
    "options" => array("script" => "/users/upload_profile_pic", $mixed...))
);

Options for the Uploadify element

plugin*
The value here must be specified as "cuploadify" in order to let CakePHP know that the element resides in the cuploadify plugin.

dom_id*
The DOM id of the Uploadify file uploader element.

session_id
As described in Uploadify’s FAQ, “Since the Flash file is what is communicating with your back-end script, the session information is not sent when a file is being uploaded.” If you want to give the back-end script the current session, you can either pass the "session_id" key through the scriptData option, or by specifying the session id through this parameter.

If you’re using the cuploadify component in your controller, the switching of the sessions will be taken care of for you. Otherwise, you will need to manually switch the session before it has been started (ie. in your controller’s beforeFilter() method) like so:

// this is not necessary if you're using the cuploadify component
if (isset($_REQUEST["session_id"])) {
    $session_id = $_REQUEST["session_id"];
    $this->Session->id($session_id);
}

include_scripts
In order to avoid including the same scripts multiple times — in the event that you have multiple uploadify inputs within the same page or are already including jquery/swfobject scripts — you can use this array to specify which scripts you wish to include when printing this element.
Possible values: "jquery", "swfobject", "uploadify", "uploadify_css".
As of v0.1.6, all of these values can be overloaded as keys, whose value will specify a custom path to its corresponding script.
Default values: No scripts will be included by default.

Example:

array("jquery" => "/path/to/jquery", "swfobject", "uploadify");

options
This associative array allows you to specify all the jquery options expected by Uploadify.
Possible values: View the Uploadify documentation to see all the possible keys and their expected values.
Mandatory option(s): script
Default option(s): The cancelImg and uploader options will use the files provided by Uploadify. No other options will be included.

To my knowledge, all paths/urls can use the CakePHP routing URLs.

* denotes mandatory options.

The Cuploadify Component

The cuploadify component contains helper methods to facilitate the back-end functionality likely to be used by an Uploadify input box. It is not required when using the uploadify element, but it’s purpose is to implement some of the basic actions generally used with Uploadify input boxes.

To use this plugin with your uploadify element, you will need to call the this component in the action specified by the script key of your element’s options parameter. In our current example, it would be like the following:

// don't forget to import the Cuploadify component!
App::import("Component", "Cuploadify.Cuploadify");
class UsersController extends AppController {
    ...
    function upload_profile_pic() {
        $this->cuploadify->upload();
    }
}

The Cuploadify component methods

upload($options = array($key=>$value,...))
This method can be used to upload the files specified by the Uploadify input box (to the destination specified by the input box).
Options: The only option currently available is "root", which allows the developer to specify a root directory to prepend to the upload directory specified by the "folder" key of the corresponding Uploadify input box. This gives a sort of sandbox effect to avoid certain XSS exploits.

And that’s it!

If there are any features missing or not working properly, feel free to let me know. Or – better yet – send me a patch with the fix

I’ve decided to split V2 of Montreal-CAC.org into multiple phases, otherwise it would just take too long to get something out there.

BETA
As soon as I have some semblance of a site, I will put it up @ beta.montreal-cac.org. There, potential users/fellowship staffs can start getting acquainted to using the site.

PHASE 1
The goal of Phase 1 is 1) to migrate all the old content (that we intend to keep) to the new structure, 2) to have the site updated more often, 3) to bring the information to the user, not relying on them to look for it and 4) Churchie.org integration.

WHAT DO WE KEEP?
Even though most of our site has been untouched for years, there are certain sections that are still up to date. For instance, we have 5 years worth of sermons from the English Congregation. Moving forward, we’ll need to decide what to keep and what needs to be revamped.

AVOIDING AN ABANDONED SITE
It’s going to be crucial for us to find a way to keep the new site up-to-date. The #1 factor (no research made lol) in retaining visitors is giving the users the information that they came for. If a visitor gets the impression that our site is no longer being used, they’re not coming back. We can’t still have posts about Christmas service when Easter is coming up.

Of course, the information generated on the site will not depend on me… I’ll need the cooperation of the MCAC community in order to keep it up-to-date. What I need to do, as the web developer, is make it easy for our community to update the site.

The people expected to drive this site’s content will be the Fellowship PRs. Typically, they will send out a weekly emails to advise the fellowship’s members what’s going on this week. However, the staff needs to be convinced that weekly emails are NOT the approach to take. Why? Because after a couple months, you end up with an email list of about 50 people even though only 20 of them actually want to stay on the mailing list. There is no way to unsubscribe.

This is where the new site comes in hand. We’ll be implementing newsletters per small group/fellowship so that people can subscribe/unsubscribe to whichever newsletters they wish. The beauty of using these newsletters is that it will simultaneously be posted on the church site! That way, even people not registered to the mailing lists can see what’s going on around the church… and, if successful, will keep the site updated regularly without requiring anyone to do more work than they did before.

BRINGING THE CHURCH TO THEM
Let’s face it… people are NOT going to go to Montreal-CAC.org regularly. We’re going to need to bring Montreal-CAC.org to them. How? It all works around the new newsletter feature. For each newsletter written, there will be options to post to twitter and post to Facebook so that, as long as you’re following MCAC on twitter or are a fan of MCAC (or whichever small group/fellowship) on Facebook, you’ll receive a short blurb along with a link to the full details located on our site. This way, users can keep up-to-date with the ongoings of MCAC without ever visiting the site!

SHARING THE WEALTH
As a developer, I want everything I create to be re-usable. As a Christian, I want to help as many churches “get online” as I can. A lot of the features on Montreal-CAC.org are not specific to MCAC — most churches have sermons and fellowships — and if it’s good enough for MCAC to use, I’m sure many other churches would find it useful as well. That’s why everything developed for this site will be written generically, to be re-implemented on Churchie.org where churches will be able to register for free and take advantage of those features.

PHASE 2
Phase 2 will consist of more church management tools like viewing your tithing records online and reserving rooms in the church.

Hope you guys are as excited as I am!

Well, between switching jobs, moving out and getting married, we’re closing in on the end of the year, and there’s been little progress.

What I have done is scrapped two different designs for the new site. I’ve also created a third layout, which looks great now, but will probably face a similar fate as the previous two before it’s release date.

One of the tougher decisions I’ve made was to not use Drupal or WordPress. Don’t get me wrong, I absolutely feel that those are good tools for creating church sites… and if one were thinking of creating a church site, I would definitely recommend checking out those two solutions first before deciding to build your own. If you can fit your site within those frameworks, their community’s plugins will help you tremendously. Unfortunately, I just didn’t see the features I wanted to implement for the new site as being easily integrated into Drupal or WordPress.

In the end, I felt most comfortable with building this site using the CakePHP framework. I’m aware of Drake, the CakePHP module for Drupal, but at this point, it just seems to bloated for what I’m trying to do.

In an attempt to reuse as much code as possible, I’m going to try and make as many generic CakePHP plugins as possible. For example, the management of Users, Groups and Roles will be part of it’s own separate project called the URG plugin. Ideally this plugin will be able to be reused in my future CakePHP projects.