-- Ralph Schindler <ralph.schindler@...> wrote
(on Wednesday, 23 July 2008, 11:38 AM -0500):
> Sorry everyone, that url broke in my last email.. Here is the tinyurl for it
>
> http://framework.zend.com/wiki/x/jAJO
>
> Thanks again, and please when you get a chance to read, send your comments
> back into this email thread.

Okay, my principle comment lies in the breakdown of the requirements to
the three points:

     * Tooling Subsystem
     * Project Management system
     * Code Generator

While I understand that the CLI tool is part of the Tooling Subsystem, I
think that relation could be made clearer, and could potentially be a
separate proposal -- a concrete consumer of the Tooling Subsystem.


> On 7/22/08 11:34 AM, "Ralph Schindler" <ralph.schindler@...> wrote:
>
> >
> >
> >
> >
> > Hello everyone!
> >
> > I have created a document that will serve as an "umbrella proposal", or as a
> > proposal to tie together the existing Zend_Tool-based proposals in a way
> > that will help everyone make heads-and-tails of everything.
> >
> > I wont post it in this email but I WOULD like the discussion to stay in this
> > email tread.  So without further ado, please visit this document - have a
> > read - and come back and let me know if there is anything in there that
> > needs to be spelled out and made clearer.
> >
> > http://framework.zend.com/wiki/display/ZFDEV/Zend+Tool+Initiative+-+Umbrella
> > +Proposal+Draft

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend Framework           | http://framework.zend.com/

Sorry everyone, that url broke in my last email.. Here is the tinyurl for it

http://framework.zend.com/wiki/x/jAJO

Thanks again, and please when you get a chance to read, send your comments
back into this email thread.

-Ralph


On 7/22/08 11:34 AM, "Ralph Schindler" <ralph.schindler@...> wrote:

>
>
>
>
> Hello everyone!
>
> I have created a document that will serve as an "umbrella proposal", or as a
> proposal to tie together the existing Zend_Tool-based proposals in a way
> that will help everyone make heads-and-tails of everything.
>
> I wont post it in this email but I WOULD like the discussion to stay in this
> email tread.  So without further ado, please visit this document - have a
> read - and come back and let me know if there is anything in there that
> needs to be spelled out and made clearer.
>
> http://framework.zend.com/wiki/display/ZFDEV/Zend+Tool+Initiative+-+Umbrella
> +Proposal+Draft
>
> Thanks again!
> -Ralph

--
Ralph Schindler
Software Engineer     | ralph.schindler@...
Zend Framework        | http://framework.zend.com/

Hello everyone!

I have created a document that will serve as an "umbrella proposal", or as a
proposal to tie together the existing Zend_Tool-based proposals in a way
that will help everyone make heads-and-tails of everything.

I wont post it in this email but I WOULD like the discussion to stay in this
email tread.  So without further ado, please visit this document - have a
read - and come back and let me know if there is anything in there that
needs to be spelled out and made clearer.

http://framework.zend.com/wiki/display/ZFDEV/Zend+Tool+Initiative+-+Umbrella
+Proposal+Draft

Thanks again!
-Ralph

--
Ralph Schindler
Software Engineer     | ralph.schindler@...
Zend Framework        | http://framework.zend.com/

--- In zf-tool@yahoogroups.com, "emails4nir" <emails4nir@...> wrote:
>
> small question:
>
> "Assuming you have only one - what is the one feature that you would
> like to see in your ide that supports Zend Tool?"
>

and thanks to Ralph for creating this group.

(It was me registered with another user emails4nir...)
- Roy

small question:

"Assuming you have only one - what is the one feature that you would
like to see in your ide that supports Zend Tool?"

few ideas are: (but you can raise more)

* XML Repository editor - this editor provides a multi pages (textual
and graphical) editor for users who want to edit their repository.

* Hierarchical menu for most important operations - users select
actions from menu and then have a dialog with relevant properties

* code completion in a dedicated console - users have a console as a
view where they can write their own commands and have code completion
for their commands.

_my_ choice - code completion

I only thought of it after, but the redeclaration of classes error is
likely from including the svn files containing copies of the class
code. Fix the svn inclusions and it should go away by itself.

--- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@...>
wrote:
>
> That¹s great feedback, I am booting into Vista and will track down any
> platform related issues, it should be trivial to make it win32 path
> acceptable.
>
> Oh, and yeah, the the provider/manifest scanner is prob recursing
into those
> .svn directories, ill make sure it doesn¹t do that.
>
> -ralph
>
>
> On 7/17/08 4:09 AM, "Pádraic Brady" <padraic.brady@...> wrote:
>
> >
> >
> >
> > Hi Ralph,
> >
> > Going to try this out on my Ubuntu machine in a few minutes. I'm
> > dragging my Windows laptop around with me (clients and their MS
> > addiction) so I tried it out there first. I know you probably weren't
> > focusing on Windows immediately but it would be great to have it
> > working on all platforms.
> >
> > It fails under Windows on a few areas. First of all it seems to use
> > Zend_Loader::loadFile() with absolute paths which won't work since
> > Windows absolute paths contain a colon ":" character which fails the
> > security checks - the loadFile() method was only ever intended for
> > loading ZF class files. When I bypass that problem I get:
> >
> > Fatal error: Cannot redeclare class
> > ZendL_Controller_Tool_ActionProvider in
> > D:\projects\ztool\library\ZendL\Controlle\Tool\ActionProvider.php on
> > line 37
> >
> > The other thing I observed was an attempt to load up at least one SVN
> > base file - this may be intentional though. I'm using it as an excuse
> > to dig around in the source code anyhow ;).
> >
> > Back when I have linuxed up...
> >
> > Paddy
> >
> > --- In zf-tool@yahoogroups.com <mailto:zf-tool%40yahoogroups.com>
, Ralph
> > Schindler <ralph.schindler@>
> > wrote:
> >> >
> >> >
> >> > Hi all,
> >> >
> >> > Here is a little task just to see how easy it is for everyone
to get the
> >> > current code / prototype.  I have confirmed this works for me
(as I have
> >> > produced the script), but I want to make sure there are no
pitfalls for
> >> > anyone when it comes to getting this code working.
> >> >
> >> > Let me know what your mileage is with the script below:
> >> >
> >> > Thanks!
> >> >
> >> >
> >
=========================================================================
> >> >
> >> >
> >> > Getting the code
> >> >
> >> >     ~$ cd tmp/
> >> >     ~/tmp$ svn export
> >> > http://framework.zend.com/svn/framework/laboratory/Zend_Tool/
> >> >
> >> >
> >> > Making a link to my zf.sh (I have ~/.bin/ in my path to look for
> >> > executables)
> >> >
> >> >     ~$ ln -s ~/tmp/Zend_Tool/bin/zf.sh ~/.bin/zf
> >> >     ~$ ls -la ~/.bin/zf
> >> >     lrwxr-xr-x  1 ralphschindler  staff  45 Jul 16 23:39
> >> > /Users/ralphschindler/.bin/zf ->
> >> > /Users/ralphschindler/tmp/Zend_Tool/bin/zf.sh
> >> >
> >> >
> >> > Lets try it!
> >> >
> >> >     ~$ which zf
> >> >     /Users/ralphschindler/.bin/zf
> >> >
> >> >     ~$ zf show version
> >> >     While in development: please set env var ZF_PATH to your
copy of
> > zend
> >> > framework.
> >> >
> >> >
> >> > Lets set the Zf env variable as it asks (This needs to be a
full path):
> >> >
> >> >     ~$ export
> >> >
> >
ZF_PATH="/Users/ralphschindler/Projects/code-zendframework/repo-standard/tru
> >> > nk/library/"
> >> >
> >> >
> >> > Ok, now things should work:
> >> >
> >> >     ~$ zf show version
> >> >     Zend Framework Version: 1.5.2
> >> >
> >> >
> >> > Errata - This is what my paths look like:
> >> >
> >> >     ~$ env | grep PATH
> >> >     MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man
> >> >
> >> >
> >
ZF_PATH=/Users/ralphschindler/Projects/code-zendframework/repo-standard/trun
> >> > k/library/
> >> >
> >> >
> >
PATH=/Users/ralphschindler/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
> >> > :/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Ralph Schindler
> >> > Software Engineer     | ralph.schindler@
> >> > Zend Framework        | http://framework.zend.com/
> >> >
> >
> >
> >
> >>>
> >>> --
> >>> Ralph Schindler
> >>> Software Engineer     | ralph.schindler@...
> >>> Zend Framework        | http://framework.zend.com/
> >>>
>

 

I have confirmed that the issue is PHP 5.3

When I downgrade, everything works fine.

=C=
--- In zf-tool@yahoogroups.com <mailto:zf-tool%40yahoogroups.com> , "Cal Evans" <cal@...> wrote:
>
> Oh, Environment is:
> CentoOS with PHP 5.3
>
> =C=
>
> --- In zf-tool@yahoogroups.com <mailto:zf-tool%40yahoogroups.com> , "Cal Evans" <cal@> wrote:
> >
> > --- In zf-tool@yahoogroups.com <mailto:zf-tool%40yahoogroups.com> , Ralph Schindler <ralph.schindler@>
> > wrote:
> > >
> > >
> > > Hi all,
> > >
> > > Here is a little task just to see how easy it is for everyone to
> get the
> > > current code / prototype.  I have confirmed this works for me (as
> I have
> > > produced the script), but I want to make sure there are no
> pitfalls for
> > > anyone when it comes to getting this code working.
> > >
> > > Let me know what your mileage is with the script below:
> > >
> > > Thanks!
> > >
> > >
> > These are basically the same staps as in the Quich Start. However, I
> > deleted my old copy of ZT, followed these instructions, verified that
> > ZF_Path is correct and I still get a lot of errors like:
> > Warning:
> >
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure):
> > failed to open stream: No such file or directory in /home/phpinc/ze
> > ndframework/Zend/Loader.php on line 138
> > Warning:
> >
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser):
> > failed to open stream: No such file or directory in /home/ph
> > pinc/zendframework/Zend/Loader.php on line 138
> > Warning: Zend_Loader::include(): Failed opening
> > '/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser' for
> > inclusion (include_path='/tmp/Zend_Too
> > l/bin/../library/:/home/phpinc/zendframework/') in
> > /home/phpinc/zendframework/Zend/Loader.php on line 138
> > ...
> > There are a total of 779 Warnings thrown when I execute
> > zf show version
> >
> > Any ideas?
> >
> > =C=
> >
>

 
    

 

Hi Ralph,

Going to try this out on my Ubuntu machine in a few minutes. I'm
dragging my Windows laptop around with me (clients and their MS
addiction) so I tried it out there first. I know you probably weren't
focusing on Windows immediately but it would be great to have it
working on all platforms.

It fails under Windows on a few areas. First of all it seems to use
Zend_Loader::loadFile() with absolute paths which won't work since
Windows absolute paths contain a colon ":" character which fails the
security checks - the loadFile() method was only ever intended for
loading ZF class files. When I bypass that problem I get:

Fatal error: Cannot redeclare class
ZendL_Controller_Tool_ActionProvider in
D:\projects\ztool\library\ZendL\Controlle\Tool\ActionProvider.php on
line 37

The other thing I observed was an attempt to load up at least one SVN
base file - this may be intentional though. I'm using it as an excuse
to dig around in the source code anyhow ;).

