Quantcast

Discussion Time: In ZF2, Where Do Things Go?

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Discussion Time: In ZF2, Where Do Things Go?

Ralph Schindler-2
This is not about what an application looks like, has nothing to do with
models, views, controllers, or any other application structure and
resource placement.  This is simply about the "Zend Framework
distribution".  In fact, this is not even about our build and packaging.

The questions are fairly simple: where do things go?  Currently, our
directory structure looks like this:

ZendFramework/
     bin/
     documentation/
     externals/
     library/
     resources/
     tests/

There are a couple of other things in there, but you get the picture.
Traditionally, the library directory is suppose to be for php class
files only. The idea here is they can be found with an
autoloader/require_once/whatever and loaded based off some name.  This
directory should not be patched in any way shape or form, and there
should be no expectation to add/alter/remove anything within it to have
working components.

More often than not, library components require non-php-class resources,
and the question is begged: where should these be located?

By putting them inside the library, they are relative to the code that
is requiring them.  Being relative, they can be found and loaded quite
easily.  But, with them in this location, developers might be inclined
to alter them in the library folder, thus violating the "don't touch
this" rule from above.

Putting them in the resources folder adds some clarity to their role
that they are non-php-classes, but detaches them from code requiring
them.  By doing this, the code now has to understand the "installation"
of the component/library.  In this case, it would be necessary for our
library code to perhaps have some kind of constant to track where
resources are, for example ZEND_RESOURCE_PATH, or something similar.

This idea is further enforced by the structure of the PEAR system.  PEAR
allows for placement of package assets (for example):

     PEAR executables directory     bin_dir          /usr/bin
     PEAR documentation directory   doc_dir          /usr/lib/php/doc
     PHP extension directory        ext_dir
/usr/lib/php/extensions/no-debug-non-zts-20090626
     PEAR directory                 php_dir          /usr/lib/php
     PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
     PEAR configuration file        cfg_dir          /usr/lib/php/cfg
     PEAR data directory            data_dir         /usr/lib/php/data
     PEAR Installer download        download_dir     /var/tmp/pear/download
     PHP CLI/CGI binary             php_bin          /usr/bin/php
     php.ini location               php_ini          <not set>
     PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
     PEAR test directory            test_dir         /usr/lib/php/test
     PEAR www files directory       www_dir          /usr/lib/php/htdocs

While some of this doesn't apply to Zend Framework, it does enforce a
top level that encourages each directory to have a specific purpose, and
a component/package will be disassembled and put into its proper place
according to the system.

The alternative to this is to keep resources within the components
directory itself.  Here is my for instance I'd like you to think of:

   Zend\Tool will be able to ship multiple project profiles out
   the box in ZF2.  These might be xml, yaml, or even json
   profiles.  Where do they go?  Where does a developer expect
   to add his to the installation?

If they exist inside the library folder, they are hidden, and the
developer might be encouraged to patch his library.  If they are located
outside the library, the library code needs to know where to look for
its default resources.

Once we understand how our distribution looks on disk, then I think we
can talk about "packaging".

-ralph



--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Dolf Schimmel
Based on our discussion on IRC...

I think it would indeed be good to suggest that files in library/ not
be edited for production purposes (anything but debugging). That eases
upgrading (also when it comes to packaging), is the only reasonable
way to provide any way of support, and may protect novice users
against themselves.

My proposal would be to store the resource files relative to the
components, so resource files for Zend\Db be stored in e.g.
library/Zend/Db/_resources/ . Then, if someone wanted to use a
different translation for one line (translation files = resources),
he/she should not alter the files in question. In fact, imho it should
be specified where alternative resource files can be found (be it
through Service Locator, be it through an options array to the
constructor), and then fall back to ZF's own resource files if a
string isn't found in the user's own resource files.

This in part discusses behavior too, but I think we cannot see
behavior and directory structure entirely separately.

Dolf
-- Freeaqingme



On Fri, Apr 1, 2011 at 6:08 PM, Ralph Schindler
<[hidden email]> wrote:

> This is not about what an application looks like, has nothing to do with
> models, views, controllers, or any other application structure and resource
> placement.  This is simply about the "Zend Framework distribution".  In
> fact, this is not even about our build and packaging.
>
> The questions are fairly simple: where do things go?  Currently, our
> directory structure looks like this:
>
> ZendFramework/
>    bin/
>    documentation/
>    externals/
>    library/
>    resources/
>    tests/
>
> There are a couple of other things in there, but you get the picture.
> Traditionally, the library directory is suppose to be for php class files
> only. The idea here is they can be found with an
> autoloader/require_once/whatever and loaded based off some name.  This
> directory should not be patched in any way shape or form, and there should
> be no expectation to add/alter/remove anything within it to have working
> components.
>
> More often than not, library components require non-php-class resources, and
> the question is begged: where should these be located?
>
> By putting them inside the library, they are relative to the code that is
> requiring them.  Being relative, they can be found and loaded quite easily.
>  But, with them in this location, developers might be inclined to alter them
> in the library folder, thus violating the "don't touch this" rule from
> above.
>
> Putting them in the resources folder adds some clarity to their role that
> they are non-php-classes, but detaches them from code requiring them.  By
> doing this, the code now has to understand the "installation" of the
> component/library.  In this case, it would be necessary for our library code
> to perhaps have some kind of constant to track where resources are, for
> example ZEND_RESOURCE_PATH, or something similar.
>
> This idea is further enforced by the structure of the PEAR system.  PEAR
> allows for placement of package assets (for example):
>
>    PEAR executables directory     bin_dir          /usr/bin
>    PEAR documentation directory   doc_dir          /usr/lib/php/doc
>    PHP extension directory        ext_dir
> /usr/lib/php/extensions/no-debug-non-zts-20090626
>    PEAR directory                 php_dir          /usr/lib/php
>    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>    PEAR data directory            data_dir         /usr/lib/php/data
>    PEAR Installer download        download_dir     /var/tmp/pear/download
>    PHP CLI/CGI binary             php_bin          /usr/bin/php
>    php.ini location               php_ini          <not set>
>    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>    PEAR test directory            test_dir         /usr/lib/php/test
>    PEAR www files directory       www_dir          /usr/lib/php/htdocs
>
> While some of this doesn't apply to Zend Framework, it does enforce a top
> level that encourages each directory to have a specific purpose, and a
> component/package will be disassembled and put into its proper place
> according to the system.
>
> The alternative to this is to keep resources within the components directory
> itself.  Here is my for instance I'd like you to think of:
>
>  Zend\Tool will be able to ship multiple project profiles out
>  the box in ZF2.  These might be xml, yaml, or even json
>  profiles.  Where do they go?  Where does a developer expect
>  to add his to the installation?
>
> If they exist inside the library folder, they are hidden, and the developer
> might be encouraged to patch his library.  If they are located outside the
> library, the library code needs to know where to look for its default
> resources.
>
> Once we understand how our distribution looks on disk, then I think we can
> talk about "packaging".
>
> -ralph
>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


bgy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

bgy
Le 01/04/11 19:40, Dolf Schimmel a écrit :
> I think it would indeed be good to suggest that files in library/ not
> be edited for production purposes (anything but debugging). That eases
> upgrading (also when it comes to packaging), is the only reasonable
> way to provide any way of support, and may protect novice users
> against themselves.
So true.

>
> My proposal would be to store the resource files relative to the
> components, so resource files for Zend\Db be stored in e.g.
> library/Zend/Db/_resources/ . Then, if someone wanted to use a
> different translation for one line (translation files = resources),
> he/she should not alter the files in question. In fact, imho it should
> be specified where alternative resource files can be found (be it
> through Service Locator, be it through an options array to the
> constructor), and then fall back to ZF's own resource files if a
> string isn't found in the user's own resource files.
I pretty agree this approach, I think as the current structure suggests
it, we could use a common local/ folder to put any custom resources,
override, etc.
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY)

Magento uses such structure, and with some improvements it can really be
straightforward.
>
> This in part discusses behavior too, but I think we cannot see
> behavior and directory structure entirely separately.

I must agree, especially when you're new to a project, you often start
by looking at the filestructure and have an idea on how the application
works before to review any codes.


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Marc Bennewitz (private)
In reply to this post by Dolf Schimmel

> My proposal would be to store the resource files relative to the
> components, so resource files for Zend\Db be stored in e.g.
> library/Zend/Db/_resources/ . Then, if someone wanted to use a
> different translation for one line (translation files = resources),
> he/she should not alter the files in question. In fact, imho it should
> be specified where alternative resource files can be found (be it
> through Service Locator, be it through an options array to the
> constructor), and then fall back to ZF's own resource files if a
> string isn't found in the user's own resource files.
I don't prefer to store such files relative the the component source
files it's self.
This would mean you ship all translation files of Zend\Validate into
library\Zend\Validate\_resources.
and if you need to change only one line the translator have to load two
resource files and need to perform a fall-back in 99% of calls.

The next tones of files are cldr files now located @ resources/cldr
which can eventually used by other components else Zend\Locale.
(On your proposal it should be located on
library/Zend/Locale/Data/_resources/cldr)

I don't see any need to change the content structure of the current
resource folder. For a PEAR structure it would simply the "data_dir"
eventually with an specified subdirectory line "/usr/lib/php/data/zend"

But next to this, I have a simple binary to get system memory status on
windows systems. Where should this be located ?
(https://github.com/marc-mabe/zf2/tree/cache/library/Zend/Cache/_win)

Greetings
Marc

> On Fri, Apr 1, 2011 at 6:08 PM, Ralph Schindler
> <[hidden email]> wrote:
>> This is not about what an application looks like, has nothing to do with
>> models, views, controllers, or any other application structure and resource
>> placement.  This is simply about the "Zend Framework distribution".  In
>> fact, this is not even about our build and packaging.
>>
>> The questions are fairly simple: where do things go?  Currently, our
>> directory structure looks like this:
>>
>> ZendFramework/
>>    bin/
>>    documentation/
>>    externals/
>>    library/
>>    resources/
>>    tests/
>>
>> There are a couple of other things in there, but you get the picture.
>> Traditionally, the library directory is suppose to be for php class files
>> only. The idea here is they can be found with an
>> autoloader/require_once/whatever and loaded based off some name.  This
>> directory should not be patched in any way shape or form, and there should
>> be no expectation to add/alter/remove anything within it to have working
>> components.
>>
>> More often than not, library components require non-php-class resources, and
>> the question is begged: where should these be located?
>>
>> By putting them inside the library, they are relative to the code that is
>> requiring them.  Being relative, they can be found and loaded quite easily.
>>  But, with them in this location, developers might be inclined to alter them
>> in the library folder, thus violating the "don't touch this" rule from
>> above.
>>
>> Putting them in the resources folder adds some clarity to their role that
>> they are non-php-classes, but detaches them from code requiring them.  By
>> doing this, the code now has to understand the "installation" of the
>> component/library.  In this case, it would be necessary for our library code
>> to perhaps have some kind of constant to track where resources are, for
>> example ZEND_RESOURCE_PATH, or something similar.
>>
>> This idea is further enforced by the structure of the PEAR system.  PEAR
>> allows for placement of package assets (for example):
>>
>>    PEAR executables directory     bin_dir          /usr/bin
>>    PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>    PHP extension directory        ext_dir
>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>    PEAR directory                 php_dir          /usr/lib/php
>>    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>    PEAR data directory            data_dir         /usr/lib/php/data
>>    PEAR Installer download        download_dir     /var/tmp/pear/download
>>    PHP CLI/CGI binary             php_bin          /usr/bin/php
>>    php.ini location               php_ini          <not set>
>>    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>    PEAR test directory            test_dir         /usr/lib/php/test
>>    PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>
>> While some of this doesn't apply to Zend Framework, it does enforce a top
>> level that encourages each directory to have a specific purpose, and a
>> component/package will be disassembled and put into its proper place
>> according to the system.
>>
>> The alternative to this is to keep resources within the components directory
>> itself.  Here is my for instance I'd like you to think of:
>>
>>  Zend\Tool will be able to ship multiple project profiles out
>>  the box in ZF2.  These might be xml, yaml, or even json
>>  profiles.  Where do they go?  Where does a developer expect
>>  to add his to the installation?
>>
>> If they exist inside the library folder, they are hidden, and the developer
>> might be encouraged to patch his library.  If they are located outside the
>> library, the library code needs to know where to look for its default
>> resources.
>>
>> Once we understand how our distribution looks on disk, then I think we can
>> talk about "packaging".
>>
>> -ralph
>>
>>
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

ThaDafinser
I prefer to store it within the component.

The advantage:
* everything related to one component is in ONE folder and not in the whole
framework (so understanding the code is easier)
* you can just copy one component folder and it's ready to use (when not
using the complete framework)
* ressources should be component related and not used by two or more
components (f.x. default translations), so that single components can be
used
* if a component falls out of the framework or refactoring have to be done,
another component can't get touched / broken
* ....

2011/4/2 Marc Bennewitz <[hidden email]>

