Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

Directory Structure

edited September 2012 in Future

I've been developing complex Drupal applications for years and I appreciate elefant's the simple and effective architecture. I see a lot of potential!

One suggestion would be separating out the core apps form the custom/contributed apps.

Placing the core apps under a /core directory and keeping the custom under /apps. This would help with upgrading and customizing.

Then you could use an override model in the handler discovery. First look in the apps folder then to the core folder. This would allow for overriding of individual handler and not entire apps.

For example, If I wanted to override add handler for blog I could just place the custom handler in /apps/blog/handlers/add.php


  • Thanks for the feedback!

    We're working on an update command so upgrades to the core will be easier to do, but managing custom apps will be beyond its scope. Although, for those comfortable with the command line, using Composer can be a powerful way to manage additional apps, and I've used git submodules for this as well.

    For overriding handlers, how I've done it so far is to create a [Custom Handlers] section in the app's config file (see apps/blog/conf/config.php for an example) that defines which handlers can be overridden in that app. So you would set blog/post = myapp/post and it will be overridden. You can see the bit of code (which can probably be shorten further) in action in apps/blog/handlers/post.php on lines 7-13.

    The downside is you can't override any arbitrary handler from another app, but having some control as the original app's developer over which handlers can be overridden may help with stability too. It would be good to explore how we can make this easier or more useful.

    Also related is the hooks feature which is a simple event dispatcher for extending handlers without having to override them. Calling $this->hook ('event/add', $data) will trigger any associated handlers from the [Hooks] config.

    Cheers :)

  • Interesting approach with the configuration based allowance of overrides. I think that's a nice mixed of flexibility with stability.

    I would lean to the side of customizability and make the config specify which handlers were not allowed to be overridden. This would make Elefant a Framework with a default CMS rather then a CMS with some override abilities.

    Hooks is something I'm very familiar with, Drupal is built on them. They are great for reacting to but not replacing functionality. This concept is powerful and you did a good job of implementing it ;) The config registry approach is much easier to deal with (and debug issues) then a convention (function/file) based approach so thank you!

    I have noticed that concept of editing an apps config is acceptable. I'm assuming the upgrade process just doesn't touch these files but that does sound a little dangerous. Say an upgraded version of the app add a new default config and expected it to be in the config.php but it wasn't. It is the app developer's responsibility to know this and add some logic to the app? I bring this up because it's related to the separation of the apps and the site.

    IMO it would be much clearer to separate out the core from the apps from the site implementation. My only worry is that it might complicate the application but I think it will actually simplify it. I'm sure it needs more discovery, perhaps I'll do a little playing.


  • I would lean to the side of customizability and make the config specify which handlers were not allowed to be overridden. This would make Elefant a Framework with a default CMS rather then a CMS with some override abilities.

    The trouble here is it adds logic to Controller::handle() to check if every handler should be overridden, versus a bit of code in the handler itself as is currently done. Granted, it wouldn't be much code, but it also limits the way in which the overriding $this->run() is called.

    For example in apps/blog/handlers/post.php, this handler gets called with a URL like /blog/post/123/post-title, and so the 123 gets added back onto the call to $this->run() on line 12.

    Not a show stopper, but maybe instead we can just encourage more overriding by reducing the boilerplate required to something like:

    if ($this->has_override ('blog/post')) {
        echo $this->run ($this->get_override () . '/' . $this->param[0], $data);

    As for editing app configs, I'm undecided as to the best approach here. I don't like anything that modifies the original files, but we're already in that scenario with the core config file. If a new config setting is added, that does indeed get messy.

    Maybe we could do something like this: An app gets a conf/default.php that gets read first, then we check for a conf/config.php that overrides the defaults (these could even live in the main conf folder). We never touch the custom file during updates, and we no longer need to worry about messy merge scenarios since we can safely overwrite the default file. What do you think?

  • edited September 2012

    Yeah, the override thing needs some more thought but I do feel it needs something.

    I've been thinking about the config a lot today. I like the basic idea of a default with custom. I do prefer it out of the app folder though.

    My first impression of the conf directory was that it's for my site only so changing items in there is expected.

    Based upon the conf directory concept I see two good options.

    1. Place an override config file per app in the conf directory.
    2. Put a section per app in the config.php

    For option 1, the filename in config could be something like: config.<app_name>.(<env>).php (env is optional just like it is now).

    How does that sound? I could throw together a pull request for it if you like it.

  • I think you're right. I added a couple lines to lib/Controller.php that do #1, but I named it conf/app.<appname>.<env>.php to denote that they're for apps, and so by default we don't end up with a bunch of files like conf/config.<appname>.config.php :)

    Elefant updates still need to contend with a modified conf/<env>.php, which probably ought to be solved next, but at least now app updates are simplified. Also need to update the docs for it, and modify the instructions in the default apps/*/conf/config.php files too now!

  • Btw, thanks for the help! Didn't mean to jump in but happened to be poking around in Controller for something else while this was in the back of my head. Got me sidetracked... :)

  • At least now I can find the value of y when adding x + z together. :-(

Sign In or Register to comment.