Back when I have linuxed up...

Paddy

--- In zf-tool@yahoogroups.com <mailto:zf-tool%40yahoogroups.com> , Ralph Schindler <ralph.schindler@...>
wrote:
>
>
> Hi all,
>
> Here is a little task just to see how easy it is for everyone to get the
> current code / prototype.  I have confirmed this works for me (as I have
> produced the script), but I want to make sure there are no pitfalls for
> anyone when it comes to getting this code working.
>
> Let me know what your mileage is with the script below:
>
> Thanks!
>
>
=========================================================================
>
>
> Getting the code
>
>     ~$ cd tmp/
>     ~/tmp$ svn export
> http://framework.zend.com/svn/framework/laboratory/Zend_Tool/
>
>
> Making a link to my zf.sh (I have ~/.bin/ in my path to look for
> executables)
>
>     ~$ ln -s ~/tmp/Zend_Tool/bin/zf.sh ~/.bin/zf
>     ~$ ls -la ~/.bin/zf
>     lrwxr-xr-x  1 ralphschindler  staff  45 Jul 16 23:39
> /Users/ralphschindler/.bin/zf ->
> /Users/ralphschindler/tmp/Zend_Tool/bin/zf.sh
>
>
> Lets try it!
>
>     ~$ which zf
>     /Users/ralphschindler/.bin/zf
>
>     ~$ zf show version
>     While in development: please set env var ZF_PATH to your copy of
zend
> framework.
>
>
> Lets set the Zf env variable as it asks (This needs to be a full path):
>
>     ~$ export
>
ZF_PATH="/Users/ralphschindler/Projects/code-zendframework/repo-standard/tru
> nk/library/"
>
>
> Ok, now things should work:
>
>     ~$ zf show version
>     Zend Framework Version: 1.5.2
>     
>     
> Errata - This is what my paths look like:
>
>     ~$ env | grep PATH
>     MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man
>     
>
ZF_PATH=/Users/ralphschindler/Projects/code-zendframework/repo-standard/trun
> k/library/
>     
>
PATH=/Users/ralphschindler/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
> :/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>
>
>
>
> --
> Ralph Schindler
> Software Engineer     | ralph.schindler@...
> Zend Framework        | http://framework.zend.com/
>

 
    

Hi Rob!

No, I checked that. It's PHP 5.3

=C=

http://sixtysecondtech.com ...think for a minute
http://blog.calevans.com

AIM:VirtualCIO
Skype:CalAtZend
Twitter:calevans



Rob Allen wrote:
>
>
> On 17 Jul 2008, at 14:05, Cal Evans wrote:
>
>> There are a total of 779 Warnings thrown when I execute
>> zf show version
>>
>> Any ideas?
>
>
> Is the incubator/another trunk on your php_include path? any prepend
> files being run? Is the trunk pointed to by ZF_PATH the latest svn
> version?
>
> Rob...
>

I have confirmed that the issue is PHP 5.3

When I downgrade, everything works fine.

