[Solar-talk] Change to Solar system assumptions?

[Richard Thomas]

I tend to be a neat freak myself and really like to keep my "work"
seperate from third party libraries, So I tend to have for example an
"internal" -> My code and an "external" -> third party code/solar
directory

Also, I really like to keep my images/static content in its own
separate tree to make it easy to publish to CDN's/Static only servers.

On Mon, May 19, 2008 at 4:28 AM, Kilbride, James P.
<James.Kilbride at gd-ais.com> wrote:
> 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
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk at lists.solarphp.com
> http://mailman-mail3.webfaction.com/listinfo/solar-talk
>