|
Vendor_App and Public
Hi everyone,
Right now, all public assets are in Vendor_App_Public, like so:
Vendor/
App/
Foo.php/
Foo/
Bar.php/
Bar/
...
Public/
images/
...
styles/
...
app/
foo.css
bar.css
scripts/
...
And then that one Public directory gets symlinked to the document root:
$system/
source/
vendor/
Vendor/
App/
Public/
...
include/
Vendor/ -> ../source/vendor/Vendor
docroot/
public/
Vendor/ -> ../../include/Vendor/App/Public
I'm beginning to think that it might be better overall have a Public
directory with each individual app, like this:
Vendor/
App/
Foo.php
Foo/
Public/
image.jpg
style.css
script.js
Bar.php
Bar
Public/
image.jpg
style.css
script.js
Of course, that means one symlink per app, instead of one symlink for
all apps:
$system/
source/
vendor/
Vendor/
App/
Foo.php
Foo/
Public/
...
Bar.php
Bar/
Public/
...
include/
Vendor/ -> ../../source/vendor/Vendor
docroot/
public/
Vendor/
App/
Foo/ -> ../../../../include/Vendor/App/Foo/Public
Bar/ -> ../../../../include/Vendor/App/Bar/Public
That's added hassle, to be sure. I think the make-app script can make
that symlink as part of its process, which I think will make that less
onerous to deal with.
The real benefit of this is not for apps, though. It is for any
library that might need to provide public assets. For example, a
module (even though I don't do modules, I know you guys do), or a
helper (e.g. a JavaScript helper that provides its own libraries)
could use this for its own assets. They will no longer be tied to the
Vendor_App_Public directory; they can provide the assets themselves.
$system/
source/
vendor/
Vendor/
Module/
Dib.php
Dib/
Public/
...
View/
Helper/
Zim.php
Zim/
Public/
...
include/
Vendor/ -> ../../source/vendor/Vendor
docroot/
public/
Vendor/
Module/
Dib/ -> ../../../include/Vendor/Module/Dib/Public
View/
Helper/
Zim/ -> ../../../include/Vendor/View/Helper/
Zim/Public
This would, in theory, help pave the way for Vendor packages that have
no apps themselves, but are only collections of helpers, modules, and
other support libraries.
Currently, there is no command-line script to help with making
symlinks for these kinds of assets; I'm thinking there could be a
"link-public Vendor_Class_Name" script to do create the symlinks.
Thoughts, for or against?
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
I have to think through this but I really like the idea of 'vendor packages'
that are not applications but rather collections of pieces. So anything that
better supports that gets my vote.
James Kilbride
-----Original Message-----
From: solar-talk-bounces@...
[mailto: solar-talk-bounces@...] On Behalf Of Paul M Jones
Sent: Tuesday, August 25, 2009 10:40 AM
To: solar-talk@...
Subject: [Solar-talk] Vendor_App and Public
Hi everyone,
Right now, all public assets are in Vendor_App_Public, like so:
Vendor/
App/
Foo.php/
Foo/
Bar.php/
Bar/
...
Public/
images/
...
styles/
...
app/
foo.css
bar.css
scripts/
...
And then that one Public directory gets symlinked to the document root:
$system/
source/
vendor/
Vendor/
App/
Public/
...
include/
Vendor/ -> ../source/vendor/Vendor
docroot/
public/
Vendor/ -> ../../include/Vendor/App/Public
I'm beginning to think that it might be better overall have a Public
directory with each individual app, like this:
Vendor/
App/
Foo.php
Foo/
Public/
image.jpg
style.css
script.js
Bar.php
Bar
Public/
image.jpg
style.css
script.js
Of course, that means one symlink per app, instead of one symlink for
all apps:
$system/
source/
vendor/
Vendor/
App/
Foo.php
Foo/
Public/
...
Bar.php
Bar/
Public/
...
include/
Vendor/ -> ../../source/vendor/Vendor
docroot/
public/
Vendor/
App/
Foo/ -> ../../../../include/Vendor/App/Foo/Public
Bar/ -> ../../../../include/Vendor/App/Bar/Public
That's added hassle, to be sure. I think the make-app script can make
that symlink as part of its process, which I think will make that less
onerous to deal with.
The real benefit of this is not for apps, though. It is for any
library that might need to provide public assets. For example, a
module (even though I don't do modules, I know you guys do), or a
helper (e.g. a JavaScript helper that provides its own libraries)
could use this for its own assets. They will no longer be tied to the
Vendor_App_Public directory; they can provide the assets themselves.
$system/
source/
vendor/
Vendor/
Module/
Dib.php
Dib/
Public/
...
View/
Helper/
Zim.php
Zim/
Public/
...
include/
Vendor/ -> ../../source/vendor/Vendor
docroot/
public/
Vendor/
Module/
Dib/ -> ../../../include/Vendor/Module/Dib/Public
View/
Helper/
Zim/ -> ../../../include/Vendor/View/Helper/
Zim/Public
This would, in theory, help pave the way for Vendor packages that have
no apps themselves, but are only collections of helpers, modules, and
other support libraries.
Currently, there is no command-line script to help with making
symlinks for these kinds of assets; I'm thinking there could be a
"link-public Vendor_Class_Name" script to do create the symlinks.
Thoughts, for or against?
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk _______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
> I'm beginning to think that it might be better overall have a Public
> directory with each individual app, like this:
> Of course, that means one symlink per app, instead of one symlink for
> all apps:
It is more of a pain to setup, but I think the possible advantages would out-
weigh the hassle.
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Aug 25, 2009, at 13:31 , Jeff Surgeson wrote:
>> I'm beginning to think that it might be better overall have a Public
>> directory with each individual app, like this:
>
>> Of course, that means one symlink per app, instead of one symlink for
>> all apps:
>
> It is more of a pain to setup, but I think the possible advantages
> would out-
> weigh the hassle.
I tend to agree on both points (the pain, and the benefit). Thanks
for weighing in, Jeff. :-)
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
 Re: Vendor_App and Public
Hello,
I don't personally see myself ever needing an app-specific public
folder, but having the flexibility to do so might be worthwhile. As
you said, I can see how it might be handy for modules or components or
whatever you might call them. However, It certainly seems like a lot
of folders and symlinks to keep track of. I wouldn't want to set them
up without a script. If this could be optional, I would buy into it.
If I had, say, 15 apps in my Vendor, I don't know that I would want to
look in my docroot/public folder and see 15+ folders for assets, most
of which will be empty. Maybe the make-app script could include a
parameter like --with-public that if set, creates the app-specific
public folder and symlinks. Or, as you mentioned, a separate script to
add app-specific public folders and symlinks after the fact.
It's interesting how the view helpers could be moving more toward the
Vendor level, and public assets more to the app level.
Jon
On Tue, Aug 25, 2009 at 11:00 AM, < solar-talk-request@...> wrote:
>
> Message: 3
> Date: Tue, 25 Aug 2009 09:40:02 -0500
> From: Paul M Jones < pmjones@...>
> Subject: [Solar-talk] Vendor_App and Public
> To: solar-talk@...
> Message-ID: < CFDE7E81-A3D1-425F-B66D-D979AA9D7F4F@...>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Hi everyone,
>
> Right now, all public assets are in Vendor_App_Public, like so:
>
> Vendor/
> App/
> Foo.php/
> Foo/
> Bar.php/
> Bar/
> ...
> Public/
> images/
> ...
> styles/
> ...
> app/
> foo.css
> bar.css
> scripts/
> ...
>
> And then that one Public directory gets symlinked to the document root:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Public/
> ...
> include/
> Vendor/ -> ../source/vendor/Vendor
> docroot/
> public/
> Vendor/ -> ../../include/Vendor/App/Public
>
> I'm beginning to think that it might be better overall have a Public
> directory with each individual app, like this:
>
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> image.jpg
> style.css
> script.js
> Bar.php
> Bar
> Public/
> image.jpg
> style.css
> script.js
>
> Of course, that means one symlink per app, instead of one symlink for
> all apps:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> ...
> Bar.php
> Bar/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> App/
> Foo/ -> ../../../../include/Vendor/App/Foo/Public
> Bar/ -> ../../../../include/Vendor/App/Bar/Public
>
> That's added hassle, to be sure. I think the make-app script can make
> that symlink as part of its process, which I think will make that less
> onerous to deal with.
>
> The real benefit of this is not for apps, though. It is for any
> library that might need to provide public assets. For example, a
> module (even though I don't do modules, I know you guys do), or a
> helper (e.g. a JavaScript helper that provides its own libraries)
> could use this for its own assets. They will no longer be tied to the
> Vendor_App_Public directory; they can provide the assets themselves.
>
> $system/
> source/
> vendor/
> Vendor/
> Module/
> Dib.php
> Dib/
> Public/
> ...
> View/
> Helper/
> Zim.php
> Zim/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> Module/
> Dib/ -> ../../../include/Vendor/Module/Dib/Public
> View/
> Helper/
> Zim/ -> ../../../include/Vendor/View/Helper/
> Zim/Public
>
> This would, in theory, help pave the way for Vendor packages that have
> no apps themselves, but are only collections of helpers, modules, and
> other support libraries.
>
> Currently, there is no command-line script to help with making
> symlinks for these kinds of assets; I'm thinking there could be a
> "link-public Vendor_Class_Name" script to do create the symlinks.
>
> Thoughts, for or against?
>
>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/>
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
I think the restructuring is a good idea, but only with a script to
automate the symlinks. Furthermore, since not every hosting
environment allows you to make such links, the script *should* have
the ability to copy all the public files to a folder under doc root.
This would allow Solar to function better under Windows and
restrictive hosting packages.
On Tue, Aug 25, 2009 at 10:40 AM, Paul M Jones< pmjones@...> wrote:
> Hi everyone,
>
> Right now, all public assets are in Vendor_App_Public, like so:
>
> Vendor/
> App/
> Foo.php/
> Foo/
> Bar.php/
> Bar/
> ...
> Public/
> images/
> ...
> styles/
> ...
> app/
> foo.css
> bar.css
> scripts/
> ...
>
> And then that one Public directory gets symlinked to the document root:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Public/
> ...
> include/
> Vendor/ -> ../source/vendor/Vendor
> docroot/
> public/
> Vendor/ -> ../../include/Vendor/App/Public
>
> I'm beginning to think that it might be better overall have a Public
> directory with each individual app, like this:
>
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> image.jpg
> style.css
> script.js
> Bar.php
> Bar
> Public/
> image.jpg
> style.css
> script.js
>
> Of course, that means one symlink per app, instead of one symlink for
> all apps:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> ...
> Bar.php
> Bar/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> App/
> Foo/ -> ../../../../include/Vendor/App/Foo/Public
> Bar/ -> ../../../../include/Vendor/App/Bar/Public
>
> That's added hassle, to be sure. I think the make-app script can make
> that symlink as part of its process, which I think will make that less
> onerous to deal with.
>
> The real benefit of this is not for apps, though. It is for any
> library that might need to provide public assets. For example, a
> module (even though I don't do modules, I know you guys do), or a
> helper (e.g. a JavaScript helper that provides its own libraries)
> could use this for its own assets. They will no longer be tied to the
> Vendor_App_Public directory; they can provide the assets themselves.
>
> $system/
> source/
> vendor/
> Vendor/
> Module/
> Dib.php
> Dib/
> Public/
> ...
> View/
> Helper/
> Zim.php
> Zim/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> Module/
> Dib/ -> ../../../include/Vendor/Module/Dib/Public
> View/
> Helper/
> Zim/ -> ../../../include/Vendor/View/Helper/
> Zim/Public
>
> This would, in theory, help pave the way for Vendor packages that have
> no apps themselves, but are only collections of helpers, modules, and
> other support libraries.
>
> Currently, there is no command-line script to help with making
> symlinks for these kinds of assets; I'm thinking there could be a
> "link-public Vendor_Class_Name" script to do create the symlinks.
>
> Thoughts, for or against?
>
>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/>
>
>
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk>
--
IAN SZEWCZYK
roamzero@...
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
Ian, As much as I like the symlinks and how they help Solar with the deeply nested stack, I also have been subject to environments that don't allow symlinks. I made a post about the changes I made to make Solar work without the symlinks found here: http://agentile.com/view/28/solarphp-on-mosso/
Unfortunately, /script/solar ties in with the symlinks, so trying to use it(running tests, make-vendor, etc) without the symlinks won't work with my changes. Hopefully you will find it useful as I have with windows/shared hosting environments. Not sure if removing the symlinks from the path stack equation is something that would eventually be changed in Solar or not.
Anthony Gentile On Wed, Aug 26, 2009 at 2:17 AM, Ian Szewczyk <roamzero@...> wrote:
I think the restructuring is a good idea, but only with a script to
automate the symlinks. Furthermore, since not every hosting
environment allows you to make such links, the script *should* have
the ability to copy all the public files to a folder under doc root.
This would allow Solar to function better under Windows and
restrictive hosting packages.
On Tue, Aug 25, 2009 at 10:40 AM, Paul M Jones< pmjones@...> wrote:
> Hi everyone,
>
> Right now, all public assets are in Vendor_App_Public, like so:
>
> Vendor/
> App/
> Foo.php/
> Foo/
> Bar.php/
> Bar/
> ...
> Public/
> images/
> ...
> styles/
> ...
> app/
> foo.css
> bar.css
> scripts/
> ...
>
> And then that one Public directory gets symlinked to the document root:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Public/
> ...
> include/
> Vendor/ -> ../source/vendor/Vendor
> docroot/
> public/
> Vendor/ -> ../../include/Vendor/App/Public
>
> I'm beginning to think that it might be better overall have a Public
> directory with each individual app, like this:
>
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> image.jpg
> style.css
> script.js
> Bar.php
> Bar
> Public/
> image.jpg
> style.css
> script.js
>
> Of course, that means one symlink per app, instead of one symlink for
> all apps:
>
> $system/
> source/
> vendor/
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> ...
> Bar.php
> Bar/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> App/
> Foo/ -> ../../../../include/Vendor/App/Foo/Public
> Bar/ -> ../../../../include/Vendor/App/Bar/Public
>
> That's added hassle, to be sure. I think the make-app script can make
> that symlink as part of its process, which I think will make that less
> onerous to deal with.
>
> The real benefit of this is not for apps, though. It is for any
> library that might need to provide public assets. For example, a
> module (even though I don't do modules, I know you guys do), or a
> helper (e.g. a JavaScript helper that provides its own libraries)
> could use this for its own assets. They will no longer be tied to the
> Vendor_App_Public directory; they can provide the assets themselves.
>
> $system/
> source/
> vendor/
> Vendor/
> Module/
> Dib.php
> Dib/
> Public/
> ...
> View/
> Helper/
> Zim.php
> Zim/
> Public/
> ...
> include/
> Vendor/ -> ../../source/vendor/Vendor
> docroot/
> public/
> Vendor/
> Module/
> Dib/ -> ../../../include/Vendor/Module/Dib/Public
> View/
> Helper/
> Zim/ -> ../../../include/Vendor/View/Helper/
> Zim/Public
>
> This would, in theory, help pave the way for Vendor packages that have
> no apps themselves, but are only collections of helpers, modules, and
> other support libraries.
>
> Currently, there is no command-line script to help with making
> symlinks for these kinds of assets; I'm thinking there could be a
> "link-public Vendor_Class_Name" script to do create the symlinks.
>
> Thoughts, for or against?
>
>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/
>
>
>
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk
>
IAN SZEWCZYK
roamzero@...
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Tue, Aug 25, 2009 at 5:40 PM, Paul M Jones< pmjones@...> wrote:
> I'm beginning to think that it might be better overall have a Public
> directory with each individual app, like this:
>
> Vendor/
> App/
> Foo.php
> Foo/
> Public/
> image.jpg
> style.css
> script.js
> Bar.php
> Bar
> Public/
> image.jpg
> style.css
> script.js
>
> Of course, that means one symlink per app, instead of one symlink for
> all apps:
I've been already doing this with some apps, and I think it makes
sense. And this doesn't change any code, so it's not a biggie.
--
-antti
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Aug 26, 2009, at 01:17 , Ian Szewczyk wrote:
> I think the restructuring is a good idea, but only with a script to
> automate the symlinks.
Agreed on the automation; without it, the symlinks would be way too
big a hassle.
> Furthermore, since not every hosting
> environment allows you to make such links, the script *should* have
> the ability to copy all the public files to a folder under doc root.
> This would allow Solar to function better under Windows and
> restrictive hosting packages.
Huh, now that's an interesting thought. I see where, in addition to
"make-public" (or "link-public"), we could have a "copy-public" as
well. The operation would be identical, but would use "cp"
equivalents instead of "ln" equivalents. It would still be the case
that, as you updated public resources in the package, you would need
to "copy-public" each time, but it would reduce the hassle of that
operation.
Does "copy-public" sounds like a reasonable addition to the "(make|
link)-public" plan?
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Aug 25, 2009, at 22:37 , Jon Elofson wrote:
> I don't personally see myself ever needing an app-specific public
> folder, but having the flexibility to do so might be worthwhile. As
> you said, I can see how it might be handy for modules or components or
> whatever you might call them. However, It certainly seems like a lot
> of folders and symlinks to keep track of.
Yeah, I can see where it could become a lot pretty easily.
> I wouldn't want to set them up without a script.
Oh I totally agree. Without a script for it, the idea would be a non-
starter.
> If this could be optional, I would buy into it.
Actually, I think it *kind of* could be. You could, if you wanted,
put all your public assets in the single Vendor/App/Base/Public
directory (or Vendor/Controller/Page/Public directory), and be done
with it. The remaining app-specific public folders can remain empty,
or even removed from the docroot/public directory. Would that be
sufficient?
> It's interesting how the view helpers could be moving more toward the
> Vendor level, and public assets more to the app level.
A funny, but accurate, observation; I hadn't thought about it that
way. :-)
It has to do with how the public assets tend to be tied to specific
apps (like stylesheets and images), and how helpers tend to be used
across all apps. Seeing Vendors with a single Public directory, but
with subdirectories for each app and helper that uses JS libs, has a
lot to do with what led to this idea for change.
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
I have been thinking of some sort of "public" file handler for a while
now... Something to do things like push public files to S3, handle
auto shrinking javascript and such..
So.. my comment on this is if we do have a public file manager it
should be configurable.. Instead of a make-public, copy-public.. just
a make-public with configuration values
So make-public could follow any of the possible paths
1. Create sym-links
2. Rsync to a public/remote directory (think cdn)
3. Copy to a public directory
4. Run my own custom adapter that builds my public directory in a temp
fold, shrinks my javascript files and pushes it to my cdn.
Richard Thomas
http://www.cyberlot.netOn Aug 27, 2009, at 12:49 PM, Paul M Jones wrote:
>
> On Aug 26, 2009, at 01:17 , Ian Szewczyk wrote:
>
>> I think the restructuring is a good idea, but only with a script to
>> automate the symlinks.
>
> Agreed on the automation; without it, the symlinks would be way too
> big a hassle.
>
>
>> Furthermore, since not every hosting
>> environment allows you to make such links, the script *should* have
>> the ability to copy all the public files to a folder under doc root.
>> This would allow Solar to function better under Windows and
>> restrictive hosting packages.
>
> Huh, now that's an interesting thought. I see where, in addition to
> "make-public" (or "link-public"), we could have a "copy-public" as
> well. The operation would be identical, but would use "cp"
> equivalents instead of "ln" equivalents. It would still be the case
> that, as you updated public resources in the package, you would need
> to "copy-public" each time, but it would reduce the hassle of that
> operation.
>
> Does "copy-public" sounds like a reasonable addition to the "(make|
> link)-public" plan?
>
>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/>
>
>
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
The cdn is the interesting case here. What happens when you're
"public" directory goes on a cdn like cloud front?
On Aug 27, 2009, at 1:23 PM, Richard Thomas wrote:
> I have been thinking of some sort of "public" file handler for a while
> now... Something to do things like push public files to S3, handle
> auto shrinking javascript and such..
>
> So.. my comment on this is if we do have a public file manager it
> should be configurable.. Instead of a make-public, copy-public.. just
> a make-public with configuration values
>
> So make-public could follow any of the possible paths
>
> 1. Create sym-links
> 2. Rsync to a public/remote directory (think cdn)
> 3. Copy to a public directory
> 4. Run my own custom adapter that builds my public directory in a temp
> fold, shrinks my javascript files and pushes it to my cdn.
>
>
> Richard Thomas
> http://www.cyberlot.net>
>
>
>
> On Aug 27, 2009, at 12:49 PM, Paul M Jones wrote:
>
>>
>> On Aug 26, 2009, at 01:17 , Ian Szewczyk wrote:
>>
>>> I think the restructuring is a good idea, but only with a script to
>>> automate the symlinks.
>>
>> Agreed on the automation; without it, the symlinks would be way too
>> big a hassle.
>>
>>
>>> Furthermore, since not every hosting
>>> environment allows you to make such links, the script *should* have
>>> the ability to copy all the public files to a folder under doc root.
>>> This would allow Solar to function better under Windows and
>>> restrictive hosting packages.
>>
>> Huh, now that's an interesting thought. I see where, in addition to
>> "make-public" (or "link-public"), we could have a "copy-public" as
>> well. The operation would be identical, but would use "cp"
>> equivalents instead of "ln" equivalents. It would still be the case
>> that, as you updated public resources in the package, you would need
>> to "copy-public" each time, but it would reduce the hassle of that
>> operation.
>>
>> Does "copy-public" sounds like a reasonable addition to the "(make|
>> link)-public" plan?
>>
>>
>>
>>
>> --
>>
>> Paul M. Jones
>> http://paul-m-jones.com/>>
>>
>>
>>
>> _______________________________________________
>> Solar-talk mailing list
>> Solar-talk@...
>> http://mailman-mail5.webfaction.com/listinfo/solar-talk>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Aug 27, 2009, at 15:23 , Richard Thomas wrote:
> I have been thinking of some sort of "public" file handler for a while
> now... Something to do things like push public files to S3, handle
> auto shrinking javascript and such..
>
> So.. my comment on this is if we do have a public file manager it
> should be configurable.. Instead of a make-public, copy-public.. just
> a make-public with configuration values
To be clear, I'm not talking about a "public file manager" proper, but
a plan to move away from a single Vendor/App/Public directory (for
apps only), to a way for separate portions of the Vendor space to have
easier access to docroot/public.
Once docroot/public is populated (probably with a "copy-public"
because you need the files themselves), a secondary business-specific
script could copy it out to a CDN.
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Aug 27, 2009, at 15:36 , Jeff Moore wrote:
> The cdn is the interesting case here. What happens when you're
> "public" directory goes on a cdn like cloud front?
This is a reasonable concern for high-traffic sites.
Speaking off the cuff, once docroot/public is populated with links to
or copies of all the Vendor/*/Public files, you might:
1. Rsync or otherwise copy to the docroot/public compilation out to
the CDN, and
2. Set $config['Solar_Uri_Public']['host'] and ['path'] values to
point to the CDN.
Does that sounds like it might work?
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
Thats similiar to how I have handled it in the past..
Last time I dealt with a cdn in production we kept the pubic directory
on the servers as a fall back and had a check in the Solar config that
pulled the cdn url out of memcache.
This was then populated by a script that was constantly checking the
cdn to see if it was up.
Way beyond the scope of all this, just saying even while using a cdn
most people also have use for the public directory as dev/failover.
The main point being, the ability to do a callback on the whole copy
public idea would be nice so a single action can solve all of someones
needs.
Richard Thomas
http://www.cyberlot.netOn Aug 27, 2009, at 2:09 PM, Paul M Jones wrote:
> On Aug 27, 2009, at 15:36 , Jeff Moore wrote:
>
>> The cdn is the interesting case here. What happens when you're
>> "public" directory goes on a cdn like cloud front?
>
> This is a reasonable concern for high-traffic sites.
>
> Speaking off the cuff, once docroot/public is populated with links to
> or copies of all the Vendor/*/Public files, you might:
>
> 1. Rsync or otherwise copy to the docroot/public compilation out to
> the CDN, and
> 2. Set $config['Solar_Uri_Public']['host'] and ['path'] values to
> point to the CDN.
>
> Does that sounds like it might work?
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/>
>
>
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
Hi everyone,
The branches/beta directory in SVN now carries the features discussed
earlier in this thread.
- Vendor/App/Public no longer exists by default (although you can
create it yourself, and can use it if you already have it)
- Each class may now have a Public subdirectory for its public assets
(if any).
- Because linking individual classes to docroot/public is tedious, the
new "link-public" command searches through a given starting class and
creates the public symlinks for you.
- The make-app command now creates a Vendor/App/{:name}/Public
directory and links it for you.
By way of examples, see Solar_App_Base, Solar_App_Bookmarks, and
Solar_View_Helper_Pager.
Additionally, there are two new commands not previously discussed:
`link-vendor` and `unlink-vendor`. These create and remove the
necessary symlinks from source/ to the rest of the Solar system. This
means you can now download a Solar vendor library to source/, and call
link-vendor to create the necessary symlinks into your system.
Finally, I have created a "beta" Solar system branch with the above
features in place; you can see it at < http://svn.solarphp.com/system/branches/beta/
>.
I look forward to feedback on this new approach; thanks, everyone.
--
Paul M. Jones
http://paul-m-jones.com/_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
|
Re: Vendor_App and Public
On Tuesday, September 29, 2009, Paul M Jones < pmjones@...> wrote:
> Hi everyone,
>
> The branches/beta directory in SVN now carries the features discussed
> earlier in this thread.
>
> - Vendor/App/Public no longer exists by default (although you can
> create it yourself, and can use it if you already have it)
>
> - Each class may now have a Public subdirectory for its public assets
> (if any).
>
> - Because linking individual classes to docroot/public is tedious, the
> new "link-public" command searches through a given starting class and
> creates the public symlinks for you.
>
> - The make-app command now creates a Vendor/App/{:name}/Public
> directory and links it for you.
>
> By way of examples, see Solar_App_Base, Solar_App_Bookmarks, and
> Solar_View_Helper_Pager.
>
> Additionally, there are two new commands not previously discussed:
> `link-vendor` and `unlink-vendor`. These create and remove the
> necessary symlinks from source/ to the rest of the Solar system. This
> means you can now download a Solar vendor library to source/, and call
> link-vendor to create the necessary symlinks into your system.
>
> Finally, I have created a "beta" Solar system branch with the above
> features in place; you can see it at < http://svn.solarphp.com/system/branches/beta/> >.
>
> I look forward to feedback on this new approach; thanks, everyone.
Very nice, I like it a lot.
--
-antti
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk
|
smime.p7s (3K) 