=C=
--- In zf-tool@yahoogroups.com, "Cal Evans" <cal@...> wrote:
>
> Oh, Environment is:
> CentoOS with PHP 5.3
>
> =C=
>
> --- In zf-tool@yahoogroups.com, "Cal Evans" <cal@> wrote:
> >
> > --- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@>
> > wrote:
> > >
> > >
> > > Hi all,
> > >
> > > Here is a little task just to see how easy it is for everyone to
> get the
> > > current code / prototype.  I have confirmed this works for me (as
> I have
> > > produced the script), but I want to make sure there are no
> pitfalls for
> > > anyone when it comes to getting this code working.
> > >
> > > Let me know what your mileage is with the script below:
> > >
> > > Thanks!
> > >
> > >
> > These are basically the same staps as in the Quich Start. However, I
> > deleted my old copy of ZT, followed these instructions, verified that
> > ZF_Path is correct and I still get a lot of errors like:
> > Warning:
> >
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure):
> > failed to open stream: No such file or directory in /home/phpinc/ze
> > ndframework/Zend/Loader.php on line 138
> > Warning:
> >
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser)\
:
> > failed to open stream: No such file or directory in /home/ph
> > pinc/zendframework/Zend/Loader.php on line 138
> > Warning: Zend_Loader::include(): Failed opening
> > '/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser' for
> > inclusion (include_path='/tmp/Zend_Too
> > l/bin/../library/:/home/phpinc/zendframework/') in
> > /home/phpinc/zendframework/Zend/Loader.php on line 138
> > ...
> > There are a total of 779 Warnings thrown when I execute
> > zf show version
> >
> > Any ideas?
> >
> > =C=
> >
>

Oh, Environment is:
CentoOS with PHP 5.3

=C=

--- In zf-tool@yahoogroups.com, "Cal Evans" <cal@...> wrote:
>
> --- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@>
> wrote:
> >
> >
> > Hi all,
> >
> > Here is a little task just to see how easy it is for everyone to
get the
> > current code / prototype.  I have confirmed this works for me (as
I have
> > produced the script), but I want to make sure there are no
pitfalls for
> > anyone when it comes to getting this code working.
> >
> > Let me know what your mileage is with the script below:
> >
> > Thanks!
> >
> >
> These are basically the same staps as in the Quich Start. However, I
> deleted my old copy of ZT, followed these instructions, verified that
> ZF_Path is correct and I still get a lot of errors like:
> Warning:
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure):
> failed to open stream: No such file or directory in /home/phpinc/ze
> ndframework/Zend/Loader.php on line 138
> Warning:
>
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser)\
:
> failed to open stream: No such file or directory in /home/ph
> pinc/zendframework/Zend/Loader.php on line 138
> Warning: Zend_Loader::include(): Failed opening
> '/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser' for
> inclusion (include_path='/tmp/Zend_Too
> l/bin/../library/:/home/phpinc/zendframework/') in
> /home/phpinc/zendframework/Zend/Loader.php on line 138
> ...
> There are a total of 779 Warnings thrown when I execute
> zf show version
>
> Any ideas?
>
> =C=
>

--- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@...>
wrote:
>
>
> Hi all,
>
> Here is a little task just to see how easy it is for everyone to get the
> current code / prototype.  I have confirmed this works for me (as I have
> produced the script), but I want to make sure there are no pitfalls for
> anyone when it comes to getting this code working.
>
> Let me know what your mileage is with the script below:
>
> Thanks!
>
>
These are basically the same staps as in the Quich Start. However, I
deleted my old copy of ZT, followed these instructions, verified that
ZF_Path is correct and I still get a lot of errors like:
Warning:
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure):
failed to open stream: No such file or directory in /home/phpinc/ze
ndframework/Zend/Loader.php on line 138
Warning:
Zend_Loader::include(/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser)\
:
failed to open stream: No such file or directory in /home/ph
pinc/zendframework/Zend/Loader.php on line 138
Warning: Zend_Loader::include(): Failed opening
'/tmp/Zend_Tool/library/ZendL/Tool/Project/Structure/Parser' for
inclusion (include_path='/tmp/Zend_Too
l/bin/../library/:/home/phpinc/zendframework/') in
/home/phpinc/zendframework/Zend/Loader.php on line 138
...
There are a total of 779 Warnings thrown when I execute
zf show version

Any ideas?

=C=

-- Ralph Schindler <ralph.schindler@...> wrote
(on Wednesday, 16 July 2008, 11:49 PM -0500):
> Here is a little task just to see how easy it is for everyone to get the
> current code / prototype.  I have confirmed this works for me (as I have
> produced the script), but I want to make sure there are no pitfalls for
> anyone when it comes to getting this code working.
>
> Let me know what your mileage is with the script below:

Worked fine for me (ubuntu 8.04, ZF from current svn).

I also ran 'zf create project', which worked nicely as well. :)

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend Framework           | http://framework.zend.com/

Works fine on Ubuntu here. :)

--- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@...>
wrote:
>
>
> Hi all,
>
> Here is a little task just to see how easy it is for everyone to get the
> current code / prototype.  I have confirmed this works for me (as I have
> produced the script), but I want to make sure there are no pitfalls for
> anyone when it comes to getting this code working.
>
> Let me know what your mileage is with the script below:
>
> Thanks!
>
>
=========================================================================
>
>
> Getting the code
>
>     ~$ cd tmp/
>     ~/tmp$ svn export
> http://framework.zend.com/svn/framework/laboratory/Zend_Tool/
>
>
> Making a link to my zf.sh (I have ~/.bin/ in my path to look for
> executables)
>
>     ~$ ln -s ~/tmp/Zend_Tool/bin/zf.sh ~/.bin/zf
>     ~$ ls -la ~/.bin/zf
>     lrwxr-xr-x  1 ralphschindler  staff  45 Jul 16 23:39
> /Users/ralphschindler/.bin/zf ->
> /Users/ralphschindler/tmp/Zend_Tool/bin/zf.sh
>
>
> Lets try it!
>
>     ~$ which zf
>     /Users/ralphschindler/.bin/zf
>
>     ~$ zf show version
>     While in development: please set env var ZF_PATH to your copy of
zend
> framework.
>
>
> Lets set the Zf env variable as it asks (This needs to be a full path):
>
>     ~$ export
>
ZF_PATH="/Users/ralphschindler/Projects/code-zendframework/repo-standard/tru
> nk/library/"
>
>
> Ok, now things should work:
>
>     ~$ zf show version
>     Zend Framework Version: 1.5.2
>
>
> Errata - This is what my paths look like:
>
>     ~$ env | grep PATH
>     MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man
>
>
ZF_PATH=/Users/ralphschindler/Projects/code-zendframework/repo-standard/trun
> k/library/
>
>
PATH=/Users/ralphschindler/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
> :/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>
>
>
>
> --
> Ralph Schindler
> Software Engineer     | ralph.schindler@...
> Zend Framework        | http://framework.zend.com/
>

Hi Ralph,

Going to try this out on my Ubuntu machine in a few minutes. I'm
dragging my Windows laptop around with me (clients and their MS
addiction) so I tried it out there first. I know you probably weren't
focusing on Windows immediately but it would be great to have it
working on all platforms.

It fails under Windows on a few areas. First of all it seems to use
Zend_Loader::loadFile() with absolute paths which won't work since
Windows absolute paths contain a colon ":" character which fails the
security checks - the loadFile() method was only ever intended for
loading ZF class files. When I bypass that problem I get:

Fatal error: Cannot redeclare class
ZendL_Controller_Tool_ActionProvider in
D:\projects\ztool\library\ZendL\Controlle\Tool\ActionProvider.php on
line 37

The other thing I observed was an attempt to load up at least one SVN
base file - this may be intentional though. I'm using it as an excuse
to dig around in the source code anyhow ;).

Back when I have linuxed up...

Paddy

--- In zf-tool@yahoogroups.com, Ralph Schindler <ralph.schindler@...>
wrote:
>
>
> Hi all,
>
> Here is a little task just to see how easy it is for everyone to get the
> current code / prototype.  I have confirmed this works for me (as I have
> produced the script), but I want to make sure there are no pitfalls for
> anyone when it comes to getting this code working.
>
> Let me know what your mileage is with the script below:
>
> Thanks!
>
>
=========================================================================
>
>
> Getting the code
>
>     ~$ cd tmp/
>     ~/tmp$ svn export
> http://framework.zend.com/svn/framework/laboratory/Zend_Tool/
>
>
> Making a link to my zf.sh (I have ~/.bin/ in my path to look for
> executables)
>
>     ~$ ln -s ~/tmp/Zend_Tool/bin/zf.sh ~/.bin/zf
>     ~$ ls -la ~/.bin/zf
>     lrwxr-xr-x  1 ralphschindler  staff  45 Jul 16 23:39
> /Users/ralphschindler/.bin/zf ->
> /Users/ralphschindler/tmp/Zend_Tool/bin/zf.sh
>
>
> Lets try it!
>
>     ~$ which zf
>     /Users/ralphschindler/.bin/zf
>
>     ~$ zf show version
>     While in development: please set env var ZF_PATH to your copy of
zend
> framework.
>
>
> Lets set the Zf env variable as it asks (This needs to be a full path):
>
>     ~$ export
>
ZF_PATH="/Users/ralphschindler/Projects/code-zendframework/repo-standard/tru
> nk/library/"
>
>
> Ok, now things should work:
>
>     ~$ zf show version
>     Zend Framework Version: 1.5.2
>
>
> Errata - This is what my paths look like:
>
>     ~$ env | grep PATH
>     MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man
>
>
ZF_PATH=/Users/ralphschindler/Projects/code-zendframework/repo-standard/trun
> k/library/
>
>
PATH=/Users/ralphschindler/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
> :/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>
>
>
>
> --
> Ralph Schindler
> Software Engineer     | ralph.schindler@...
> Zend Framework        | http://framework.zend.com/
>

Hi all,

Here is a little task just to see how easy it is for everyone to get the
current code / prototype.  I have confirmed this works for me (as I have
produced the script), but I want to make sure there are no pitfalls for
anyone when it comes to getting this code working.

Let me know what your mileage is with the script below:

Thanks!

=========================================================================


Getting the code

     ~$ cd tmp/
     ~/tmp$ svn export
http://framework.zend.com/svn/framework/laboratory/Zend_Tool/


Making a link to my zf.sh (I have ~/.bin/ in my path to look for
executables)

     ~$ ln -s ~/tmp/Zend_Tool/bin/zf.sh ~/.bin/zf
     ~$ ls -la ~/.bin/zf
     lrwxr-xr-x  1 ralphschindler  staff  45 Jul 16 23:39
/Users/ralphschindler/.bin/zf ->
/Users/ralphschindler/tmp/Zend_Tool/bin/zf.sh


