[Solar-talk] Organizing multiple Solar applications

[Andreas Ravnestad]

>
>> [ 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
>   

Actually this only redirects if the file or folder isn't found (that's 
what the RewriteConds are for), so people can still browse your 
subfolders if they know what they're called :)


>   
>> 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. :-)
>   

Ah, that would be nice. Can your router do that now? Got an example of 
how to set that up?



>   
>> 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. :-)
>   
Great - it's not that much of a big deal either, won't be a problem to 
refactor this later if I find a better way.


> 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.
>   
Yes, though this would integrate my applications a bit tighter than I'd 
like - but under slightly different circumstances I would probably have 
done this too!

> 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. :-)
>   
Looking forward to it :)

-Andreas