>
> > My proposal would be to store the resource files relative to the
> > components, so resource files for Zend\Db be stored in e.g.
> > library/Zend/Db/_resources/ . Then, if someone wanted to use a
> > different translation for one line (translation files = resources),
> > he/she should not alter the files in question. In fact, imho it should
> > be specified where alternative resource files can be found (be it
> > through Service Locator, be it through an options array to the
> > constructor), and then fall back to ZF's own resource files if a
> > string isn't found in the user's own resource files.
> I don't prefer to store such files relative the the component source
> files it's self.
> This would mean you ship all translation files of Zend\Validate into
> library\Zend\Validate\_resources.
> and if you need to change only one line the translator have to load two
> resource files and need to perform a fall-back in 99% of calls.
>
> The next tones of files are cldr files now located @ resources/cldr
> which can eventually used by other components else Zend\Locale.
> (On your proposal it should be located on
> library/Zend/Locale/Data/_resources/cldr)
>
> I don't see any need to change the content structure of the current
> resource folder. For a PEAR structure it would simply the "data_dir"
> eventually with an specified subdirectory line "/usr/lib/php/data/zend"
>
> But next to this, I have a simple binary to get system memory status on
> windows systems. Where should this be located ?
> (https://github.com/marc-mabe/zf2/tree/cache/library/Zend/Cache/_win)
>
> Greetings
> Marc
>
> > On Fri, Apr 1, 2011 at 6:08 PM, Ralph Schindler
> > <[hidden email]> wrote:
> >> This is not about what an application looks like, has nothing to do with
> >> models, views, controllers, or any other application structure and
> resource
> >> placement.  This is simply about the "Zend Framework distribution".  In
> >> fact, this is not even about our build and packaging.
> >>
> >> The questions are fairly simple: where do things go?  Currently, our
> >> directory structure looks like this:
> >>
> >> ZendFramework/
> >>    bin/
> >>    documentation/
> >>    externals/
> >>    library/
> >>    resources/
> >>    tests/
> >>
> >> There are a couple of other things in there, but you get the picture.
> >> Traditionally, the library directory is suppose to be for php class
> files
> >> only. The idea here is they can be found with an
> >> autoloader/require_once/whatever and loaded based off some name.  This
> >> directory should not be patched in any way shape or form, and there
> should
> >> be no expectation to add/alter/remove anything within it to have working
> >> components.
> >>
> >> More often than not, library components require non-php-class resources,
> and
> >> the question is begged: where should these be located?
> >>
> >> By putting them inside the library, they are relative to the code that
> is
> >> requiring them.  Being relative, they can be found and loaded quite
> easily.
> >>  But, with them in this location, developers might be inclined to alter
> them
> >> in the library folder, thus violating the "don't touch this" rule from
> >> above.
> >>
> >> Putting them in the resources folder adds some clarity to their role
> that
> >> they are non-php-classes, but detaches them from code requiring them.
>  By
> >> doing this, the code now has to understand the "installation" of the
> >> component/library.  In this case, it would be necessary for our library
> code
> >> to perhaps have some kind of constant to track where resources are, for
> >> example ZEND_RESOURCE_PATH, or something similar.
> >>
> >> This idea is further enforced by the structure of the PEAR system.  PEAR
> >> allows for placement of package assets (for example):
> >>
> >>    PEAR executables directory     bin_dir          /usr/bin
> >>    PEAR documentation directory   doc_dir          /usr/lib/php/doc
> >>    PHP extension directory        ext_dir
> >> /usr/lib/php/extensions/no-debug-non-zts-20090626
> >>    PEAR directory                 php_dir          /usr/lib/php
> >>    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
> >>    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
> >>    PEAR data directory            data_dir         /usr/lib/php/data
> >>    PEAR Installer download        download_dir
> /var/tmp/pear/download
> >>    PHP CLI/CGI binary             php_bin          /usr/bin/php
> >>    php.ini location               php_ini          <not set>
> >>    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
> >>    PEAR test directory            test_dir         /usr/lib/php/test
> >>    PEAR www files directory       www_dir          /usr/lib/php/htdocs
> >>
> >> While some of this doesn't apply to Zend Framework, it does enforce a
> top
> >> level that encourages each directory to have a specific purpose, and a
> >> component/package will be disassembled and put into its proper place
> >> according to the system.
> >>
> >> The alternative to this is to keep resources within the components
> directory
> >> itself.  Here is my for instance I'd like you to think of:
> >>
> >>  Zend\Tool will be able to ship multiple project profiles out
> >>  the box in ZF2.  These might be xml, yaml, or even json
> >>  profiles.  Where do they go?  Where does a developer expect
> >>  to add his to the installation?
> >>
> >> If they exist inside the library folder, they are hidden, and the
> developer
> >> might be encouraged to patch his library.  If they are located outside
> the
> >> library, the library code needs to know where to look for its default
> >> resources.
> >>
> >> Once we understand how our distribution looks on disk, then I think we
> can
> >> talk about "packaging".
> >>
> >> -ralph
> >>
> >>
> >>
> >> --
> >> List: [hidden email]
> >> Info: http://framework.zend.com/archives
> >> Unsubscribe: [hidden email]
> >>
> >>
> >>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Marc Bennewitz (private)

On 03.04.2011 14:00, Martin Keckeis wrote:
> * ressources should be component related and not used by two or more
> components (f.x. default translations), so that single components can be
> used
Thats not practicable for resources like cldr because it's a standard
repository and could theoretically used by more components as
Zend\Locale (e.g Translator, Currency, Date ...).
And of curse your application can use it out of the box of ZF or already
using it.


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Dolf Schimmel
> On 03.04.2011 14:00, Martin Keckeis wrote:
>> * ressources should be component related and not used by two or more
>> components (f.x. default translations), so that single components can be
>> used
> Thats not practicable for resources like cldr because it's a standard
> repository and could theoretically used by more components as
> Zend\Locale (e.g Translator, Currency, Date ...).
> And of curse your application can use it out of the box of ZF or already
> using it.

Yet, Currency, Date, etc are all dependent on \Locale. We've been
doing it like this from at least 0.9, and I've never seen an issue
coming around that it would be a problem.

Dolf
-- Freeaqingme

>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Marc Bennewitz (private)

On 03.04.2011 18:40, Dolf Schimmel wrote:

>> On 03.04.2011 14:00, Martin Keckeis wrote:
>>> * ressources should be component related and not used by two or more
>>> components (f.x. default translations), so that single components can be
>>> used
>> Thats not practicable for resources like cldr because it's a standard
>> repository and could theoretically used by more components as
>> Zend\Locale (e.g Translator, Currency, Date ...).
>> And of curse your application can use it out of the box of ZF or already
>> using it.
> Yet, Currency, Date, etc are all dependent on \Locale. We've been
> doing it like this from at least 0.9, and I've never seen an issue
> coming around that it would be a problem.
Thats not a problem for ZF1. But with ZF2 there are some structural changes:
1. The locale cldr data will be optional because of buid-in intl of php.
2. On shipping ZF2 splitting into components it COULD be interesting to
remove component requirements

What I mean is that they are additional RESOURCES and not part of the
library it self.
For standard resources like cldr it COULD be used by other components
AND other applications out of ZF and it's not practicable if all will
ship the same data.
For translation files, not all languages are needed by the user and if
you would like to change only some lines it an overhead to load the own
translations AND the default with a fall-back.
(On most other applications the language files are not part of the
library it self, too)
Another resource is Dojo (or jQuery). There you CAN'T use it within the
library, too.
-> We don't know which types of resources could be added in the feature ;)

In my opinion the library folder should only contain php class files and
files REQUIRED by the library but these SHOULD be disused individual.

Greetings
Marc

> Dolf
> -- Freeaqingme
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Dolf Schimmel
Hey Marc,

> Thats not a problem for ZF1. But with ZF2 there are some structural changes:
> 1. The locale cldr data will be optional because of buid-in intl of php.
> 2. On shipping ZF2 splitting into components it COULD be interesting to
> remove component requirements

1. I haven't seen any proposal regarding Zend\Date for zf2, so I
wouldn't know about it becoming optional.

> What I mean is that they are additional RESOURCES and not part of the
> library it self.
> For standard resources like cldr it COULD be used by other components
> AND other applications out of ZF and it's not practicable if all will
> ship the same data.
> For translation files, not all languages are needed by the user and if
> you would like to change only some lines it an overhead to load the own
> translations AND the default with a fall-back.
> (On most other applications the language files are not part of the
> library it self, too)
> Another resource is Dojo (or jQuery). There you CAN'T use it within the
> library, too.
> -> We don't know which types of resources could be added in the feature ;)
>
> In my opinion the library folder should only contain php class files and
> files REQUIRED by the library but these SHOULD be disused individual.

I think we should distinct three things here: The validation/error
messages (I'd call these resource files), the CLDR files, and Dojo.

Resource files:
The resource files are (or should be) specific to a component, so you
can alter a message for one component without affecting that of
another component. These resource files (e.g. translation/error
messages) are already php, so could by your reasoning be in the
library/ dir. Which I think should, as reasoned in my previous emails.

I think we shouldn't mind the fact that there are multiple languages.
After all, they do not affect performance as long as they're not
loaded, and usually only language is used per request (or project).

Also, when it comes to packaging, you'll usually have multiple
projects running off the same resource files. So that's an additional
why they shouldn't be edited and are fine in library/. The performance
when using fallback files is no issue either. You could load a
fallback file only if a string were to be missing.

Dojo & CLDR:
I don't care where we put them. For dojo it makes sense to be put
outside library/, for cldr files: I dont know what would be wise.

Dolf
-- Freeaqingme

>
> Greetings
> Marc
>
>> Dolf
>> -- Freeaqingme
>>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Marc Bennewitz (private)
sorry for this

I hoped to make thinks more clear what I mean because english isn't my
preferred language.
please ignore it.

On 03.04.2011 21:24, Dolf Schimmel wrote:

> Hey Marc,
>
>> Thats not a problem for ZF1. But with ZF2 there are some structural changes:
>> 1. The locale cldr data will be optional because of buid-in intl of php.
>> 2. On shipping ZF2 splitting into components it COULD be interesting to
>> remove component requirements
> 1. I haven't seen any proposal regarding Zend\Date for zf2, so I
> wouldn't know about it becoming optional.
>
>> What I mean is that they are additional RESOURCES and not part of the
>> library it self.
>> For standard resources like cldr it COULD be used by other components
>> AND other applications out of ZF and it's not practicable if all will
>> ship the same data.
>> For translation files, not all languages are needed by the user and if
>> you would like to change only some lines it an overhead to load the own
>> translations AND the default with a fall-back.
>> (On most other applications the language files are not part of the
>> library it self, too)
>> Another resource is Dojo (or jQuery). There you CAN'T use it within the
>> library, too.
>> -> We don't know which types of resources could be added in the feature ;)
>>
>> In my opinion the library folder should only contain php class files and
>> files REQUIRED by the library but these SHOULD be disused individual.
> I think we should distinct three things here: The validation/error
> messages (I'd call these resource files), the CLDR files, and Dojo.
>
> Resource files:
> The resource files are (or should be) specific to a component, so you
> can alter a message for one component without affecting that of
> another component. These resource files (e.g. translation/error
> messages) are already php, so could by your reasoning be in the
> library/ dir. Which I think should, as reasoned in my previous emails.
>
> I think we shouldn't mind the fact that there are multiple languages.
> After all, they do not affect performance as long as they're not
> loaded, and usually only language is used per request (or project).
>
> Also, when it comes to packaging, you'll usually have multiple
> projects running off the same resource files. So that's an additional
> why they shouldn't be edited and are fine in library/. The performance
> when using fallback files is no issue either. You could load a
> fallback file only if a string were to be missing.
>
> Dojo & CLDR:
> I don't care where we put them. For dojo it makes sense to be put
> outside library/, for cldr files: I dont know what would be wise.
>
> Dolf
> -- Freeaqingme
>
>> Greetings
>> Marc
>>
>>> Dolf
>>> -- Freeaqingme
>>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Marc Bennewitz (private)
In reply to this post by Dolf Schimmel
Hi Dolf,
>> Thats not a problem for ZF1. But with ZF2 there are some structural changes:
>> 1. The locale cldr data will be optional because of buid-in intl of php.
>> 2. On shipping ZF2 splitting into components it COULD be interesting to
>> remove component requirements
> 1. I haven't seen any proposal regarding Zend\Date for zf2, so I
> wouldn't know about it becoming optional.
I didn't read about it, too. But if I look @
https://github.com/zendframework/zf2/tree/master/library/Zend/Locale/Data it
looks like that ;)

>> What I mean is that they are additional RESOURCES and not part of the
>> library it self.
>> For standard resources like cldr it COULD be used by other components
>> AND other applications out of ZF and it's not practicable if all will
>> ship the same data.
>> For translation files, not all languages are needed by the user and if
>> you would like to change only some lines it an overhead to load the own
>> translations AND the default with a fall-back.
>> (On most other applications the language files are not part of the
>> library it self, too)
>> Another resource is Dojo (or jQuery). There you CAN'T use it within the
>> library, too.
>> -> We don't know which types of resources could be added in the feature ;)
>>
>> In my opinion the library folder should only contain php class files and
>> files REQUIRED by the library but these SHOULD be disused individual.
> I think we should distinct three things here: The validation/error
> messages (I'd call these resource files), the CLDR files, and Dojo.
Good to know.
What would be your definition of resource files if we only talk over
translation files.

> Resource files:
> The resource files are (or should be) specific to a component, so you
> can alter a message for one component without affecting that of
> another component. These resource files (e.g. translation/error
> messages) are already php, so could by your reasoning be in the
> library/ dir. Which I think should, as reasoned in my previous emails.
>
> I think we shouldn't mind the fact that there are multiple languages.
> After all, they do not affect performance as long as they're not
> loaded, and usually only language is used per request (or project).
>
> Also, when it comes to packaging, you'll usually have multiple
> projects running off the same resource files. So that's an additional
> why they shouldn't be edited and are fine in library/. The performance
> when using fallback files is no issue either. You could load a
> fallback file only if a string were to be missing.
For me translation files are part of the application and should be
shipped with but they are not part of the library because they are not
required by the component and the only component using it is the translator.
Ok the translator will be called by another component but it defines a
directory structure and you pre-defines a translator adapter to be used.
On moving it outside of the library it's more simple to move it into
your own application structure. I think thats one advantage of ZF to
don't pre-define the users application structure only to write
recommendations.

I don't know about the translation files shouldn't be edited. Also if
there are more than one projects are running on. For me ever changed the
the translation files if I need another translation than it's simpler to
handle updates because on chowing the difference you will see if the
changed line was changed in ZF and I need to update the translation key.

I would like to handle it that the user can select what he need and
don't get unneeded thinks. If he need an addition he can simply add this
addition or download a full package.

> Dojo & CLDR:
> I don't care where we put them. For dojo it makes sense to be put
> outside library/, for cldr files: I dont know what would be wise.
This is the same. Packing into an own folder and let the user say what
he need.



> Dolf
> -- Freeaqingme
>
>> Greetings
>> Marc
>>
>>> Dolf
>>> -- Freeaqingme
>>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Mike Willbanks
In reply to this post by Ralph Schindler-2
> The questions are fairly simple: where do things go?  Currently, our
> directory structure looks like this:
>
> ZendFramework/
>    bin/
>    documentation/
>    externals/
>    library/
>    resources/
>    tests/
>
> There are a couple of other things in there, but you get the picture.
> Traditionally, the library directory is suppose to be for php class files
> only. The idea here is they can be found with an
> autoloader/require_once/whatever and loaded based off some name.  This
> directory should not be patched in any way shape or form, and there should
> be no expectation to add/alter/remove anything within it to have working
> components.

First things first, since I get highly opinionated :)  I believe the
standard distribution should now be through PEAR.  The library folder
is really aggravating when I find that people took a ZF snapshot or
specific version and bundled it.  Subsequently, we really need to
attempt to keep the include path as small as possible to keep
performance losses limited due to lstat and stat calls.  This is
frequently an issue in larger installations and something that I have
personally been working on limiting down in our current ZF 1.x
application.

> This idea is further enforced by the structure of the PEAR system.  PEAR
> allows for placement of package assets (for example):
>
>    PEAR executables directory     bin_dir          /usr/bin
>    PEAR documentation directory   doc_dir          /usr/lib/php/doc
>    PHP extension directory        ext_dir
> /usr/lib/php/extensions/no-debug-non-zts-20090626
>    PEAR directory                 php_dir          /usr/lib/php
>    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>    PEAR data directory            data_dir         /usr/lib/php/data
>    PEAR Installer download        download_dir     /var/tmp/pear/download
>    PHP CLI/CGI binary             php_bin          /usr/bin/php
>    php.ini location               php_ini          <not set>
>    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>    PEAR test directory            test_dir         /usr/lib/php/test
>    PEAR www files directory       www_dir          /usr/lib/php/htdocs

We should certainly work towards a packaging system for library style
components.  However, I do feel that if we made the standard
distribution a PEAR installation; it would subsequently help us to
highly recommend the PEAR packaging system through using something
like Pirum and then packaging their own library components to be
utilized through the PEAR packaging system.  Why build something
specifically for ZF that already exists?

> While some of this doesn't apply to Zend Framework, it does enforce a top
> level that encourages each directory to have a specific purpose, and a
> component/package will be disassembled and put into its proper place
> according to the system.

Many of these things do apply to ZF specifically as well as the
extending and embedding of ZF.  The only reason we ever use the
library folder is in the event of a needed patch for a ZF component
that we are unable to overwrite utilizing our own classes.  However,
we have started to move away from that completely taking the standard
ZF PEAR package, applying patches and repackaging to a local PEAR
repository which also houses our extensions on the top of ZF.

> The alternative to this is to keep resources within the components directory
> itself.  Here is my for instance I'd like you to think of:
>
>  Zend\Tool will be able to ship multiple project profiles out
>  the box in ZF2.  These might be xml, yaml, or even json
>  profiles.  Where do they go?  Where does a developer expect
>  to add his to the installation?

These go in the standard PEAR installation area.  We really should
start thinking about leveraging the community wide features and
recommendations for installation.  This also aides shared hosting
providers to install packages far easier.  A user could then override
it by installing it locally and thus would need to tell their systems
the include paths.  Now when we are talking about configuration of a
project specifically, why not just store it in the application/configs
area?

I just really believe it would be inconsiderate as well as
non-productive to make this a ZF specific item.  PEAR for distribution
has been becoming far more popular as well as more scalable and I
believe strongly that it would be a mistake to not make it the
standard distribution.

Now when we get more into where application resources go I believe
this discussion to be far more complex such as where configuration
goes, modules, models, data, etc.

Regards,

Mike

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

weierophinney
Administrator
-- Mike Willbanks <[hidden email]> wrote
(on Monday, 04 April 2011, 01:38 PM -0500):

> > The questions are fairly simple: where do things go?  Currently, our
> > directory structure looks like this:
> >
> > ZendFramework/
> >    bin/
> >    documentation/
> >    externals/
> >    library/
> >    resources/
> >    tests/
> >
> > There are a couple of other things in there, but you get the picture.
> > Traditionally, the library directory is suppose to be for php class files
> > only. The idea here is they can be found with an
> > autoloader/require_once/whatever and loaded based off some name.  This
> > directory should not be patched in any way shape or form, and there should
> > be no expectation to add/alter/remove anything within it to have working
> > components.
>
> First things first, since I get highly opinionated :)  I believe the
> standard distribution should now be through PEAR.  The library folder
> is really aggravating when I find that people took a ZF snapshot or
> specific version and bundled it.  Subsequently, we really need to
> attempt to keep the include path as small as possible to keep
> performance losses limited due to lstat and stat calls.  This is
> frequently an issue in larger installations and something that I have
> personally been working on limiting down in our current ZF 1.x
> application.

I'm going to jump in here, and note that ZF2 is going to be less
dependent on the include_path, to the point of being independent
whenever possible. The whole point of the autoloader research and work I
did last fall was due to profiling applications and determining
bottlenecks -- and the first and worst was relying on the include_path.

So, while I understand keeping the include_path as small as possible,
my point is that it shouldn't be an issue in ZF2 applications unless
you're being lazy and using a fallback autoloader that utilizes it.

> > This idea is further enforced by the structure of the PEAR system.  PEAR
> > allows for placement of package assets (for example):
> >
> >    PEAR executables directory     bin_dir          /usr/bin
> >    PEAR documentation directory   doc_dir          /usr/lib/php/doc
> >    PHP extension directory        ext_dir
> > /usr/lib/php/extensions/no-debug-non-zts-20090626
> >    PEAR directory                 php_dir          /usr/lib/php
> >    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
> >    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
> >    PEAR data directory            data_dir         /usr/lib/php/data
> >    PEAR Installer download        download_dir     /var/tmp/pear/download
> >    PHP CLI/CGI binary             php_bin          /usr/bin/php
> >    php.ini location               php_ini          <not set>
> >    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
> >    PEAR test directory            test_dir         /usr/lib/php/test
> >    PEAR www files directory       www_dir          /usr/lib/php/htdocs
>
> We should certainly work towards a packaging system for library style
> components.  However, I do feel that if we made the standard
> distribution a PEAR installation; it would subsequently help us to
> highly recommend the PEAR packaging system through using something
> like Pirum and then packaging their own library components to be
> utilized through the PEAR packaging system.  Why build something
> specifically for ZF that already exists?

We're planning on utilizing PEAR infrastructure. The question that Ralph
is raising is: where do we put "resource" files, such as CodeGenerator
templates, locale files, etc?

It's actually non-obvious when you look at the PEAR package assets
structure: would these be considered data? www files? configuration
(probably not, as the cfg_dir is usually reserved for PEAR and/or
executables)? I can actually see an argument for categorizing it as part
php_dir, simply because otherwise we need to worry about whether or not
the user has customized their PEAR environment (i.e., specified
locations other than the defaults for configuration).

> > While some of this doesn't apply to Zend Framework, it does enforce a top
> > level that encourages each directory to have a specific purpose, and a
> > component/package will be disassembled and put into its proper place
> > according to the system.
>
> Many of these things do apply to ZF specifically as well as the
> extending and embedding of ZF.  The only reason we ever use the
> library folder is in the event of a needed patch for a ZF component
> that we are unable to overwrite utilizing our own classes.  However,
> we have started to move away from that completely taking the standard
> ZF PEAR package, applying patches and repackaging to a local PEAR
> repository which also houses our extensions on the top of ZF.
>
> > The alternative to this is to keep resources within the components directory
> > itself.  Here is my for instance I'd like you to think of:
> >
> >  Zend\Tool will be able to ship multiple project profiles out
> >  the box in ZF2.  These might be xml, yaml, or even json
> >  profiles.  Where do they go?  Where does a developer expect
> >  to add his to the installation?
>
> These go in the standard PEAR installation area.  We really should
> start thinking about leveraging the community wide features and
> recommendations for installation.  This also aides shared hosting
> providers to install packages far easier.  A user could then override
> it by installing it locally and thus would need to tell their systems
> the include paths.  Now when we are talking about configuration of a
> project specifically, why not just store it in the application/configs
> area?
>
> I just really believe it would be inconsiderate as well as
> non-productive to make this a ZF specific item.  PEAR for distribution
> has been becoming far more popular as well as more scalable and I
> believe strongly that it would be a mistake to not make it the
> standard distribution.

Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
Ralph's post is to try and determine where certain assets should be
placed when packaging. As such, you've answered that question to a
degree: you appear to be arguing that they should be in the PEAR dir
(php_dir in the above), and that developers would override this through
application configuration.

Does that sound about right?

> Now when we get more into where application resources go I believe
> this discussion to be far more complex such as where configuration
> goes, modules, models, data, etc.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Mike Willbanks
Matthew,

Sorry it has taken me a while to respond to this.  It has been some crazy
last few weeks.


> (on Monday, 04 April 2011, 01:38 PM -0500):
> > > The questions are fairly simple: where do things go?  Currently, our
> > > directory structure looks like this:
> > >
> > > ZendFramework/
> > >    bin/
> > >    documentation/
> > >    externals/
> > >    library/
> > >    resources/
> > >    tests/
> > >
> > > There are a couple of other things in there, but you get the picture.
> > > Traditionally, the library directory is suppose to be for php class
> files
> > > only. The idea here is they can be found with an
> > > autoloader/require_once/whatever and loaded based off some name.  This
> > > directory should not be patched in any way shape or form, and there
> should
> > > be no expectation to add/alter/remove anything within it to have
> working
> > > components.
> >
> > First things first, since I get highly opinionated :)  I believe the
> > standard distribution should now be through PEAR.  The library folder
> > is really aggravating when I find that people took a ZF snapshot or
> > specific version and bundled it.  Subsequently, we really need to
> > attempt to keep the include path as small as possible to keep
> > performance losses limited due to lstat and stat calls.  This is
> > frequently an issue in larger installations and something that I have
> > personally been working on limiting down in our current ZF 1.x
> > application.
>
> I'm going to jump in here, and note that ZF2 is going to be less
> dependent on the include_path, to the point of being independent
> whenever possible. The whole point of the autoloader research and work I
> did last fall was due to profiling applications and determining
> bottlenecks -- and the first and worst was relying on the include_path.
>
> So, while I understand keeping the include_path as small as possible,
> my point is that it shouldn't be an issue in ZF2 applications unless
> you're being lazy and using a fallback autoloader that utilizes it.
>
>
It will still need to be utilized in a limited capacity which was the reason
for my comment, I realize that we have the new class map autoloading as well
and that should solve a lot of it.