Lets try it!

     ~$ which zf
     /Users/ralphschindler/.bin/zf

     ~$ zf show version
     While in development: please set env var ZF_PATH to your copy of zend
framework.


Lets set the Zf env variable as it asks (This needs to be a full path):

     ~$ export
ZF_PATH="/Users/ralphschindler/Projects/code-zendframework/repo-standard/tru
nk/library/"


Ok, now things should work:

     ~$ zf show version
     Zend Framework Version: 1.5.2


Errata - This is what my paths look like:

     ~$ env | grep PATH
     MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man

ZF_PATH=/Users/ralphschindler/Projects/code-zendframework/repo-standard/trun
k/library/

PATH=/Users/ralphschindler/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin




--
Ralph Schindler
Software Engineer     | ralph.schindler@...
Zend Framework        | http://framework.zend.com/

--- In zf-tool@yahoogroups.com, Pádraic Brady <padraic.brady@...> wrote:

>
> I think that covers the whole list - I don't have anything else to add
> here.
>


One of the advantages of being slightly late to the party is that
Paddy has covered the stuff I thought of in a much more complete way
than I would have done!

Regards,


Rob...

Hi Ralph,

> > We can probably be more specific about what RAD refers to. The second
> > point seems to cover the gamut of possibilities for manipulating and
> > creating the primary app structures like
> > controllers/views/models/config/tests/etc. So once you remove those,
>
> Right, I feel like we will walk into this right after requirements
when we
> start talking about what resources are actually inside of any given
"project
> profile".  But ultimately, we are talking about management and
manipulation
> of any resources within a project to the fullest extent possible..

That last sentences pretty much sells it as is ;).

> This means adding controller files, modifying them to add new actions,
> creating model files, modifying them to include new
assessors/mutators when
> they are required, reading and writing config files, and so on and
so forth.
> Does that help?
>
> To me, rapid application is the ability to automate the repetitive tasks
> associated with starting a new project.

I understand, but be aware RAD has been around for so long, and
misused so often, it's often given a very broad definition. Don't mind
me though - I get picky over terminology at times.

> > what is left within the RAD umbrella for a command line tool to assist
> > with? Database migrations spring to mind as an obvious (and popular)
> > example. Isn't there a proposal for something like this in the wild?
>
> Yep,
>
http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Rob+A
> llen?showComments=false
>
> In fact when we get to it, I will throw out how I see that fitting
into this
> initiate and what (existing) code it will leverage.

Very cool!

> >> * Ability of the "tooling system" to describe its full set of
> > capabilities
> >
> > Similar point to how I started, its vague enough that it could just
> > mean "zf --help" - maybe it does mean just that.
>
> Correct

Overanalysing is another of my fortés...;)

> >> * Ability to attach metadata to "tooling capabilities (provider)"
> > and/or arbitrary "tooling" data to the system
> >
> > Needs to a bit more specific as to what is meant by attaching metadata
> > or tooling data. What is its purpose and likely effect? Is there a
> > simpler way of restating this requirement.
>
> This is a crucial one.  And, I am not sure I can simplify it any
further,
> but let me give you the for-instance.
>
> When talking about some capability of this tooling system, it should be
> known that it is called by some name.  In code, you might have a "class
> CustomAuthProvider {}".  This provider provides the "custom
authentication"
> related tasks/capabilities to the tooling system.  The system will
actually
> infer that this system capability is called "CustomAuth" from the
class name
> itself. (Lets not bog down in what this provider actually does, only
that it
> exists.)
>
> SO - considering that, there needs to be a way for the command line
> environment to get the name of this provider in a way which is
consistent to
> what is generally accepted in the command line environment.  That
said, the
> CLI part of the tooling system will create "metadata" for this
capability
> that makes it readable in the CLI environment (lowercase-dashed
instead of
> CamelCased).  This means that when you are referring to it from the
command
> line, you might use "custom-auth" instead of "CustomAuth", thus a more
> consistent experience.

I wouldn't worry about oversimplifying - the above makes is very clear
what direction you mean.

I think that covers the whole list - I don't have anything else to add
here.

Paddy

They all made sense, and we'll probably jump all over them once
Ralph's list has been pecked to death ;).

