[Solar-talk] Change to Solar system assumptions?

[Kilbride, James P.]

I actually keep even an alias out of the docroot for solar and have,
ussually at the root directory of the machine, a solar folder(which
contains the project code). In my docroot I set up each application
independent of the rest by having their own folders for each, and their
own index.php files and each one calls it's own config files which lets
solar know only about their 'vendor' data. They all share the same solar
library though. Our production/test server has two seperate copies of
everything though but it works on the same principle. The test folders
override the include though and point to the test solar installation.
Other than that everything is nearly identical between the two. I like
having solar be usable for both indepedent and shared library
structures. I tend to prefer to use a common library where possible but
be able to have multiple copies of the library installed in case things
change dramatically.

James Kilbride

-----Original Message-----
From: solar-talk-bounces at lists.solarphp.com
[mailto:solar-talk-bounces at lists.solarphp.com] On Behalf Of Jeff Moore
Sent: Saturday, May 17, 2008 7:54 PM
To: solar-talk at lists.solarphp.com
Subject: Re: [Solar-talk] Change to Solar system assumptions?

Hi,

I think one consideration is that deployment and development directory
structures have different needs.

For example, during development, I prefer to break things up into "our
code" and "other people's code".  I don't want either of these to be a
subdirectory of the other, because it makes day to day searching through
code harder and slower.  At development time, I can use include_path to
stitch together code from my project directory and the PEAR repository
directory (other people's code).

At deployment time, I can resolve the include_path segments and just put
everything in a single directory tree.  The PEAR installer is good for
this, although I suppose you could do it with svn:externals if your
directories were setup well, or if you wanted to use one svn:external
for Solar.php and another for the Solar directory.

The kink is the webserver doc root.  I guess the Solar way is to alias a
public directory into the docroot.  But, I would prefer a merging of
public directories, rather than a unique directory per library.  PEAR
installer can do the merging of public directories at deployment time,
but there is no web server equivalent to include_path that searches
multiple directories for http://www.example.com/resource to make a
multiple directory development structure usable.  (is there?)

Jeff


On May 17, 2008, at 8:47 AM, Paul M Jones wrote:

> Hi everyone,
>
> Since its beginning, Solar development has been very much an extension

> of how PEAR does things.  PEAR assumes that there is one one shared 
> library for all applications and projects; sometimes the shared 
> library is for the entire server, sometimes it is for all the projects

> for one user on a server, but "shared everything" has been the 
> foundational assumption.  Even if you have multiple projects, PEAR 
> expects they will all use a common library set.
>
> The Ruby on Rails crowd, and their imitators in the Symfony and Cake 
> projects, have a different approach.  With them, you have one self- 
> contained project system, and no references to anything outside that 
> system.  If you have multiple projects, you have multiple separate 
> library collections for them.  This means that core libraries are 
> usually duplicated across projects.
>
> Over the past few weeks, I come to believe that the Rails (et al) 
> approach is the more effective solution for web application projects.

> I think that Solar, while still maintaining itself as a 
> PEAR-library-style framework, should start assuming that it will be 
> part of a project-specific system, not a server-wide system.
>
> There are a few implications of this change in approach:
>
> * The PEAR-style distribution of Solar as a library set should not 
> change; you should still be able to `pear upgrade Solar` for PEAR 
> compatibility.
>
> * There should be a *second* distribution mechanism: a downloadable 
> "project directory" with the full project structure already in place, 
> Solar in the "source" and "include" directories, the bootstrap file in

> the "docroot" directory, and so on.  This will make first-time setups 
> much easier.
>
> * The binary `solar` CLI tool should *not* look through the server in 
> various places for its config files.  Instead, it should look in the 
> project "config" directory.  (You can still specify an alternate 
> config file with --config.)  (The same would be true for the bootstrap

> file -- it should look in the "config" directory.)
>
> Those are all the changes I can think of that would apply with the 
> "project-specific" assumptions (rather than "system-wide"
> assumptions).
>
> I'd like to hear any and all criticism of this proposed change to the 
> Solar assumptions.  I think we're all doing our projects this way, but

> I want to make sure I'm not missing anything.
>
>
> -- pmj
> _______________________________________________
> Solar-talk mailing list
> Solar-talk at lists.solarphp.com
> http://mailman-mail3.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk at lists.solarphp.com
http://mailman-mail3.webfaction.com/listinfo/solar-talk