> > > This idea is further enforced by the structure of the PEAR system.
>  PEAR
> > > allows for placement of package assets (for example):
> > >
> > >    PEAR executables directory     bin_dir          /usr/bin
> > >    PEAR documentation directory   doc_dir          /usr/lib/php/doc
> > >    PHP extension directory        ext_dir
> > > /usr/lib/php/extensions/no-debug-non-zts-20090626
> > >    PEAR directory                 php_dir          /usr/lib/php
> > >    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
> > >    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
> > >    PEAR data directory            data_dir         /usr/lib/php/data
> > >    PEAR Installer download        download_dir
> /var/tmp/pear/download
> > >    PHP CLI/CGI binary             php_bin          /usr/bin/php
> > >    php.ini location               php_ini          <not set>
> > >    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
> > >    PEAR test directory            test_dir         /usr/lib/php/test
> > >    PEAR www files directory       www_dir          /usr/lib/php/htdocs
> >
> > We should certainly work towards a packaging system for library style
> > components.  However, I do feel that if we made the standard
> > distribution a PEAR installation; it would subsequently help us to
> > highly recommend the PEAR packaging system through using something
> > like Pirum and then packaging their own library components to be
> > utilized through the PEAR packaging system.  Why build something
> > specifically for ZF that already exists?
>
> We're planning on utilizing PEAR infrastructure. The question that Ralph
> is raising is: where do we put "resource" files, such as CodeGenerator
> templates, locale files, etc?
>