--- In zf-tool@yahoogroups.com, "Tim Fountain" <lists@...> wrote:
>
> As (hopefully) a future user of this toolset, here are some real world
> examples of what I would like to use some of the features mentioned
for. To
> give a brief background, my app is a modular CMS where one
installation is
> used by multiple websites.
>
> Firstly some things for development convenience:
>
> * Generating 'skeleton' structure for new modules (zf create module
--name
> news) - would create directory structure and some initial class
files based
> on my predefined module layout
>
> * Installation of an existing module onto a site - this would be a
custom
> task I'd write for my particular app, it would have to grab an SQL
file from
> the relevant module directory and run (creating the required database
> tables)
>
> * Configuration check - another custom one for my app, would do a
quick scan
> of some predefined XML files to make sure the XML is parseable
(think along
> the lines of the linux command 'apache2ctl configtest')
>
>
> Some other things hinted at which I think would be extremely useful
for ZF
> development in general:
>
> * Database migrations - either by calling methods on the proposed
> Zend_Db_Schema_Manager component, or through something Zend_Tool_*
itself
>
> * Generating skeleton structure for a new app - i.e. the equivalent of
> running 'rails myapp' in RoR. Looks like you have this already since
there's
> an example of it in the Zend_Tool quickstart.
>
>
> Some other areas that weren't mentioned but perhaps could be
considered for
> the (long term) future:
>
> * Deployments - currently I use capistrano (www.capify.org), which
is very
> good, but since it's designed for Rails apps, takes a little
fiddling to get
> working with PHP ones.
>
> * Auto-updating of applications or components - e.g. connecting to a
> predefined source control repo using some supplied credentials, download
> newest version if available, run tests and then if successful apply to
> existing codebase
>
> * Installation of third party plugins - sorry to use Rails as an example
> again, but in Rails you can run: ./script/install <URL to public
repo> which
> will download a mini-app into the 'plugins' directory of your
application
>
> * Managing environment dependencies - e.g. imagine if your application
> required particular min. versions of PHP and the GD library, it would be
> nice if you could define these in such a way that users could
download your
> app and run one command to see whether their server had all of the
necessary
> bits installed.
>
>
> I hope I'm not too far off base with these!
>
>
> --
> Tim Fountain
> http://www.tfountain.co.uk/
>

>> * Ability to issue "tooling system" requests via the command line to
> facilitate:
>>     * rapid application development of php based applications
>>     * jump starting application structures with include the creation
> and alteration of
>>         * directories
>>         * files (classes, html, view scripts, etc.)
>>         * database schemas
>>         * config files
>>         * xml files
>>         * wsdl generation
>
> We can probably be more specific about what RAD refers to. The second
> point seems to cover the gamut of possibilities for manipulating and
> creating the primary app structures like
> controllers/views/models/config/tests/etc. So once you remove those,

Right, I feel like we will walk into this right after requirements when we
start talking about what resources are actually inside of any given "project
profile".  But ultimately, we are talking about management and manipulation
of any resources within a project to the fullest extent possible..

This means adding controller files, modifying them to add new actions,
creating model files, modifying them to include new assessors/mutators when
they are required, reading and writing config files, and so on and so forth.
Does that help?

To me, rapid application is the ability to automate the repetitive tasks
associated with starting a new project.

> what is left within the RAD umbrella for a command line tool to assist
> with? Database migrations spring to mind as an obvious (and popular)
> example. Isn't there a proposal for something like this in the wild?

Yep,
http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Rob+A
llen?showComments=false

In fact when we get to it, I will throw out how I see that fitting into this
initiate and what (existing) code it will leverage.

>> * Ability of the "tooling system" to describe its full set of
> capabilities
>
> Similar point to how I started, its vague enough that it could just
> mean "zf --help" - maybe it does mean just that.

Correct


>> * Ability to attach metadata to "tooling capabilities (provider)"
> and/or arbitrary "tooling" data to the system
>
> Needs to a bit more specific as to what is meant by attaching metadata
> or tooling data. What is its purpose and likely effect? Is there a
> simpler way of restating this requirement.

This is a crucial one.  And, I am not sure I can simplify it any further,
but let me give you the for-instance.

When talking about some capability of this tooling system, it should be
known that it is called by some name.  In code, you might have a "class
CustomAuthProvider {}".  This provider provides the "custom authentication"
related tasks/capabilities to the tooling system.  The system will actually
infer that this system capability is called "CustomAuth" from the class name
itself. (Lets not bog down in what this provider actually does, only that it
exists.)

SO - considering that, there needs to be a way for the command line
environment to get the name of this provider in a way which is consistent to
what is generally accepted in the command line environment.  That said, the
CLI part of the tooling system will create "metadata" for this capability
that makes it readable in the CLI environment (lowercase-dashed instead of
CamelCased).  This means that when you are referring to it from the command
line, you might use "custom-auth" instead of "CustomAuth", thus a more
consistent experience.

That's a pretty gross simplification of the idea, but lets take it a step
further.  The Zend Studio guys create a set of icons for all of the tooling
providers that make sense for Zend Studio to support.  This icons would be
accessible (via the tooling system) to other IDE's to utilize (if they so
wish), and can be found inside the registry of metadata that has been built.
Its even conceivable that these icons end up on a web interface to this
tooling system.

Lemme know if I need to come up with other for instances, like I said, this
concept might be one of the harder ones to define without examples.



> I think we can almost drop the references to RAD - not all developers
> will adopt any variety of RAD approach and the command line tooling,
> while useful, is only one small part of a possible RAD process. Rest
> of the points are fine.

