[Solar-talk] Organizing multiple Solar applications

[Rodrigo Moraes]

On 11/11/06, Andreas Ravnestad wrote:
> (I'm quoting "vendor" because in this context I'm
> thinking more of them like applications and not vendors).

You can think in "vendors" like "directories" or "namespaces". A
vendor is a namespace where you put some apps. You can have multiple
vendors with one app each or one vendor with multiple apps .
Personally I think it is easier to manage just one  - it is easier to
share helpers and view parts, and you centralize your development in
one common root. The same vendor can have distinct and very separated
apps. But of course this depends on your project.

> [ A side note: the corresponding directories (/Journal, /Map, etc) are
> locked down with a htaccess file to prevent snoopers from browsing around ]

I prefer to redirect all requests that don't find a physical file or
dir to index.php, using mod_rewrite. This is my .htaccess:

RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1

> But of course this only works as long as there are no identical
> controllers in the various application directories - and Solar will of
> course look up the first controller class that matches, ignoring the
> remaining controllers that might match.
>
> One solution to this is to add an entry point to each application
> directory and let them live their own lives completely.

Other solution is to use a "mapper" (or "router") that maps /Journal
to Vendor_App_Journal and /OtherJournal to OtherVendor_App_Journal.
But of course I'm shamelessly trying to push what I've been doing the
last week - the Router port from Zend Framework. :-)

> But there are a
> few problems with this. For example, for any given "vendor", I may want
> to be able to access a few classes in some other application (using
> Solar::loadClass()). This means that if the entry point is switched from
> /index.php to /Map/index.php, I'd have to modify the include path to
> include the parent directory, + a few other non-relevant hacks.

Indeed, multiple entry points can solve your problem for a while but
can become complicated for maintenance. The best is to have just one,
and put the logic for specific dirs in a class, so you need to manage
just one file and not multiple files in multiple dirs.

> So I decide that /index.php remains the entry point, because it
> determines which application (or "vendor") that should be used in a
> request based on the subdomain in the request anyways. But the problem
> with the duplicate controllers remain. So here's what I do:
>
> In each application directory, I put a solar.config.php, with specific
> settings for that application (for example, /Map/solar.config.php). And
> in the entry point (/index.php), I simply include the proper config file
> when starting solar, based on the subdomain - and this works perfectly.
> I get full granularity on the classes, and I get the right include path
> without hacks.

This is what I use for the bootstrap:

<?php
set_include_path(
    '/var/www/tiposnew/Framework'
    . PATH_SEPARATOR . get_include_path()
);

// Load, build and run Tipos.
require_once 'Tipos.php';
$tipos = new Tipos();
$tipos->run();
?>

The 'Tipos' class loads Solar and manages how the config is loaded.
I'm using it because I need to combine config files at some point and
cache the config. The whole idea is to keep the bootstrap *the same*
forever and anywhere. Any additional logic I need is added to
Tipos::run().

The result is the same, I just prefer to have the minimum amount of
logic in the bootstrap, so you can use the same everywhere and not
depending on which app you are running.

> Now my questions: is this a proper way to do it? Are there better ways
> to do this that you can think of? For example, should I completely
> isolate these applications and use virtual host configuration in apache
> to execute the proper applications?

It s the proper way if it solves your problem. :-)
Hoho, but of course this doesn't help much. So, in the end:
- I think your solution is fine. :-)

And:
- You can redirect all requests to index.php instead of locking dirs,
and then deal with bad requests inside your apps.
- A router (or "mapper") can allow two applications with the same name
('Journal') to be mapped (or "routed" ;-) depending on your needs.
- I think it is a nice idea to have a main class to start Solar. It
can deal with configs and any other basic initializations you need.
Besides configs, I use mine to start a plugin system together with
Solar. By the way, the Event_Dispatcher port has evolved a bit in the
last week. Oh no, I'm pushing myself again. :-)

cheers,
rodrigo

---------------------------------------------------------------------
Solar has now a Community Wiki: solarphp.org
---------------------------------------------------------------------
Join the #solarphp IRC channel on freenode.org
---------------------------------------------------------------------