These are generally always application specific.  In the case that there are
specific ones for ZF that are shared, I would argue that the data directory
would be made for this sort of thing.  Think of the apc.php file that is
generally located in the data dir.  This is also where most projects put SQL
creation files, templates and additional items.  The only thing to think
about is how to override this configuration area and provide a secondary
area in the application itself.


>
> It's actually non-obvious when you look at the PEAR package assets
> structure: would these be considered data? www files? configuration
> (probably not, as the cfg_dir is usually reserved for PEAR and/or
> executables)? I can actually see an argument for categorizing it as part
> php_dir, simply because otherwise we need to worry about whether or not
> the user has customized their PEAR environment (i.e., specified
> locations other than the defaults for configuration).


IMO www files should always be in the application configuration area.  More
often than not you need those locally inside of the folder, otherwise if you
were to organize them into the php_dir data area that pear has a simple
include would handle much of the work for us.  You should not need to worry
about a customized PEAR environment simply due to the variables that exist
to state where things live aka: pear config-show will give you the locations
that you need as well as pear config-get to locate the environment locations
for PEAR directories.



> > > While some of this doesn't apply to Zend Framework, it does enforce a
> top
> > > level that encourages each directory to have a specific purpose, and a
> > > component/package will be disassembled and put into its proper place
> > > according to the system.
> >
> > Many of these things do apply to ZF specifically as well as the
> > extending and embedding of ZF.  The only reason we ever use the
> > library folder is in the event of a needed patch for a ZF component
> > that we are unable to overwrite utilizing our own classes.  However,
> > we have started to move away from that completely taking the standard
> > ZF PEAR package, applying patches and repackaging to a local PEAR
> > repository which also houses our extensions on the top of ZF.
> >
> > > The alternative to this is to keep resources within the components
> directory
> > > itself.  Here is my for instance I'd like you to think of:
> > >
> > >  Zend\Tool will be able to ship multiple project profiles out
> > >  the box in ZF2.  These might be xml, yaml, or even json
> > >  profiles.  Where do they go?  Where does a developer expect
> > >  to add his to the installation?
> >
> > These go in the standard PEAR installation area.  We really should
> > start thinking about leveraging the community wide features and
> > recommendations for installation.  This also aides shared hosting
> > providers to install packages far easier.  A user could then override
> > it by installing it locally and thus would need to tell their systems
> > the include paths.  Now when we are talking about configuration of a
> > project specifically, why not just store it in the application/configs
> > area?
> >
> > I just really believe it would be inconsiderate as well as
> > non-productive to make this a ZF specific item.  PEAR for distribution
> > has been becoming far more popular as well as more scalable and I
> > believe strongly that it would be a mistake to not make it the
> > standard distribution.
>
> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
> Ralph's post is to try and determine where certain assets should be
> placed when packaging. As such, you've answered that question to a
> degree: you appear to be arguing that they should be in the PEAR dir
> (php_dir in the above), and that developers would override this through
> application configuration.
>
> Does that sound about right?
>

That is pretty much exactly what I am stating :)  Also there is the data
directory that is inside of the PEAR configuration that can be used for
common items as I stated above.  Application configuration allows us to
provide the flexibility of being able to override the individual assets
where needed having the fallback to the data folder.

Regards,

Mike
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

padraicb
Hi all,

Since I haven't really chimed in on the resource location topic…

The question of where to locate resources needs to be determined on the basis of
what fits the surrounding code and not what best fits whichever packaging
standard is being utilised. PEAR is, putting it bluntly, an incoherent set of
standards based on what was perceived to be best practice in the 90s.
Predictably, a considerable number of people don't bother using it except to
install PHPUnit. So let's not let it determine the solution.

The best solution, to my mind, is the simplest one. PHP 5.3 has a constant,
__DIR__, accessible from any file. This gives us a fast, clear and obvious
location for any class. Putting resources/files into any directory relative to
that value ensures it can be accessed with a minimum of fuss. If folk need to
define alternate paths, well, there's nothing stopping us from adding a check
for that.

The alternative, using PEAR's data/resource directories has numerous problems.
It forces configuration onto users, adds uncertainty (local configuration of
PEAR), and allows the packaging system to dictate what should be an independent
decision.

The purpose of a package system should be to store a set of files to an isolated
part of the filesystem irrespective of what the internal file organisation might
be. This preserves the original code's internal organisation and assumptions,
allows simple running of unit tests, and viewing of documentation. PEAR's
envisaged system of meddling with the filesystem is just a mess designed to
impose misplaced standards. Docs are written (and overwritten), file name
conflicts abound, running unit tests is unheard of (unless they're PHPT).

It IS NOT our job as developers to meet the expectations of a package system. It
IS its job to meet our expectations so we're willing to adopt and use it. Let's
not get confused over who is in charge around here!

P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus is no
different.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Mike Willbanks <[hidden email]>
To: [hidden email]
Cc: Matthew Weier O'Phinney <[hidden email]>
Sent: Tue, April 12, 2011 3:42:45 PM
Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things Go?

Matthew,

Sorry it has taken me a while to respond to this.  It has been some crazy
last few weeks.


> (on Monday, 04 April 2011, 01:38 PM -0500):
> > > The questions are fairly simple: where do things go?  Currently, our
> > > directory structure looks like this:
> > >
> > > ZendFramework/
> > >    bin/
> > >    documentation/
> > >    externals/
> > >    library/
> > >    resources/
> > >    tests/
> > >
> > > There are a couple of other things in there, but you get the picture.
> > > Traditionally, the library directory is suppose to be for php class
> files
> > > only. The idea here is they can be found with an
> > > autoloader/require_once/whatever and loaded based off some name.  This
> > > directory should not be patched in any way shape or form, and there
> should
> > > be no expectation to add/alter/remove anything within it to have
> working
> > > components.
> >
> > First things first, since I get highly opinionated :)  I believe the
> > standard distribution should now be through PEAR.  The library folder
> > is really aggravating when I find that people took a ZF snapshot or
> > specific version and bundled it.  Subsequently, we really need to
> > attempt to keep the include path as small as possible to keep
> > performance losses limited due to lstat and stat calls.  This is
> > frequently an issue in larger installations and something that I have
> > personally been working on limiting down in our current ZF 1.x
> > application.
>
> I'm going to jump in here, and note that ZF2 is going to be less
> dependent on the include_path, to the point of being independent
> whenever possible. The whole point of the autoloader research and work I
> did last fall was due to profiling applications and determining
> bottlenecks -- and the first and worst was relying on the include_path.
>
> So, while I understand keeping the include_path as small as possible,
> my point is that it shouldn't be an issue in ZF2 applications unless
> you're being lazy and using a fallback autoloader that utilizes it.
>
>
It will still need to be utilized in a limited capacity which was the reason
for my comment, I realize that we have the new class map autoloading as well
and that should solve a lot of it.


> > > This idea is further enforced by the structure of the PEAR system.
>  PEAR
> > > allows for placement of package assets (for example):
> > >
> > >    PEAR executables directory     bin_dir          /usr/bin
> > >    PEAR documentation directory   doc_dir          /usr/lib/php/doc
> > >    PHP extension directory        ext_dir
> > > /usr/lib/php/extensions/no-debug-non-zts-20090626
> > >    PEAR directory                 php_dir          /usr/lib/php
> > >    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
> > >    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
> > >    PEAR data directory            data_dir         /usr/lib/php/data
> > >    PEAR Installer download        download_dir
> /var/tmp/pear/download
> > >    PHP CLI/CGI binary             php_bin          /usr/bin/php
> > >    php.ini location               php_ini          <not set>
> > >    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
> > >    PEAR test directory            test_dir         /usr/lib/php/test
> > >    PEAR www files directory       www_dir          /usr/lib/php/htdocs
> >
> > We should certainly work towards a packaging system for library style
> > components.  However, I do feel that if we made the standard
> > distribution a PEAR installation; it would subsequently help us to
> > highly recommend the PEAR packaging system through using something
> > like Pirum and then packaging their own library components to be
> > utilized through the PEAR packaging system.  Why build something
> > specifically for ZF that already exists?
>
> We're planning on utilizing PEAR infrastructure. The question that Ralph
> is raising is: where do we put "resource" files, such as CodeGenerator
> templates, locale files, etc?
>

These are generally always application specific.  In the case that there are
specific ones for ZF that are shared, I would argue that the data directory
would be made for this sort of thing.  Think of the apc.php file that is
generally located in the data dir.  This is also where most projects put SQL
creation files, templates and additional items.  The only thing to think
about is how to override this configuration area and provide a secondary
area in the application itself.


>
> It's actually non-obvious when you look at the PEAR package assets
> structure: would these be considered data? www files? configuration
> (probably not, as the cfg_dir is usually reserved for PEAR and/or
> executables)? I can actually see an argument for categorizing it as part
> php_dir, simply because otherwise we need to worry about whether or not
> the user has customized their PEAR environment (i.e., specified
> locations other than the defaults for configuration).


IMO www files should always be in the application configuration area.  More
often than not you need those locally inside of the folder, otherwise if you
were to organize them into the php_dir data area that pear has a simple
include would handle much of the work for us.  You should not need to worry
about a customized PEAR environment simply due to the variables that exist
to state where things live aka: pear config-show will give you the locations
that you need as well as pear config-get to locate the environment locations
for PEAR directories.



> > > While some of this doesn't apply to Zend Framework, it does enforce a
> top
> > > level that encourages each directory to have a specific purpose, and a
> > > component/package will be disassembled and put into its proper place
> > > according to the system.
> >
> > Many of these things do apply to ZF specifically as well as the
> > extending and embedding of ZF.  The only reason we ever use the
> > library folder is in the event of a needed patch for a ZF component
> > that we are unable to overwrite utilizing our own classes.  However,
> > we have started to move away from that completely taking the standard
> > ZF PEAR package, applying patches and repackaging to a local PEAR
> > repository which also houses our extensions on the top of ZF.
> >
> > > The alternative to this is to keep resources within the components
> directory
> > > itself.  Here is my for instance I'd like you to think of:
> > >
> > >  Zend\Tool will be able to ship multiple project profiles out
> > >  the box in ZF2.  These might be xml, yaml, or even json
> > >  profiles.  Where do they go?  Where does a developer expect
> > >  to add his to the installation?
> >
> > These go in the standard PEAR installation area.  We really should
> > start thinking about leveraging the community wide features and
> > recommendations for installation.  This also aides shared hosting
> > providers to install packages far easier.  A user could then override
> > it by installing it locally and thus would need to tell their systems
> > the include paths.  Now when we are talking about configuration of a
> > project specifically, why not just store it in the application/configs
> > area?
> >
> > I just really believe it would be inconsiderate as well as
> > non-productive to make this a ZF specific item.  PEAR for distribution
> > has been becoming far more popular as well as more scalable and I
> > believe strongly that it would be a mistake to not make it the
> > standard distribution.
>
> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
> Ralph's post is to try and determine where certain assets should be
> placed when packaging. As such, you've answered that question to a
> degree: you appear to be arguing that they should be in the PEAR dir
> (php_dir in the above), and that developers would override this through
> application configuration.
>
> Does that sound about right?
>

That is pretty much exactly what I am stating :)  Also there is the data
directory that is inside of the PEAR configuration that can be used for
common items as I stated above.  Application configuration allows us to
provide the flexibility of being able to override the individual assets
where needed having the fallback to the data folder.

Regards,

Mike
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Ralph Schindler-2
There were two thoughts that came to mind.

If we go with resources outside of the directory where the "library"
code is found, perhaps we have ZF specific constants to peer off of,
like ZEND_DATA_DIRECTORY, or something similar.  That way, by default,
they are relative to __DIR__, but can be moved and the developer can
simply change the constant.  Out of the box, like I said,
ZEND_DATA_DIRECTORY would be relative to __DIR__ so that components dont
require you to configure it if you just downloaded ZF and put it in you
/usr/share or something.

The other though:

Have you looked at the Assetic project?  It is something Matthew brought
to my attention, and it looks like a promising idea.  Basically, this
would encourage non-php files to be placed inside the libary by default,
and to override, you have to configure the component to look in a
different place.

Thoughts?
-ralph

On 5/27/11 5:11 AM, Pádraic Brady wrote:

> Hi all,
>
> Since I haven't really chimed in on the resource location topic…
>
> The question of where to locate resources needs to be determined on the basis of
> what fits the surrounding code and not what best fits whichever packaging
> standard is being utilised. PEAR is, putting it bluntly, an incoherent set of
> standards based on what was perceived to be best practice in the 90s.
> Predictably, a considerable number of people don't bother using it except to
> install PHPUnit. So let's not let it determine the solution.
>
> The best solution, to my mind, is the simplest one. PHP 5.3 has a constant,
> __DIR__, accessible from any file. This gives us a fast, clear and obvious
> location for any class. Putting resources/files into any directory relative to
> that value ensures it can be accessed with a minimum of fuss. If folk need to
> define alternate paths, well, there's nothing stopping us from adding a check
> for that.
>
> The alternative, using PEAR's data/resource directories has numerous problems.
> It forces configuration onto users, adds uncertainty (local configuration of
> PEAR), and allows the packaging system to dictate what should be an independent
> decision.
>
> The purpose of a package system should be to store a set of files to an isolated
> part of the filesystem irrespective of what the internal file organisation might
> be. This preserves the original code's internal organisation and assumptions,
> allows simple running of unit tests, and viewing of documentation. PEAR's
> envisaged system of meddling with the filesystem is just a mess designed to
> impose misplaced standards. Docs are written (and overwritten), file name
> conflicts abound, running unit tests is unheard of (unless they're PHPT).
>
> It IS NOT our job as developers to meet the expectations of a package system. It
> IS its job to meet our expectations so we're willing to adopt and use it. Let's
> not get confused over who is in charge around here!
>
> P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus is no
> different.
>
> Paddy
>
>   Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
>
>
> ________________________________
> From: Mike Willbanks<[hidden email]>
> To: [hidden email]
> Cc: Matthew Weier O'Phinney<[hidden email]>
> Sent: Tue, April 12, 2011 3:42:45 PM
> Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things Go?
>
> Matthew,
>
> Sorry it has taken me a while to respond to this.  It has been some crazy
> last few weeks.
>
>
>> (on Monday, 04 April 2011, 01:38 PM -0500):
>>>> The questions are fairly simple: where do things go?  Currently, our
>>>> directory structure looks like this:
>>>>
>>>> ZendFramework/
>>>>     bin/
>>>>     documentation/
>>>>     externals/
>>>>     library/
>>>>     resources/
>>>>     tests/
>>>>
>>>> There are a couple of other things in there, but you get the picture.
>>>> Traditionally, the library directory is suppose to be for php class
>> files
>>>> only. The idea here is they can be found with an
>>>> autoloader/require_once/whatever and loaded based off some name.  This
>>>> directory should not be patched in any way shape or form, and there
>> should
>>>> be no expectation to add/alter/remove anything within it to have
>> working
>>>> components.
>>>
>>> First things first, since I get highly opinionated :)  I believe the
>>> standard distribution should now be through PEAR.  The library folder
>>> is really aggravating when I find that people took a ZF snapshot or
>>> specific version and bundled it.  Subsequently, we really need to
>>> attempt to keep the include path as small as possible to keep
>>> performance losses limited due to lstat and stat calls.  This is
>>> frequently an issue in larger installations and something that I have
>>> personally been working on limiting down in our current ZF 1.x
>>> application.
>>
>> I'm going to jump in here, and note that ZF2 is going to be less
>> dependent on the include_path, to the point of being independent
>> whenever possible. The whole point of the autoloader research and work I
>> did last fall was due to profiling applications and determining
>> bottlenecks -- and the first and worst was relying on the include_path.
>>
>> So, while I understand keeping the include_path as small as possible,
>> my point is that it shouldn't be an issue in ZF2 applications unless
>> you're being lazy and using a fallback autoloader that utilizes it.
>>
>>
> It will still need to be utilized in a limited capacity which was the reason
> for my comment, I realize that we have the new class map autoloading as well
> and that should solve a lot of it.
>
>
>>>> This idea is further enforced by the structure of the PEAR system.
>>   PEAR
>>>> allows for placement of package assets (for example):
>>>>
>>>>     PEAR executables directory     bin_dir          /usr/bin
>>>>     PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>>>     PHP extension directory        ext_dir
>>>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>>>     PEAR directory                 php_dir          /usr/lib/php
>>>>     PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>>>     PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>>>     PEAR data directory            data_dir         /usr/lib/php/data
>>>>     PEAR Installer download        download_dir
>> /var/tmp/pear/download
>>>>     PHP CLI/CGI binary             php_bin          /usr/bin/php
>>>>     php.ini location               php_ini<not set>
>>>>     PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>>>     PEAR test directory            test_dir         /usr/lib/php/test
>>>>     PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>>
>>> We should certainly work towards a packaging system for library style
>>> components.  However, I do feel that if we made the standard
>>> distribution a PEAR installation; it would subsequently help us to
>>> highly recommend the PEAR packaging system through using something
>>> like Pirum and then packaging their own library components to be
>>> utilized through the PEAR packaging system.  Why build something
>>> specifically for ZF that already exists?
>>
>> We're planning on utilizing PEAR infrastructure. The question that Ralph
>> is raising is: where do we put "resource" files, such as CodeGenerator
>> templates, locale files, etc?
>>
>
> These are generally always application specific.  In the case that there are
> specific ones for ZF that are shared, I would argue that the data directory
> would be made for this sort of thing.  Think of the apc.php file that is
> generally located in the data dir.  This is also where most projects put SQL
> creation files, templates and additional items.  The only thing to think
> about is how to override this configuration area and provide a secondary
> area in the application itself.
>
>
>>
>> It's actually non-obvious when you look at the PEAR package assets
>> structure: would these be considered data? www files? configuration
>> (probably not, as the cfg_dir is usually reserved for PEAR and/or
>> executables)? I can actually see an argument for categorizing it as part
>> php_dir, simply because otherwise we need to worry about whether or not
>> the user has customized their PEAR environment (i.e., specified
>> locations other than the defaults for configuration).
>
>
> IMO www files should always be in the application configuration area.  More
> often than not you need those locally inside of the folder, otherwise if you
> were to organize them into the php_dir data area that pear has a simple
> include would handle much of the work for us.  You should not need to worry
> about a customized PEAR environment simply due to the variables that exist
> to state where things live aka: pear config-show will give you the locations
> that you need as well as pear config-get to locate the environment locations
> for PEAR directories.
>
>
>
>>>> While some of this doesn't apply to Zend Framework, it does enforce a
>> top
>>>> level that encourages each directory to have a specific purpose, and a
>>>> component/package will be disassembled and put into its proper place
>>>> according to the system.
>>>
>>> Many of these things do apply to ZF specifically as well as the
>>> extending and embedding of ZF.  The only reason we ever use the
>>> library folder is in the event of a needed patch for a ZF component
>>> that we are unable to overwrite utilizing our own classes.  However,
>>> we have started to move away from that completely taking the standard
>>> ZF PEAR package, applying patches and repackaging to a local PEAR
>>> repository which also houses our extensions on the top of ZF.
>>>
>>>> The alternative to this is to keep resources within the components
>> directory
>>>> itself.  Here is my for instance I'd like you to think of:
>>>>
>>>>   Zend\Tool will be able to ship multiple project profiles out
>>>>   the box in ZF2.  These might be xml, yaml, or even json
>>>>   profiles.  Where do they go?  Where does a developer expect
>>>>   to add his to the installation?
>>>
>>> These go in the standard PEAR installation area.  We really should
>>> start thinking about leveraging the community wide features and
>>> recommendations for installation.  This also aides shared hosting
>>> providers to install packages far easier.  A user could then override
>>> it by installing it locally and thus would need to tell their systems
>>> the include paths.  Now when we are talking about configuration of a
>>> project specifically, why not just store it in the application/configs
>>> area?
>>>
>>> I just really believe it would be inconsiderate as well as
>>> non-productive to make this a ZF specific item.  PEAR for distribution
>>> has been becoming far more popular as well as more scalable and I
>>> believe strongly that it would be a mistake to not make it the
>>> standard distribution.
>>
>> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
>> Ralph's post is to try and determine where certain assets should be
>> placed when packaging. As such, you've answered that question to a
>> degree: you appear to be arguing that they should be in the PEAR dir
>> (php_dir in the above), and that developers would override this through
>> application configuration.
>>
>> Does that sound about right?
>>
>
> That is pretty much exactly what I am stating :)  Also there is the data
> directory that is inside of the PEAR configuration that can be used for
> common items as I stated above.  Application configuration allows us to
> provide the flexibility of being able to override the individual assets
> where needed having the fallback to the data folder.
>
> Regards,
>
> Mike
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Kevin McArthur-2
In reply to this post by padraicb
I'd +1 to avoiding pear.

We should follow a versioned, shared-library approach for the framework
itself allowing many versions of the framework to be installed onto a
single box and many applications running different versions to be able
to pick them up.

I'd like to see a __LATEST__ or similar version tag and improvements to
Zend_Version to alert the admin about security vulnerabilities and
outstanding upgrades as well.

As for resources, (like client application file packaging), I strongly
suggest looking at PHAR, and the component model of the framework overall.

--

Kevin McArthur

On 11-05-27 03:11 AM, Pádraic Brady wrote:

> Hi all,
>
> Since I haven't really chimed in on the resource location topic…
>
> The question of where to locate resources needs to be determined on the basis of
> what fits the surrounding code and not what best fits whichever packaging
> standard is being utilised. PEAR is, putting it bluntly, an incoherent set of
> standards based on what was perceived to be best practice in the 90s.
> Predictably, a considerable number of people don't bother using it except to
> install PHPUnit. So let's not let it determine the solution.
>
> The best solution, to my mind, is the simplest one. PHP 5.3 has a constant,
> __DIR__, accessible from any file. This gives us a fast, clear and obvious
> location for any class. Putting resources/files into any directory relative to
> that value ensures it can be accessed with a minimum of fuss. If folk need to
> define alternate paths, well, there's nothing stopping us from adding a check
> for that.
>
> The alternative, using PEAR's data/resource directories has numerous problems.
> It forces configuration onto users, adds uncertainty (local configuration of
> PEAR), and allows the packaging system to dictate what should be an independent
> decision.
>
> The purpose of a package system should be to store a set of files to an isolated
> part of the filesystem irrespective of what the internal file organisation might
> be. This preserves the original code's internal organisation and assumptions,
> allows simple running of unit tests, and viewing of documentation. PEAR's
> envisaged system of meddling with the filesystem is just a mess designed to
> impose misplaced standards. Docs are written (and overwritten), file name
> conflicts abound, running unit tests is unheard of (unless they're PHPT).
>
> It IS NOT our job as developers to meet the expectations of a package system. It
> IS its job to meet our expectations so we're willing to adopt and use it. Let's
> not get confused over who is in charge around here!
>
> P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus is no
> different.
>
> Paddy
>
>   Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
>
>
> ________________________________
> From: Mike Willbanks<[hidden email]>
> To: [hidden email]
> Cc: Matthew Weier O'Phinney<[hidden email]>
> Sent: Tue, April 12, 2011 3:42:45 PM
> Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things Go?
>
> Matthew,
>
> Sorry it has taken me a while to respond to this.  It has been some crazy
> last few weeks.
>
>
>> (on Monday, 04 April 2011, 01:38 PM -0500):
>>>> The questions are fairly simple: where do things go?  Currently, our
>>>> directory structure looks like this:
>>>>
>>>> ZendFramework/
>>>>     bin/
>>>>     documentation/
>>>>     externals/
>>>>     library/
>>>>     resources/
>>>>     tests/
>>>>
>>>> There are a couple of other things in there, but you get the picture.
>>>> Traditionally, the library directory is suppose to be for php class
>> files
>>>> only. The idea here is they can be found with an
>>>> autoloader/require_once/whatever and loaded based off some name.  This
>>>> directory should not be patched in any way shape or form, and there
>> should
>>>> be no expectation to add/alter/remove anything within it to have
>> working
>>>> components.
>>> First things first, since I get highly opinionated :)  I believe the
>>> standard distribution should now be through PEAR.  The library folder
>>> is really aggravating when I find that people took a ZF snapshot or
>>> specific version and bundled it.  Subsequently, we really need to
>>> attempt to keep the include path as small as possible to keep
>>> performance losses limited due to lstat and stat calls.  This is
>>> frequently an issue in larger installations and something that I have
>>> personally been working on limiting down in our current ZF 1.x
>>> application.
>> I'm going to jump in here, and note that ZF2 is going to be less
>> dependent on the include_path, to the point of being independent
>> whenever possible. The whole point of the autoloader research and work I
>> did last fall was due to profiling applications and determining
>> bottlenecks -- and the first and worst was relying on the include_path.
>>
>> So, while I understand keeping the include_path as small as possible,
>> my point is that it shouldn't be an issue in ZF2 applications unless
>> you're being lazy and using a fallback autoloader that utilizes it.
>>
>>
> It will still need to be utilized in a limited capacity which was the reason
> for my comment, I realize that we have the new class map autoloading as well
> and that should solve a lot of it.
>
>
>>>> This idea is further enforced by the structure of the PEAR system.
>>   PEAR
>>>> allows for placement of package assets (for example):
>>>>
>>>>     PEAR executables directory     bin_dir          /usr/bin
>>>>     PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>>>     PHP extension directory        ext_dir
>>>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>>>     PEAR directory                 php_dir          /usr/lib/php
>>>>     PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>>>     PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>>>     PEAR data directory            data_dir         /usr/lib/php/data
>>>>     PEAR Installer download        download_dir
>> /var/tmp/pear/download
>>>>     PHP CLI/CGI binary             php_bin          /usr/bin/php
>>>>     php.ini location               php_ini<not set>
>>>>     PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>>>     PEAR test directory            test_dir         /usr/lib/php/test
>>>>     PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>> We should certainly work towards a packaging system for library style
>>> components.  However, I do feel that if we made the standard
>>> distribution a PEAR installation; it would subsequently help us to
>>> highly recommend the PEAR packaging system through using something
>>> like Pirum and then packaging their own library components to be
>>> utilized through the PEAR packaging system.  Why build something
>>> specifically for ZF that already exists?
>> We're planning on utilizing PEAR infrastructure. The question that Ralph
>> is raising is: where do we put "resource" files, such as CodeGenerator
>> templates, locale files, etc?
>>
> These are generally always application specific.  In the case that there are
> specific ones for ZF that are shared, I would argue that the data directory
> would be made for this sort of thing.  Think of the apc.php file that is
> generally located in the data dir.  This is also where most projects put SQL
> creation files, templates and additional items.  The only thing to think
> about is how to override this configuration area and provide a secondary
> area in the application itself.
>
>
>> It's actually non-obvious when you look at the PEAR package assets
>> structure: would these be considered data? www files? configuration
>> (probably not, as the cfg_dir is usually reserved for PEAR and/or
>> executables)? I can actually see an argument for categorizing it as part
>> php_dir, simply because otherwise we need to worry about whether or not
>> the user has customized their PEAR environment (i.e., specified
>> locations other than the defaults for configuration).
>
> IMO www files should always be in the application configuration area.  More
> often than not you need those locally inside of the folder, otherwise if you
> were to organize them into the php_dir data area that pear has a simple
> include would handle much of the work for us.  You should not need to worry
> about a customized PEAR environment simply due to the variables that exist
> to state where things live aka: pear config-show will give you the locations
> that you need as well as pear config-get to locate the environment locations
> for PEAR directories.
>
>
>
>>>> While some of this doesn't apply to Zend Framework, it does enforce a
>> top
>>>> level that encourages each directory to have a specific purpose, and a
>>>> component/package will be disassembled and put into its proper place
>>>> according to the system.
>>> Many of these things do apply to ZF specifically as well as the
>>> extending and embedding of ZF.  The only reason we ever use the
>>> library folder is in the event of a needed patch for a ZF component
>>> that we are unable to overwrite utilizing our own classes.  However,
>>> we have started to move away from that completely taking the standard
>>> ZF PEAR package, applying patches and repackaging to a local PEAR
>>> repository which also houses our extensions on the top of ZF.
>>>
>>>> The alternative to this is to keep resources within the components
>> directory
>>>> itself.  Here is my for instance I'd like you to think of:
>>>>
>>>>   Zend\Tool will be able to ship multiple project profiles out
>>>>   the box in ZF2.  These might be xml, yaml, or even json
>>>>   profiles.  Where do they go?  Where does a developer expect
>>>>   to add his to the installation?
>>> These go in the standard PEAR installation area.  We really should
>>> start thinking about leveraging the community wide features and
>>> recommendations for installation.  This also aides shared hosting
>>> providers to install packages far easier.  A user could then override
>>> it by installing it locally and thus would need to tell their systems
>>> the include paths.  Now when we are talking about configuration of a
>>> project specifically, why not just store it in the application/configs
>>> area?
>>>
>>> I just really believe it would be inconsiderate as well as
>>> non-productive to make this a ZF specific item.  PEAR for distribution
>>> has been becoming far more popular as well as more scalable and I
>>> believe strongly that it would be a mistake to not make it the
>>> standard distribution.
>> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
>> Ralph's post is to try and determine where certain assets should be
>> placed when packaging. As such, you've answered that question to a
>> degree: you appear to be arguing that they should be in the PEAR dir
>> (php_dir in the above), and that developers would override this through
>> application configuration.
>>
>> Does that sound about right?
>>
> That is pretty much exactly what I am stating :)  Also there is the data
> directory that is inside of the PEAR configuration that can be used for
> common items as I stated above.  Application configuration allows us to
> provide the flexibility of being able to override the individual assets
> where needed having the fallback to the data folder.
>
> Regards,
>
> Mike
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Dolf Schimmel
Once again, this discussion is only meant at where we want resources
to go. After that we can evaluate what tool supports that.