Understood, but its important to note that a large portion of this
initiative is to be able to read and write code (this might include apache
configuration files, Zend_Config files, Zend Search Lucene Indexes, WSDL
files, Database Migrations, and so on.  I am sure there are other
"maintenance" like tasks that could be accomplished and exposed by this
tooling system.


--
Ralph Schindler
Software Engineer     | ralph.schindler@...
Zend Framework        | http://framework.zend.com/

> Flexibility would be crucial to the tooling set. It should be very easy to
> make it generate a Zym controller action instead of a Zend controller action
> for example. This flexibility should be complemented by great OOTB support for
> common use cases. It should be possible to generate a Hello World app directly
> after unpacking a freshly downloaded ZF tar-ball.

Actually, I think today I will have produced a script into how to SEE the
code working to produce a "hello world" app.  This would basically include
both the methods for checking out from subversion, and then moving onto
executing the actual commands.  I'll keep you posted.

> Your many hours into defining and prototyping have definitely payed off. This
> is already looking very good and I think it's just a matter of (to roughly
> translate a Dutch saying) "to put the dot on the i".

Thanks!

--
Ralph Schindler
Software Engineer     | ralph.schindler@...
Zend Framework        | http://framework.zend.com/

I think we also need to partner each requirement with one or more
specific reasons to explain why it's a requirement. Take for example
the second requirement "describe its full set of capabilities". One
could assume this is a reference to what happens when you run "zf
--help" and a mini manual pops out or it could mean something else
entirely. I usually end up pretending all requirements without an
attached reason or specifics end with the phrase "for the purpose of"
and fill in what fits best thereafter.

  I'll comment point by point below, it's a good list.

> * Ability to issue "tooling system" requests via the command line to
facilitate:
>     * rapid application development of php based applications
>     * jump starting application structures with include the creation
and alteration of
>         * directories
>         * files (classes, html, view scripts, etc.)
>         * database schemas
>         * config files
>         * xml files
>         * wsdl generation

We can probably be more specific about what RAD refers to. The second
point seems to cover the gamut of possibilities for manipulating and
creating the primary app structures like
controllers/views/models/config/tests/etc. So once you remove those,
what is left within the RAD umbrella for a command line tool to assist
with? Database migrations spring to mind as an obvious (and popular)
example. Isn't there a proposal for something like this in the wild?

> * Ability of the "tooling system" to describe its full set of
capabilities

Similar point to how I started, its vague enough that it could just
mean "zf --help" - maybe it does mean just that.

> * Ability to issue "tooling system" requests from multiple clients
to interact with this "tooling system"
>     * Zend Studio
>     * Command Line
>     * Other IDE (example: textmate via perhaps XML-RPC)

No problems here.

> * Ability to extend the "tooling system" as simply as creating a php
class.

No problems here.

> * Ability to attach metadata to "tooling capabilities (provider)"
and/or arbitrary "tooling" data to the system

Needs to a bit more specific as to what is meant by attaching metadata
or tooling data. What is its purpose and likely effect? Is there a
simpler way of restating this requirement.

> * Ability for this "tooling system" to be bootstrapped automatically
by detecting "capabilities" inside the php include-path.

Works for me.

> * Ability to customize and use a "project profiling" system to
facilitate:
>     * defining project structures to be used in rapid application
development
>     * ability to serialize a "live" project profile inside a project
>     * ability to keep project "artifacts" and the project profile in
synchronization
> * Ability to construct php based files, classes, methods, properties
via an OO interface
> * Ability to deconstruct and alter the contents of existing PHP
files and classes

I think we can almost drop the references to RAD - not all developers
will adopt any variety of RAD approach and the command line tooling,
while useful, is only one small part of a possible RAD process. Rest
of the points are fine.

Hey all,

Thanks for signing up on this list.  As you can tell, we are in dire
need to get the community on board and with understanding of what I
like to call the "Tooling Initiative".  So, since we have a relatively
small but focused group assembled with a tight communication channel,
I propose we start off at the top.

What are the requirements of this initiative?

It goes without saying that the framework devteam and myself have put
many hours into defining and prototyping, so let me start off this
discussion with what I think our list might contain.

So to start:


* Ability to issue "tooling system" requests via the command line to
facilitate:
     * rapid application development of php based applications
     * jump starting application structures with include the creation
and alteration of
         * directories
         * files (classes, html, view scripts, etc.)
         * database schemas
         * config files
         * xml files
         * wsdl generation
         * etc.

* Ability of the "tooling system" to describe its full set of capabilities

* Ability to issue "tooling system" requests from multiple clients to
interact with this "tooling system"
     * Zend Studio
     * Command Line
     * Other IDE (example: textmate via perhaps XML-RPC)

* Ability to extend the "tooling system" as simply as creating a php
class.

* Ability to attach metadata to "tooling capabilities (provider)"
and/or arbitrary "tooling" data to the system

* Ability for this "tooling system" to be bootstrapped automatically
by detecting "capabilities" inside the php include-path.

* Ability to customize and use a "project profiling" system to facilitate:
     * defining project structures to be used in rapid application
development
     * ability to serialize a "live" project profile inside a project
     * ability to keep project "artifacts" and the project profile in
synchronization

* Ability to construct php based files, classes, methods, properties
via an OO interface

* Ability to deconstruct and alter the contents of existing PHP files
and classes


Please let me know what you guys think of the above list, and let me
know if this overall list of requirements is in line with what you are
expecting.

Thanks,
Ralph