Dolf
-- Freeaqingme

On Fri, May 27, 2011 at 6:13 PM, Kevin McArthur <[hidden email]> wrote:

> I'd +1 to avoiding pear.
>
> We should follow a versioned, shared-library approach for the framework
> itself allowing many versions of the framework to be installed onto a single
> box and many applications running different versions to be able to pick them
> up.
>
> I'd like to see a __LATEST__ or similar version tag and improvements to
> Zend_Version to alert the admin about security vulnerabilities and
> outstanding upgrades as well.
>
> As for resources, (like client application file packaging), I strongly
> suggest looking at PHAR, and the component model of the framework overall.
>
> --
>
> Kevin McArthur
>
> On 11-05-27 03:11 AM, Pádraic Brady wrote:
>>
>> Hi all,
>>
>> Since I haven't really chimed in on the resource location topic…
>>
>> The question of where to locate resources needs to be determined on the
>> basis of
>> what fits the surrounding code and not what best fits whichever packaging
>> standard is being utilised. PEAR is, putting it bluntly, an incoherent set
>> of
>> standards based on what was perceived to be best practice in the 90s.
>> Predictably, a considerable number of people don't bother using it except
>> to
>> install PHPUnit. So let's not let it determine the solution.
>>
>> The best solution, to my mind, is the simplest one. PHP 5.3 has a
>> constant,
>> __DIR__, accessible from any file. This gives us a fast, clear and obvious
>> location for any class. Putting resources/files into any directory
>> relative to
>> that value ensures it can be accessed with a minimum of fuss. If folk need
>> to
>> define alternate paths, well, there's nothing stopping us from adding a
>> check
>> for that.
>>
>> The alternative, using PEAR's data/resource directories has numerous
>> problems.
>> It forces configuration onto users, adds uncertainty (local configuration
>> of
>> PEAR), and allows the packaging system to dictate what should be an
>> independent
>> decision.
>>
>> The purpose of a package system should be to store a set of files to an
>> isolated
>> part of the filesystem irrespective of what the internal file organisation
>> might
>> be. This preserves the original code's internal organisation and
>> assumptions,
>> allows simple running of unit tests, and viewing of documentation. PEAR's
>> envisaged system of meddling with the filesystem is just a mess designed
>> to
>> impose misplaced standards. Docs are written (and overwritten), file name
>> conflicts abound, running unit tests is unheard of (unless they're PHPT).
>>
>> It IS NOT our job as developers to meet the expectations of a package
>> system. It
>> IS its job to meet our expectations so we're willing to adopt and use it.
>> Let's
>> not get confused over who is in charge around here!
>>
>> P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus
>> is no
>> different.
>>
>> Paddy
>>
>>  Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>>
>>
>>
>>
>>
>> ________________________________
>> From: Mike Willbanks<[hidden email]>
>> To: [hidden email]
>> Cc: Matthew Weier O'Phinney<[hidden email]>
>> Sent: Tue, April 12, 2011 3:42:45 PM
>> Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things
>> Go?
>>
>> Matthew,
>>
>> Sorry it has taken me a while to respond to this.  It has been some crazy
>> last few weeks.
>>
>>
>>> (on Monday, 04 April 2011, 01:38 PM -0500):
>>>>>
>>>>> The questions are fairly simple: where do things go?  Currently, our
>>>>> directory structure looks like this:
>>>>>
>>>>> ZendFramework/
>>>>>    bin/
>>>>>    documentation/
>>>>>    externals/
>>>>>    library/
>>>>>    resources/
>>>>>    tests/
>>>>>
>>>>> There are a couple of other things in there, but you get the picture.
>>>>> Traditionally, the library directory is suppose to be for php class
>>>
>>> files
>>>>>
>>>>> only. The idea here is they can be found with an
>>>>> autoloader/require_once/whatever and loaded based off some name.  This
>>>>> directory should not be patched in any way shape or form, and there
>>>
>>> should
>>>>>
>>>>> be no expectation to add/alter/remove anything within it to have
>>>
>>> working
>>>>>
>>>>> components.
>>>>
>>>> First things first, since I get highly opinionated :)  I believe the
>>>> standard distribution should now be through PEAR.  The library folder
>>>> is really aggravating when I find that people took a ZF snapshot or
>>>> specific version and bundled it.  Subsequently, we really need to
>>>> attempt to keep the include path as small as possible to keep
>>>> performance losses limited due to lstat and stat calls.  This is
>>>> frequently an issue in larger installations and something that I have
>>>> personally been working on limiting down in our current ZF 1.x
>>>> application.
>>>
>>> I'm going to jump in here, and note that ZF2 is going to be less
>>> dependent on the include_path, to the point of being independent
>>> whenever possible. The whole point of the autoloader research and work I
>>> did last fall was due to profiling applications and determining
>>> bottlenecks -- and the first and worst was relying on the include_path.
>>>
>>> So, while I understand keeping the include_path as small as possible,
>>> my point is that it shouldn't be an issue in ZF2 applications unless
>>> you're being lazy and using a fallback autoloader that utilizes it.
>>>
>>>
>> It will still need to be utilized in a limited capacity which was the
>> reason
>> for my comment, I realize that we have the new class map autoloading as
>> well
>> and that should solve a lot of it.
>>
>>
>>>>> This idea is further enforced by the structure of the PEAR system.
>>>
>>>  PEAR
>>>>>
>>>>> allows for placement of package assets (for example):
>>>>>
>>>>>    PEAR executables directory     bin_dir          /usr/bin
>>>>>    PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>>>>    PHP extension directory        ext_dir
>>>>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>>>>    PEAR directory                 php_dir          /usr/lib/php
>>>>>    PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>>>>    PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>>>>    PEAR data directory            data_dir         /usr/lib/php/data
>>>>>    PEAR Installer download        download_dir
>>>
>>> /var/tmp/pear/download
>>>>>
>>>>>    PHP CLI/CGI binary             php_bin          /usr/bin/php
>>>>>    php.ini location               php_ini<not set>
>>>>>    PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>>>>    PEAR test directory            test_dir         /usr/lib/php/test
>>>>>    PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>>>
>>>> We should certainly work towards a packaging system for library style
>>>> components.  However, I do feel that if we made the standard
>>>> distribution a PEAR installation; it would subsequently help us to
>>>> highly recommend the PEAR packaging system through using something
>>>> like Pirum and then packaging their own library components to be
>>>> utilized through the PEAR packaging system.  Why build something
>>>> specifically for ZF that already exists?
>>>
>>> We're planning on utilizing PEAR infrastructure. The question that Ralph
>>> is raising is: where do we put "resource" files, such as CodeGenerator
>>> templates, locale files, etc?
>>>
>> These are generally always application specific.  In the case that there
>> are
>> specific ones for ZF that are shared, I would argue that the data
>> directory
>> would be made for this sort of thing.  Think of the apc.php file that is
>> generally located in the data dir.  This is also where most projects put
>> SQL
>> creation files, templates and additional items.  The only thing to think
>> about is how to override this configuration area and provide a secondary
>> area in the application itself.
>>
>>
>>> It's actually non-obvious when you look at the PEAR package assets
>>> structure: would these be considered data? www files? configuration
>>> (probably not, as the cfg_dir is usually reserved for PEAR and/or
>>> executables)? I can actually see an argument for categorizing it as part
>>> php_dir, simply because otherwise we need to worry about whether or not
>>> the user has customized their PEAR environment (i.e., specified
>>> locations other than the defaults for configuration).
>>
>> IMO www files should always be in the application configuration area.
>>  More
>> often than not you need those locally inside of the folder, otherwise if
>> you
>> were to organize them into the php_dir data area that pear has a simple
>> include would handle much of the work for us.  You should not need to
>> worry
>> about a customized PEAR environment simply due to the variables that exist
>> to state where things live aka: pear config-show will give you the
>> locations
>> that you need as well as pear config-get to locate the environment
>> locations
>> for PEAR directories.
>>
>>
>>
>>>>> While some of this doesn't apply to Zend Framework, it does enforce a
>>>
>>> top
>>>>>
>>>>> level that encourages each directory to have a specific purpose, and a
>>>>> component/package will be disassembled and put into its proper place
>>>>> according to the system.
>>>>
>>>> Many of these things do apply to ZF specifically as well as the
>>>> extending and embedding of ZF.  The only reason we ever use the
>>>> library folder is in the event of a needed patch for a ZF component
>>>> that we are unable to overwrite utilizing our own classes.  However,
>>>> we have started to move away from that completely taking the standard
>>>> ZF PEAR package, applying patches and repackaging to a local PEAR
>>>> repository which also houses our extensions on the top of ZF.
>>>>
>>>>> The alternative to this is to keep resources within the components
>>>
>>> directory
>>>>>
>>>>> itself.  Here is my for instance I'd like you to think of:
>>>>>
>>>>>  Zend\Tool will be able to ship multiple project profiles out
>>>>>  the box in ZF2.  These might be xml, yaml, or even json
>>>>>  profiles.  Where do they go?  Where does a developer expect
>>>>>  to add his to the installation?
>>>>
>>>> These go in the standard PEAR installation area.  We really should
>>>> start thinking about leveraging the community wide features and
>>>> recommendations for installation.  This also aides shared hosting
>>>> providers to install packages far easier.  A user could then override
>>>> it by installing it locally and thus would need to tell their systems
>>>> the include paths.  Now when we are talking about configuration of a
>>>> project specifically, why not just store it in the application/configs
>>>> area?
>>>>
>>>> I just really believe it would be inconsiderate as well as
>>>> non-productive to make this a ZF specific item.  PEAR for distribution
>>>> has been becoming far more popular as well as more scalable and I
>>>> believe strongly that it would be a mistake to not make it the
>>>> standard distribution.
>>>
>>> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
>>> Ralph's post is to try and determine where certain assets should be
>>> placed when packaging. As such, you've answered that question to a
>>> degree: you appear to be arguing that they should be in the PEAR dir
>>> (php_dir in the above), and that developers would override this through
>>> application configuration.
>>>
>>> Does that sound about right?
>>>
>> That is pretty much exactly what I am stating :)  Also there is the data
>> directory that is inside of the PEAR configuration that can be used for
>> common items as I stated above.  Application configuration allows us to
>> provide the flexibility of being able to override the individual assets
>> where needed having the fallback to the data folder.
>>
>> Regards,
>>
>> Mike
>>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion Time: In ZF2, Where Do Things Go?

Kevin McArthur-2
Dolf,

The question of where things go is one of how they are packaged IMO.

If we use PHAR's for example, everything must be in a single
package-able area. (each phar being a clone of the
controller/model/view/etc hierarchy and probably resembling a small zfw
app itself)

If we don't decide that, then what, we decide to have 10 phars in a
buncha dirs? See what I'm getting at.

Packaging is directly relevant to file locations.

--

Kevin

On 11-05-27 09:35 AM, Dolf Schimmel wrote:

> Once again, this discussion is only meant at where we want resources
> to go. After that we can evaluate what tool supports that.
>
> Dolf
> -- Freeaqingme
>
> On Fri, May 27, 2011 at 6:13 PM, Kevin McArthur<[hidden email]>  wrote:
>> I'd +1 to avoiding pear.
>>
>> We should follow a versioned, shared-library approach for the framework
>> itself allowing many versions of the framework to be installed onto a single
>> box and many applications running different versions to be able to pick them
>> up.
>>
>> I'd like to see a __LATEST__ or similar version tag and improvements to
>> Zend_Version to alert the admin about security vulnerabilities and
>> outstanding upgrades as well.
>>
>> As for resources, (like client application file packaging), I strongly
>> suggest looking at PHAR, and the component model of the framework overall.
>>
>> --
>>
>> Kevin McArthur
>>
>> On 11-05-27 03:11 AM, Pádraic Brady wrote:
>>> Hi all,
>>>
>>> Since I haven't really chimed in on the resource location topic…
>>>
>>> The question of where to locate resources needs to be determined on the
>>> basis of
>>> what fits the surrounding code and not what best fits whichever packaging
>>> standard is being utilised. PEAR is, putting it bluntly, an incoherent set
>>> of
>>> standards based on what was perceived to be best practice in the 90s.
>>> Predictably, a considerable number of people don't bother using it except
>>> to
>>> install PHPUnit. So let's not let it determine the solution.
>>>
>>> The best solution, to my mind, is the simplest one. PHP 5.3 has a
>>> constant,
>>> __DIR__, accessible from any file. This gives us a fast, clear and obvious
>>> location for any class. Putting resources/files into any directory
>>> relative to
>>> that value ensures it can be accessed with a minimum of fuss. If folk need
>>> to
>>> define alternate paths, well, there's nothing stopping us from adding a
>>> check
>>> for that.
>>>
>>> The alternative, using PEAR's data/resource directories has numerous
>>> problems.
>>> It forces configuration onto users, adds uncertainty (local configuration
>>> of
>>> PEAR), and allows the packaging system to dictate what should be an
>>> independent
>>> decision.
>>>
>>> The purpose of a package system should be to store a set of files to an
>>> isolated
>>> part of the filesystem irrespective of what the internal file organisation
>>> might
>>> be. This preserves the original code's internal organisation and
>>> assumptions,
>>> allows simple running of unit tests, and viewing of documentation. PEAR's
>>> envisaged system of meddling with the filesystem is just a mess designed
>>> to
>>> impose misplaced standards. Docs are written (and overwritten), file name
>>> conflicts abound, running unit tests is unheard of (unless they're PHPT).
>>>
>>> It IS NOT our job as developers to meet the expectations of a package
>>> system. It
>>> IS its job to meet our expectations so we're willing to adopt and use it.
>>> Let's
>>> not get confused over who is in charge around here!
>>>
>>> P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus
>>> is no
>>> different.
>>>
>>> Paddy
>>>
>>>   Pádraic Brady
>>>
>>> http://blog.astrumfutura.com
>>> http://www.survivethedeepend.com
>>> Zend Framework Community Review Team
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Mike Willbanks<[hidden email]>
>>> To: [hidden email]
>>> Cc: Matthew Weier O'Phinney<[hidden email]>
>>> Sent: Tue, April 12, 2011 3:42:45 PM
>>> Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things
>>> Go?
>>>
>>> Matthew,
>>>
>>> Sorry it has taken me a while to respond to this.  It has been some crazy
>>> last few weeks.
>>>
>>>
>>>> (on Monday, 04 April 2011, 01:38 PM -0500):
>>>>>> The questions are fairly simple: where do things go?  Currently, our
>>>>>> directory structure looks like this:
>>>>>>
>>>>>> ZendFramework/
>>>>>>     bin/
>>>>>>     documentation/
>>>>>>     externals/
>>>>>>     library/
>>>>>>     resources/
>>>>>>     tests/
>>>>>>
>>>>>> There are a couple of other things in there, but you get the picture.
>>>>>> Traditionally, the library directory is suppose to be for php class
>>>> files
>>>>>> only. The idea here is they can be found with an
>>>>>> autoloader/require_once/whatever and loaded based off some name.  This
>>>>>> directory should not be patched in any way shape or form, and there
>>>> should
>>>>>> be no expectation to add/alter/remove anything within it to have
>>>> working
>>>>>> components.
>>>>> First things first, since I get highly opinionated :)  I believe the
>>>>> standard distribution should now be through PEAR.  The library folder
>>>>> is really aggravating when I find that people took a ZF snapshot or
>>>>> specific version and bundled it.  Subsequently, we really need to
>>>>> attempt to keep the include path as small as possible to keep
>>>>> performance losses limited due to lstat and stat calls.  This is
>>>>> frequently an issue in larger installations and something that I have
>>>>> personally been working on limiting down in our current ZF 1.x
>>>>> application.
>>>> I'm going to jump in here, and note that ZF2 is going to be less
>>>> dependent on the include_path, to the point of being independent
>>>> whenever possible. The whole point of the autoloader research and work I
>>>> did last fall was due to profiling applications and determining
>>>> bottlenecks -- and the first and worst was relying on the include_path.
>>>>
>>>> So, while I understand keeping the include_path as small as possible,
>>>> my point is that it shouldn't be an issue in ZF2 applications unless
>>>> you're being lazy and using a fallback autoloader that utilizes it.
>>>>
>>>>
>>> It will still need to be utilized in a limited capacity which was the
>>> reason
>>> for my comment, I realize that we have the new class map autoloading as
>>> well
>>> and that should solve a lot of it.
>>>
>>>
>>>>>> This idea is further enforced by the structure of the PEAR system.
>>>>   PEAR
>>>>>> allows for placement of package assets (for example):
>>>>>>
>>>>>>     PEAR executables directory     bin_dir          /usr/bin
>>>>>>     PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>>>>>     PHP extension directory        ext_dir
>>>>>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>>>>>     PEAR directory                 php_dir          /usr/lib/php
>>>>>>     PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>>>>>     PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>>>>>     PEAR data directory            data_dir         /usr/lib/php/data
>>>>>>     PEAR Installer download        download_dir
>>>> /var/tmp/pear/download
>>>>>>     PHP CLI/CGI binary             php_bin          /usr/bin/php
>>>>>>     php.ini location               php_ini<not set>
>>>>>>     PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>>>>>     PEAR test directory            test_dir         /usr/lib/php/test
>>>>>>     PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>>>> We should certainly work towards a packaging system for library style
>>>>> components.  However, I do feel that if we made the standard
>>>>> distribution a PEAR installation; it would subsequently help us to
>>>>> highly recommend the PEAR packaging system through using something
>>>>> like Pirum and then packaging their own library components to be
>>>>> utilized through the PEAR packaging system.  Why build something
>>>>> specifically for ZF that already exists?
>>>> We're planning on utilizing PEAR infrastructure. The question that Ralph
>>>> is raising is: where do we put "resource" files, such as CodeGenerator
>>>> templates, locale files, etc?
>>>>
>>> These are generally always application specific.  In the case that there
>>> are
>>> specific ones for ZF that are shared, I would argue that the data
>>> directory
>>> would be made for this sort of thing.  Think of the apc.php file that is
>>> generally located in the data dir.  This is also where most projects put
>>> SQL
>>> creation files, templates and additional items.  The only thing to think
>>> about is how to override this configuration area and provide a secondary
>>> area in the application itself.
>>>
>>>
>>>> It's actually non-obvious when you look at the PEAR package assets
>>>> structure: would these be considered data? www files? configuration
>>>> (probably not, as the cfg_dir is usually reserved for PEAR and/or
>>>> executables)? I can actually see an argument for categorizing it as part
>>>> php_dir, simply because otherwise we need to worry about whether or not
>>>> the user has customized their PEAR environment (i.e., specified
>>>> locations other than the defaults for configuration).
>>> IMO www files should always be in the application configuration area.
>>>   More
>>> often than not you need those locally inside of the folder, otherwise if
>>> you
>>> were to organize them into the php_dir data area that pear has a simple
>>> include would handle much of the work for us.  You should not need to
>>> worry
>>> about a customized PEAR environment simply due to the variables that exist
>>> to state where things live aka: pear config-show will give you the
>>> locations
>>> that you need as well as pear config-get to locate the environment
>>> locations
>>> for PEAR directories.
>>>
>>>
>>>
>>>>>> While some of this doesn't apply to Zend Framework, it does enforce a
>>>> top
>>>>>> level that encourages each directory to have a specific purpose, and a
>>>>>> component/package will be disassembled and put into its proper place
>>>>>> according to the system.
>>>>> Many of these things do apply to ZF specifically as well as the
>>>>> extending and embedding of ZF.  The only reason we ever use the
>>>>> library folder is in the event of a needed patch for a ZF component
>>>>> that we are unable to overwrite utilizing our own classes.  However,
>>>>> we have started to move away from that completely taking the standard
>>>>> ZF PEAR package, applying patches and repackaging to a local PEAR
>>>>> repository which also houses our extensions on the top of ZF.
>>>>>
>>>>>> The alternative to this is to keep resources within the components
>>>> directory
>>>>>> itself.  Here is my for instance I'd like you to think of:
>>>>>>
>>>>>>   Zend\Tool will be able to ship multiple project profiles out
>>>>>>   the box in ZF2.  These might be xml, yaml, or even json
>>>>>>   profiles.  Where do they go?  Where does a developer expect
>>>>>>   to add his to the installation?
>>>>> These go in the standard PEAR installation area.  We really should
>>>>> start thinking about leveraging the community wide features and
>>>>> recommendations for installation.  This also aides shared hosting
>>>>> providers to install packages far easier.  A user could then override
>>>>> it by installing it locally and thus would need to tell their systems
>>>>> the include paths.  Now when we are talking about configuration of a
>>>>> project specifically, why not just store it in the application/configs
>>>>> area?
>>>>>
>>>>> I just really believe it would be inconsiderate as well as
>>>>> non-productive to make this a ZF specific item.  PEAR for distribution
>>>>> has been becoming far more popular as well as more scalable and I
>>>>> believe strongly that it would be a mistake to not make it the
>>>>> standard distribution.
>>>> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
>>>> Ralph's post is to try and determine where certain assets should be
>>>> placed when packaging. As such, you've answered that question to a
>>>> degree: you appear to be arguing that they should be in the PEAR dir
>>>> (php_dir in the above), and that developers would override this through
>>>> application configuration.
>>>>
>>>> Does that sound about right?
>>>>
>>> That is pretty much exactly what I am stating :)  Also there is the data
>>> directory that is inside of the PEAR configuration that can be used for
>>> common items as I stated above.  Application configuration allows us to
>>> provide the flexibility of being able to override the individual assets
>>> where needed having the fallback to the data folder.
>>>
>>> Regards,
>>>
>>> Mike
>>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to package ZF2 (was: Discussion Time: In ZF2, Where Do Things Go?)

padraicb
Switched subject so we keep the spacetime continuum intact ;).

There are 3-4 options for a package manager:

1. PEAR Installer
2. Pyrus Installer (PEAR2)
3. git
4. Symfony2-related bundle manager (unnamed and under development)

PEAR:

Pros:
- widely adopted and installed
- uses a relatively simple channels for distribution from source
- it's stable and works right now
Cons:
- doesn't support versioning (i.e. access to multiple versions of one package)
- source identity verification is non-existent
- packages require an XML definition intermediary

Pyrus:

Pros:
- doesn't rock the PEAR boat
- source identity verification is supported by default
- claims to be significantly better performance wise
Cons:
- doesn't support versioning
- packages require an XML definition intermediary
- it's currently unstable (in alpha)
- doesn't change much else from PEAR

Git:

Pros:
- widely adopted and installed
- it's stable and works right now
Cons:
- there's no package manager leveraging git

Unnamed Symfony2-related bundle manager thingy:

Pros (as heard on the grapevine):
- meta package installer (supports git, PEAR, bundles)
- likely to solve Symfony 2 bundle distribution
- likely to be non-specific to "bundles"
Cons:
- it doesn't exist yet

The pros and cons are off the top of my head and not intended as a complete
picture, but basically we don't have any one particularly great option. As
things stand, PEAR is the devil we know and understand best. If Pyrus stablises,
I've suggested previously they be requested to consider adding support for a few
features:

1. Versioning

A server may host many apps requiring different versions of any one package.
This isn't weird, unusual or rare. It's what I'm doing right now on multiple
servers - and that means I NEVER use or recommend PEAR to manage libraries on a
live server.

2. Simpler Package Definition

There's no reason not to use something like a PHP closure to combine the
definition and build instructions into one consumable unit. XML package
definitions are generally written by hand to never require change (omitting
stuff like MD5 file hashes) or require a whole other package build stage that
needs its own configuration file. This is silly when we can combine everything
into one PHP5 structure.

3. Support for git hosted source code

Most stuff is on git these days. Why should those guys (namely everyone here!)
have to run around writing whole build scripts instead of "git clone" and
"copy"? Yes, it's not that simple, I know - but surely worth the time given
git's pervasiveness.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Kevin McArthur <[hidden email]>
To: [hidden email]
Sent: Fri, May 27, 2011 6:08:57 PM
Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things Go?

Dolf,

The question of where things go is one of how they are packaged IMO.

If we use PHAR's for example, everything must be in a single
package-able area. (each phar being a clone of the
controller/model/view/etc hierarchy and probably resembling a small zfw
app itself)

If we don't decide that, then what, we decide to have 10 phars in a
buncha dirs? See what I'm getting at.

Packaging is directly relevant to file locations.

--

Kevin

On 11-05-27 09:35 AM, Dolf Schimmel wrote:

> Once again, this discussion is only meant at where we want resources
> to go. After that we can evaluate what tool supports that.
>
> Dolf
> -- Freeaqingme
>
> On Fri, May 27, 2011 at 6:13 PM, Kevin McArthur<[hidden email]>  wrote:
>> I'd +1 to avoiding pear.
>>
>> We should follow a versioned, shared-library approach for the framework
>> itself allowing many versions of the framework to be installed onto a single
>> box and many applications running different versions to be able to pick them
>> up.
>>
>> I'd like to see a __LATEST__ or similar version tag and improvements to
>> Zend_Version to alert the admin about security vulnerabilities and
>> outstanding upgrades as well.
>>
>> As for resources, (like client application file packaging), I strongly
>> suggest looking at PHAR, and the component model of the framework overall.
>>
>> --
>>
>> Kevin McArthur
>>
>> On 11-05-27 03:11 AM, Pádraic Brady wrote:
>>> Hi all,
>>>
>>> Since I haven't really chimed in on the resource location topic…
>>>
>>> The question of where to locate resources needs to be determined on the
>>> basis of
>>> what fits the surrounding code and not what best fits whichever packaging
>>> standard is being utilised. PEAR is, putting it bluntly, an incoherent set
>>> of
>>> standards based on what was perceived to be best practice in the 90s.
>>> Predictably, a considerable number of people don't bother using it except
>>> to
>>> install PHPUnit. So let's not let it determine the solution.
>>>
>>> The best solution, to my mind, is the simplest one. PHP 5.3 has a
>>> constant,
>>> __DIR__, accessible from any file. This gives us a fast, clear and obvious
>>> location for any class. Putting resources/files into any directory
>>> relative to
>>> that value ensures it can be accessed with a minimum of fuss. If folk need
>>> to
>>> define alternate paths, well, there's nothing stopping us from adding a
>>> check
>>> for that.
>>>
>>> The alternative, using PEAR's data/resource directories has numerous
>>> problems.
>>> It forces configuration onto users, adds uncertainty (local configuration
>>> of
>>> PEAR), and allows the packaging system to dictate what should be an
>>> independent
>>> decision.
>>>
>>> The purpose of a package system should be to store a set of files to an
>>> isolated
>>> part of the filesystem irrespective of what the internal file organisation
>>> might
>>> be. This preserves the original code's internal organisation and
>>> assumptions,
>>> allows simple running of unit tests, and viewing of documentation. PEAR's
>>> envisaged system of meddling with the filesystem is just a mess designed
>>> to
>>> impose misplaced standards. Docs are written (and overwritten), file name
>>> conflicts abound, running unit tests is unheard of (unless they're PHPT).
>>>
>>> It IS NOT our job as developers to meet the expectations of a package
>>> system. It
>>> IS its job to meet our expectations so we're willing to adopt and use it.
>>> Let's
>>> not get confused over who is in charge around here!
>>>
>>> P.S. PEAR lets you add any file to the PHP role. I'm going to assume Pyrus
>>> is no
>>> different.
>>>
>>> Paddy
>>>
>>>   Pádraic Brady
>>>
>>> http://blog.astrumfutura.com
>>> http://www.survivethedeepend.com
>>> Zend Framework Community Review Team
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Mike Willbanks<[hidden email]>
>>> To: [hidden email]
>>> Cc: Matthew Weier O'Phinney<[hidden email]>
>>> Sent: Tue, April 12, 2011 3:42:45 PM
>>> Subject: Re: [zf-contributors] Discussion Time: In ZF2, Where Do Things
>>> Go?
>>>
>>> Matthew,
>>>
>>> Sorry it has taken me a while to respond to this.  It has been some crazy
>>> last few weeks.
>>>
>>>
>>>> (on Monday, 04 April 2011, 01:38 PM -0500):
>>>>>> The questions are fairly simple: where do things go?  Currently, our
>>>>>> directory structure looks like this:
>>>>>>
>>>>>> ZendFramework/
>>>>>>     bin/
>>>>>>     documentation/
>>>>>>     externals/
>>>>>>     library/
>>>>>>     resources/
>>>>>>     tests/
>>>>>>
>>>>>> There are a couple of other things in there, but you get the picture.
>>>>>> Traditionally, the library directory is suppose to be for php class
>>>> files
>>>>>> only. The idea here is they can be found with an
>>>>>> autoloader/require_once/whatever and loaded based off some name.  This
>>>>>> directory should not be patched in any way shape or form, and there
>>>> should
>>>>>> be no expectation to add/alter/remove anything within it to have
>>>> working
>>>>>> components.
>>>>> First things first, since I get highly opinionated :)  I believe the
>>>>> standard distribution should now be through PEAR.  The library folder
>>>>> is really aggravating when I find that people took a ZF snapshot or
>>>>> specific version and bundled it.  Subsequently, we really need to
>>>>> attempt to keep the include path as small as possible to keep
>>>>> performance losses limited due to lstat and stat calls.  This is
>>>>> frequently an issue in larger installations and something that I have
>>>>> personally been working on limiting down in our current ZF 1.x
>>>>> application.
>>>> I'm going to jump in here, and note that ZF2 is going to be less
>>>> dependent on the include_path, to the point of being independent
>>>> whenever possible. The whole point of the autoloader research and work I
>>>> did last fall was due to profiling applications and determining
>>>> bottlenecks -- and the first and worst was relying on the include_path.
>>>>
>>>> So, while I understand keeping the include_path as small as possible,
>>>> my point is that it shouldn't be an issue in ZF2 applications unless
>>>> you're being lazy and using a fallback autoloader that utilizes it.
>>>>
>>>>
>>> It will still need to be utilized in a limited capacity which was the
>>> reason
>>> for my comment, I realize that we have the new class map autoloading as
>>> well
>>> and that should solve a lot of it.
>>>
>>>
>>>>>> This idea is further enforced by the structure of the PEAR system.
>>>>   PEAR
>>>>>> allows for placement of package assets (for example):
>>>>>>
>>>>>>     PEAR executables directory     bin_dir          /usr/bin
>>>>>>     PEAR documentation directory   doc_dir          /usr/lib/php/doc
>>>>>>     PHP extension directory        ext_dir
>>>>>> /usr/lib/php/extensions/no-debug-non-zts-20090626
>>>>>>     PEAR directory                 php_dir          /usr/lib/php
>>>>>>     PEAR Installer cache directory cache_dir        /var/tmp/pear/cache
>>>>>>     PEAR configuration file        cfg_dir          /usr/lib/php/cfg
>>>>>>     PEAR data directory            data_dir         /usr/lib/php/data
>>>>>>     PEAR Installer download        download_dir
>>>> /var/tmp/pear/download
>>>>>>     PHP CLI/CGI binary             php_bin          /usr/bin/php
>>>>>>     php.ini location               php_ini<not set>
>>>>>>     PEAR Installer temp directory  temp_dir         /var/tmp/pear/temp
>>>>>>     PEAR test directory            test_dir         /usr/lib/php/test
>>>>>>     PEAR www files directory       www_dir          /usr/lib/php/htdocs
>>>>> We should certainly work towards a packaging system for library style
>>>>> components.  However, I do feel that if we made the standard
>>>>> distribution a PEAR installation; it would subsequently help us to
>>>>> highly recommend the PEAR packaging system through using something
>>>>> like Pirum and then packaging their own library components to be
>>>>> utilized through the PEAR packaging system.  Why build something
>>>>> specifically for ZF that already exists?
>>>> We're planning on utilizing PEAR infrastructure. The question that Ralph
>>>> is raising is: where do we put "resource" files, such as CodeGenerator
>>>> templates, locale files, etc?
>>>>
>>> These are generally always application specific.  In the case that there
>>> are
>>> specific ones for ZF that are shared, I would argue that the data
>>> directory
>>> would be made for this sort of thing.  Think of the apc.php file that is
>>> generally located in the data dir.  This is also where most projects put
>>> SQL
>>> creation files, templates and additional items.  The only thing to think
>>> about is how to override this configuration area and provide a secondary
>>> area in the application itself.
>>>
>>>
>>>> It's actually non-obvious when you look at the PEAR package assets
>>>> structure: would these be considered data? www files? configuration
>>>> (probably not, as the cfg_dir is usually reserved for PEAR and/or
>>>> executables)? I can actually see an argument for categorizing it as part
>>>> php_dir, simply because otherwise we need to worry about whether or not
>>>> the user has customized their PEAR environment (i.e., specified
>>>> locations other than the defaults for configuration).
>>> IMO www files should always be in the application configuration area.
>>>   More
>>> often than not you need those locally inside of the folder, otherwise if
>>> you
>>> were to organize them into the php_dir data area that pear has a simple
>>> include would handle much of the work for us.  You should not need to
>>> worry
>>> about a customized PEAR environment simply due to the variables that exist
>>> to state where things live aka: pear config-show will give you the
>>> locations
>>> that you need as well as pear config-get to locate the environment
>>> locations
>>> for PEAR directories.
>>>
>>>
>>>
>>>>>> While some of this doesn't apply to Zend Framework, it does enforce a
>>>> top
>>>>>> level that encourages each directory to have a specific purpose, and a
>>>>>> component/package will be disassembled and put into its proper place
>>>>>> according to the system.
>>>>> Many of these things do apply to ZF specifically as well as the
>>>>> extending and embedding of ZF.  The only reason we ever use the
>>>>> library folder is in the event of a needed patch for a ZF component
>>>>> that we are unable to overwrite utilizing our own classes.  However,
>>>>> we have started to move away from that completely taking the standard
>>>>> ZF PEAR package, applying patches and repackaging to a local PEAR
>>>>> repository which also houses our extensions on the top of ZF.
>>>>>
>>>>>> The alternative to this is to keep resources within the components
>>>> directory
>>>>>> itself.  Here is my for instance I'd like you to think of:
>>>>>>
>>>>>>   Zend\Tool will be able to ship multiple project profiles out
>>>>>>   the box in ZF2.  These might be xml, yaml, or even json
>>>>>>   profiles.  Where do they go?  Where does a developer expect
>>>>>>   to add his to the installation?
>>>>> These go in the standard PEAR installation area.  We really should
>>>>> start thinking about leveraging the community wide features and
>>>>> recommendations for installation.  This also aides shared hosting
>>>>> providers to install packages far easier.  A user could then override
>>>>> it by installing it locally and thus would need to tell their systems
>>>>> the include paths.  Now when we are talking about configuration of a
>>>>> project specifically, why not just store it in the application/configs
>>>>> area?
>>>>>
>>>>> I just really believe it would be inconsiderate as well as
>>>>> non-productive to make this a ZF specific item.  PEAR for distribution
>>>>> has been becoming far more popular as well as more scalable and I
>>>>> believe strongly that it would be a mistake to not make it the
>>>>> standard distribution.
>>>> Again, we're planning on leveraging PEAR and/or Pyrus. The goal of
>>>> Ralph's post is to try and determine where certain assets should be
>>>> placed when packaging. As such, you've answered that question to a
>>>> degree: you appear to be arguing that they should be in the PEAR dir
>>>> (php_dir in the above), and that developers would override this through
>>>> application configuration.
>>>>
>>>> Does that sound about right?
>>>>
>>> That is pretty much exactly what I am stating :)  Also there is the data
>>> directory that is inside of the PEAR configuration that can be used for
>>> common items as I stated above.  Application configuration allows us to
>>> provide the flexibility of being able to override the individual assets
>>> where needed having the fallback to the data folder.
>>>
>>> Regards,
>>>
>>> Mike
>>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]
123
Loading...