[fw-general] Zend_Navigation menu links rendering bug?

[jiewmeng]

i am having this scenario where when i goto a url like /posts/add, my menu
items will all render posts/add. when i goto /posts its all right


my  http://pastebin.com/RfAfxkwE nav config 


-- 
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/Zend-Navigation-menu-links-rendering-bug-tp2316966p2316966.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: Fwd: Re: [fw-general] Zend Framework 2.0.0dev1 Release

[Matthew Weier O'Phinney]

-- Mike A  wrote
(on Friday, 06 August 2010, 08:35 PM +0100):
> Documentation availability/plans?

(Evidently you CC'd me, so pardon the two replies.)

Documentation will come at a later date, for a variety of reasons.

First, this is a development snapshot -- a very, very early sneak peek
at ZF2. So early, in fact, that it doesn't really look like what ZF2
will likely look like when stable. It's really a 1:1 port of ZF1 to
namespaces, with some minor refactoring. As it is, most code from ZF1
will work simply by migrating it to namespaces.

Second, if you read the "Milestones" document, one milestone is
documentation. We plan a documentation re-organization, with two goals:
making the documentation more predictable and thorough, and establishing
a clear baseline of documentation for contributors. This will have to
come after components have been refactored, however.

Finally, if you have played with PHP 5.3 at all, one area of
documentation that's lacking is a good API documentation generator that
understands namespaces. There are a few in the works right now, and
we're still evaluating what we will use.

> On 06/08/2010 20:24, Matthew Weier O'Phinney wrote:
> > Yesterday, the Zend Framework team tagged the first development
> > milestone of Zend Framework 2.0 (2.0.0dev1). It is immediately
> > downloadable from the Zend Framework servers:
> >
> >   * Zip package:
> > 
> > http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.zip
> >
> >   * tar.gz package:
> > 
> > http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.tar.gz
> >
> > NOTE! This release is not considered of production quality, and is
> > released solely to provide a development snapshot for purposes of
> > testing and research. Use at your own risk.
> >
> > This release is the culmination of several months of work, and
> > incorporates the following features:
> >
> >   * Removal of all require_once statements.
> >   * Migration to namespaces.
> >   * Refactoring of the test suite, including:
> >   * Removal of all "AllTests.php" files.
> >   * Removal of unreferenced test classes.
> >   * Limited refactoring to move helper classes into their own files.
> >   * Refactoring of conditional tests.
> >   * Rewrite of Zend\Session from the ground up. This required creation of
> > a new component, Zend\SignalSlot, for handling observers and creating
> > filter chains.
> >   * Addition of a new Zend\Stdlib namespace for interfaces and utility
> > classes; in particular, we added extensions to SplQueue, SplStack,
> > and SplPriorityQueue to create serializable versions of these
> > classes.
> >
> > We have done some "real-world" testing of the release by building the
> > Quick Start application, as well as migrating an existing demo
> > application to ZF2. We were able to achieve both goals, demonstrating
> > that while the release is certainly pre-alpha, it is definitely
> > functional.
> >
> > There is much work yet to be done. Today, we published a rough roadmap
> > of milestones we will be working towards (1). This roadmap only
> > addresses components with cross-cutting concerns, but serves as a guide
> > for development in the coming months. If you are interested in
> > contributing, be sure to sign our Contributors License Agreement (CLA),
> > and read the "README-DEV.txt" file in the release. We also suggest you
> > join the zf-contributors mailing list (2), and join in discussions on
> > the #zftalk.dev IRC channel on Freenode.
> >
> > [1] 
> > http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
> > [2] 
> > http://zend-framework-community.634137.n4.nabble.com/ZF-Contributor-f680267.html
> >
> >
> 
> 

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

Fwd: Re: [fw-general] Zend Framework 2.0.0dev1 Release

[Mike A]

Documentation availability/plans?

On 06/08/2010 20:24, Matthew Weier O'Phinney wrote:

 Yesterday, the Zend Framework team tagged the first development
 milestone of Zend Framework 2.0 (2.0.0dev1). It is immediately
 downloadable from the Zend Framework servers:

   * Zip package:
 
http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.zip

   * tar.gz package:
 
http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.tar.gz

 NOTE! This release is not considered of production quality, and is
 released solely to provide a development snapshot for purposes of
 testing and research. Use at your own risk.

 This release is the culmination of several months of work, and
 incorporates the following features:

   * Removal of all require_once statements.
   * Migration to namespaces.
   * Refactoring of the test suite, including:
   * Removal of all "AllTests.php" files.
   * Removal of unreferenced test classes.
   * Limited refactoring to move helper classes into their own files.
   * Refactoring of conditional tests.
   * Rewrite of Zend\Session from the ground up. This required creation of
 a new component, Zend\SignalSlot, for handling observers and creating
 filter chains.
   * Addition of a new Zend\Stdlib namespace for interfaces and utility
 classes; in particular, we added extensions to SplQueue, SplStack,
 and SplPriorityQueue to create serializable versions of these
 classes.

 We have done some "real-world" testing of the release by building the
 Quick Start application, as well as migrating an existing demo
 application to ZF2. We were able to achieve both goals, demonstrating
 that while the release is certainly pre-alpha, it is definitely
 functional.

 There is much work yet to be done. Today, we published a rough roadmap
 of milestones we will be working towards (1). This roadmap only
 addresses components with cross-cutting concerns, but serves as a guide
 for development in the coming months. If you are interested in
 contributing, be sure to sign our Contributors License Agreement (CLA),
 and read the "README-DEV.txt" file in the release. We also suggest you
 join the zf-contributors mailing list (2), and join in discussions on
 the #zftalk.dev IRC channel on Freenode.

 [1] http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
 [2] 
http://zend-framework-community.634137.n4.nabble.com/ZF-Contributor-f680267.html

[fw-general] Re: setDestination in Zend_Form_Element_File

[ukanga]

I think you need to invovle Zend_File_Transfer somewhere. Could you check
this blog post
http://ahsangill.wordpress.com/2009/02/17/zend-framework-file-upload-using-zend_form_element_file/,
it helped me out when I had to do a file upload.

Regards,
Ukang'a Dickson


On Fri, Aug 6, 2010 at 9:19 PM, zensys [via Zend Framework Community] <
ml-node+2316644-354392398-98...@n4.nabble.com
> wrote:

> I try to upload a file to a directory using setDestination but the file
> ends op in /tmp, whatever I try. Here's my code:
>
> class forms_ImportForm extends Zend_Form {
>
>  public function __construct($options = null) {
>   parent::__construct($options);
>   $this->setName('import');
>
>   $uploadFile = new Zend_Form_Element_File('extract');
>   $uploadFile->setLabel('File') ->setDestination(APPLICATION_PATH
> ."/../data");
>
>   $submit = new Zend_Form_Element_Submit('submit');
>   $submit->setLabel('Uploaden');
>
>   $this->addElements(array($uploadFile, $submit));
> }
> }
>
> The method is called because the label is displayed and if I mutilate the
> file location I get an error. Any suggestions greatly appreciated.
>
> Timmo
>
>
>
> --
>  View message @
> http://zend-framework-community.634137.n4.nabble.com/setDestination-in-Zend-Form-Element-File-tp2316644p2316644.html
> To unsubscribe from Zend Framework Community, click 
> here.
>
>
>

-- 
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/setDestination-in-Zend-Form-Element-File-tp2316644p2316653.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Team Development

[Jason Austin]

svn:externals saved our butts on a lot of that.  We setup ZF as externals in
our projects so every time a new instance of the project is checked out, the
ZF library is local to the product in the htdocs folder.  I realize lots of
people like using a central ZF library, but keeping them as externals is the
best way to keep your application dependencies on ZF (and any other library)
in your repo.  We also support about 30 applications, so its not feasible
for all of those to use the same ZF library or all we would ever do is
update applications to use a new version of the framework.

- Jason

On Fri, Aug 6, 2010 at 2:14 PM, Paul  wrote:

>  Well Tortoise Subversion is just a svn client.  I have that all sorted.
> The issue is where are the local copies stored.  Centralized dev server or
> each developer local machine.  Wanted to see most organizations do, and some
> best practices.
>
>
> On 8/6/2010 1:51 PM, Deborah Dalcin wrote:
>
> Should also check out tortoise subversion.  It's not without it's problems,
> but it's a pretty solid tool.
>
> On Fri, Aug 6, 2010 at 12:18 PM, Paul  wrote:
>
>> We currently use PHING, I have heard of Apache Maven, will look into this.
>>
>> On 8/6/2010 12:00 PM, Hector Virgen wrote:
>>
>>> Apache Maven
>>>
>>
>
>
> --
> www.pseudoworlds.gibbserv.net/mms
> www.killk.gibbserv.net
>
>


-- 
Jason Austin
Senior Solutions Implementation Engineer
NCSU - OIT - Outreach Technology
jason_aus...@ncsu.edu

[fw-general] setDestination in Zend_Form_Element_File

[zensys]

I try to upload a file to a directory using setDestination but the file ends
op in /tmp, whatever I try. Here's my code:

class forms_ImportForm extends Zend_Form {

 public function __construct($options = null) {
  parent::__construct($options);
  $this->setName('import');

  $uploadFile = new Zend_Form_Element_File('extract');
  $uploadFile->setLabel('File') ->setDestination(APPLICATION_PATH
."/../data");

  $submit = new Zend_Form_Element_Submit('submit');
  $submit->setLabel('Uploaden');
 
  $this->addElements(array($uploadFile, $submit));
}
}

The method is called because the label is displayed and if I mutilate the
file location I get an error. Any suggestions greatly appreciated.

Timmo


-- 
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/setDestination-in-Zend-Form-Element-File-tp2316644p2316644.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Team Development

[Jason Austin]

We worked in the single-dev-server environment for a long time, but in the
last year have moved to our own local development stacks.  So far, that has
worked out a lot better and is far less error prone.

The biggest problem that we have had is just the minor nuances that come
with developing on an os-x lamp stack and deploying on a linux lamp stack,
but those are usually not a big issue.  We run Zend Server CE on the local
boxes and have found that to be very good as an all-in-one install.  Also it
forced our devs to be a little more familiar with apache configuration and
setup, so that was a learning challenge at first.

Hope that helps,
Jason

On Fri, Aug 6, 2010 at 11:22 AM, Paul  wrote:

> I was wondering if anyone had some good resources on the topic of working
> on a project with a team of php developers.  In particular looking at the
> local setup for a developer.  Should each developer have their own LAMP
> instance (probably using a VM)?  Or is it better to have one centralized dev
> server, where each developer has their own user, and their local copies are
> on that machine, and they connect either through samba, ftp, etc.
>
> Surprisingly there is not much on team development, and instead on how one
> developer can setup their own development on their local machine.
>
> Being a freelancer for the past few years, and then previously working with
> a company who used their own proprietary language/environment, I would love
> to know how other php shops developing enterprise web application (using ZF
> of course :)) manage this.
>
> What are some guidelines, best practices, etc.  I am looking to the ZF
> community because I feel the standards here are high, and part of the point
> of ZF is how to build php projects the right way, or at least in way that
> helps promote best practices.  Just compare the code from Wordpress to ZF:)
>
> Cheers,
> Paul
>



-- 
Jason Austin
Senior Solutions Implementation Engineer
NCSU - OIT - Outreach Technology
jason_aus...@ncsu.edu

Re: [fw-general] Team Development

[Matthew Weier O'Phinney]

-- Paul  wrote
(on Friday, 06 August 2010, 02:59 PM -0400):
> Thanks!  That will makes our lives easier, as we are in the process
> of moving towards 5.3 (getting ready for ZF2!).
> 
> So you recommend going with each developer having his/her own local
> stack rather than central dev server?
> 
> Do you recommend VM for this to keep the environments similar?

The teams I've worked on have all managed their own local development
stacks. 

That said, I also have some colleagues and friends who work on teams
that use VM environments, and swear by it. The nice part of having a VM
environment is that one person can be tasked with its creation and
documentation, and then each person simply grabs an image and uses it.
In the end, however, they still need to push code to it, and each
person's VM image will vary after time.

> On 8/6/2010 2:23 PM, Matthew Weier O'Phinney wrote:
> >-- Paul  wrote
> >(on Friday, 06 August 2010, 12:15 PM -0400):
> >
> >>Can you run two instances of Zend Server CE, one w/ php5.2 the other with
> >>php5.3?
> >
> >
> >Yes. Zend Server has FastCGI enabled, so you can have mod_php with one
> >version of PHP, and create FastCGI vhosts for running projects on other
> >versions of PHP. The steps are relatively easy:
> >
> >  * In your vhost, you add a few lines:
> >
> > ScriptAlias /cgi-bin/ /path/to/zfproject/public/cgi-bin/
> > AddHandler php-fcgi .php
> > Action php-fcgi /cgi-bin/php-5.3.1
> >
> >  * Create a "cgi-bin" directory under your "public" directory
> >
> >  * Create a script named "php-5.3.1" (or whatever you want -- just needs
> >to be whatever you put in your vhost definition), and have it execute
> >the php-cgi binary:
> >
> > #!/bin/bash
> > exec /path/to/php/install/bin/php-cgi "$@"
> >
> >Because it's a CLI/CGI version of PHP, you can pass additional
> >arguments to it as well -- which is useful for setting things like
> >the include_path, etc.
> >
> >Make sure the script is executable.
> >
> >  * On Zend Server on my ubuntu install, I had to do a few things to
> >enable FastCGI:
> >
> >% cd /etc/apache2/mods-enabled
> >% sudo ln -s ../mods-available/fastcgi.load .
> >% sudo ln -s ../mods-available/fastcgi.conf .
> >% sudo ln -s ../mods-available/actions.load .
> >% sudo ln -s ../mods-available/actions.conf .
> >
> >Then restart your server, and you should be set.
> >
> 

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

[fw-general] Zend Framework 2.0.0dev1 Release

[Matthew Weier O'Phinney]

Yesterday, the Zend Framework team tagged the first development
milestone of Zend Framework 2.0 (2.0.0dev1). It is immediately
downloadable from the Zend Framework servers:

 * Zip package:
   
http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.zip

 * tar.gz package:
   
http://framework.zend.com/releases/ZendFramework-2.0.0dev1/ZendFramework-2.0.0dev1.tar.gz

NOTE! This release is not considered of production quality, and is
released solely to provide a development snapshot for purposes of
testing and research. Use at your own risk.

This release is the culmination of several months of work, and
incorporates the following features: 

 * Removal of all require_once statements.
 * Migration to namespaces.
 * Refactoring of the test suite, including:
 * Removal of all "AllTests.php" files.
 * Removal of unreferenced test classes.
 * Limited refactoring to move helper classes into their own files.
 * Refactoring of conditional tests.
 * Rewrite of Zend\Session from the ground up. This required creation of
   a new component, Zend\SignalSlot, for handling observers and creating
   filter chains.
 * Addition of a new Zend\Stdlib namespace for interfaces and utility
   classes; in particular, we added extensions to SplQueue, SplStack,
   and SplPriorityQueue to create serializable versions of these
   classes.

We have done some "real-world" testing of the release by building the
Quick Start application, as well as migrating an existing demo
application to ZF2. We were able to achieve both goals, demonstrating
that while the release is certainly pre-alpha, it is definitely
functional.

There is much work yet to be done. Today, we published a rough roadmap
of milestones we will be working towards (1). This roadmap only
addresses components with cross-cutting concerns, but serves as a guide
for development in the coming months. If you are interested in
contributing, be sure to sign our Contributors License Agreement (CLA),
and read the "README-DEV.txt" file in the release. We also suggest you
join the zf-contributors mailing list (2), and join in discussions on
the #zftalk.dev IRC channel on Freenode.

[1] http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
[2] 
http://zend-framework-community.634137.n4.nabble.com/ZF-Contributor-f680267.html

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

Re: [fw-general] Team Development

[Paul]

On 8/6/2010 2:57 PM, Mike A wrote:

On 06/08/2010 19:14, Paul wrote:
Well Tortoise Subversion is just a svn client.  I have that all 
sorted.  The issue is where are the local copies stored.  Centralized 
dev server or each developer local machine.  Wanted to see most 
organizations do, and some best practices.


On 8/6/2010 1:51 PM, Deborah Dalcin wrote:
Should also check out tortoise subversion.  It's not without it's 
problems, but it's a pretty solid tool.


On Fri, Aug 6, 2010 at 12:18 PM, Paul > wrote:


We currently use PHING, I have heard of Apache Maven, will look
into this.

On 8/6/2010 12:00 PM, Hector Virgen wrote:

Apache Maven




--
www.pseudoworlds.gibbserv.net/mms 


www.killk.gibbserv.net 

FWIW I've been preparing a chapter about the various tools and methods 
for team development.


It comes down to this: keep all files on a central repository and have 
developers check out, modify and check back in. Developers tend to 
prefer their own "ways" of storing files locally but my view is they 
should mimic the central repository: retain a mirror of it. This 
avoids confusion and also assists managing of trunk, pre-release and  
release file/package versions.


To explain how development teams can mirror a common system I've used 
the acronym MILDRED (Managed Integrated Laboratory for Research 
Evolution and Development). I shall release a draft as soon as I can 
because I've had various developers (unconnected with ZF) asking for 
detail of setting up the various parts of a MILDRED (only for Win 
machines with Apache ATM but intended to grow for wider use). 
Unfortunately I've been delayed through pressure by projects. I could 
send the OP a somewhat broken draft if wanted, perhaps get some 
feedback in return.




Sure send my way, would love to check it out.

Re: [fw-general] Team Development

[Paul]

Very cool.   Agree Jason, we should blog about these experiences.  So 
surprised there is not more online about this.  Anytime I find anything 
it is so Java-centric.  I think it's so important for the PHP community 
to have our own perspective and identity.  I don't want us to follow all 
of Java's techniques and setups, because the two languages are really 
two different animals.


On 8/6/2010 3:02 PM, Jason Austin wrote:
Keeping everyone on the same system is WAY easier.  VM's are a great 
way to make that happen, so I would definitely say try it out.  Our 
team is relatively small (1 manager, 2 developers, 2 part-time 
developers) so we just keep everyone on Apple hardware and don't have 
a problem.


Given that there is not a lot of info on this, I'd suggest blogging 
your experience once you decide what to do.  It may help somebody else 
out in the future.  Heck, maybe I should do that too :)


- Jason

On Fri, Aug 6, 2010 at 2:54 PM, Paul > wrote:


Agree Jason.  We in fact already do that at my shop.   Not
everything is an svn repository though, so that becomes an issue. 
We are using PHING to build are web apps and deploy to stagin and

production.  So we might add targets for update dependencies,
which would make sure things outside of svn can be
imported/removed/etc.

Where it gets a headache for me is when it comes to the server
itself or operating system, which is why I am leaning towards each
developer having a vm, so we can all run the same os, version,
etc.  Then when we need to install an extension, the same steps
should work for the whole team, we could even write scripts to
automate, and put that in the phing target.

Just want to see what the community does, before I start over
thinking this.


On 8/6/2010 2:24 PM, Jason Austin wrote:

svn:externals saved our butts on a lot of that.  We setup ZF as
externals in our projects so every time a new instance of the
project is checked out, the ZF library is local to the product in
the htdocs folder.  I realize lots of people like using a central
ZF library, but keeping them as externals is the best way to keep
your application dependencies on ZF (and any other library) in
your repo.  We also support about 30 applications, so its not
feasible for all of those to use the same ZF library or all we
would ever do is update applications to use a new version of the
framework.

- Jason

On Fri, Aug 6, 2010 at 2:14 PM, Paul mailto:z...@zooluserver.com>> wrote:

Well Tortoise Subversion is just a svn client.  I have that
all sorted.  The issue is where are the local copies stored. 
Centralized dev server or each developer local machine. 
Wanted to see most organizations do, and some best practices.



On 8/6/2010 1:51 PM, Deborah Dalcin wrote:

Should also check out tortoise subversion.  It's not without
it's problems, but it's a pretty solid tool.

On Fri, Aug 6, 2010 at 12:18 PM, Paul mailto:z...@zooluserver.com>> wrote:

We currently use PHING, I have heard of Apache Maven,
will look into this.

On 8/6/2010 12:00 PM, Hector Virgen wrote:

Apache Maven




-- 
www.pseudoworlds.gibbserv.net/mms


www.killk.gibbserv.net 





-- 
Jason Austin

Senior Solutions Implementation Engineer
NCSU - OIT - Outreach Technology
jason_aus...@ncsu.edu 





--
Jason Austin
Senior Solutions Implementation Engineer
NCSU - OIT - Outreach Technology
jason_aus...@ncsu.edu 

Re: [fw-general] Team Development

[Mike A]

On 06/08/2010 19:14, Paul wrote:
Well Tortoise Subversion is just a svn client.  I have that all 
sorted.  The issue is where are the local copies stored.  Centralized 
dev server or each developer local machine.  Wanted to see most 
organizations do, and some best practices.


On 8/6/2010 1:51 PM, Deborah Dalcin wrote:
Should also check out tortoise subversion.  It's not without it's 
problems, but it's a pretty solid tool.


On Fri, Aug 6, 2010 at 12:18 PM, Paul > wrote:


We currently use PHING, I have heard of Apache Maven, will look
into this.

On 8/6/2010 12:00 PM, Hector Virgen wrote:

Apache Maven




--
www.pseudoworlds.gibbserv.net/mms 


www.killk.gibbserv.net 

FWIW I've been preparing a chapter about the various tools and methods 
for team development.


It comes down to this: keep all files on a central repository and have 
developers check out, modify and check back in. Developers tend to 
prefer their own "ways" of storing files locally but my view is they 
should mimic the central repository: retain a mirror of it. This avoids 
confusion and also assists managing of trunk, pre-release and  release 
file/package versions.


To explain how development teams can mirror a common system I've used 
the acronym MILDRED (Managed Integrated Laboratory for Research 
Evolution and Development). I shall release a draft as soon as I can 
because I've had various developers (unconnected with ZF) asking for 
detail of setting up the various parts of a MILDRED (only for Win 
machines with Apache ATM but intended to grow for wider use). 
Unfortunately I've been delayed through pressure by projects. I could 
send the OP a somewhat broken draft if wanted, perhaps get some feedback 
in return.

Re: [fw-general] Team Development

[Paul]

Thanks!  That will makes our lives easier, as we are in the process of 
moving towards 5.3 (getting ready for ZF2!).


So you recommend going with each developer having his/her own local 
stack rather than central dev server?


Do you recommend VM for this to keep the environments similar?

On 8/6/2010 2:23 PM, Matthew Weier O'Phinney wrote:

-- Paul  wrote
(on Friday, 06 August 2010, 12:15 PM -0400):

   

Can you run two instances of Zend Server CE, one w/ php5.2 the other with
php5.3?
 



Yes. Zend Server has FastCGI enabled, so you can have mod_php with one
version of PHP, and create FastCGI vhosts for running projects on other
versions of PHP. The steps are relatively easy:

  * In your vhost, you add a few lines:

 ScriptAlias /cgi-bin/ /path/to/zfproject/public/cgi-bin/
 AddHandler php-fcgi .php
 Action php-fcgi /cgi-bin/php-5.3.1

  * Create a "cgi-bin" directory under your "public" directory

  * Create a script named "php-5.3.1" (or whatever you want -- just needs
to be whatever you put in your vhost definition), and have it execute
the php-cgi binary:

 #!/bin/bash
 exec /path/to/php/install/bin/php-cgi "$@"

Because it's a CLI/CGI version of PHP, you can pass additional
arguments to it as well -- which is useful for setting things like
the include_path, etc.

Make sure the script is executable.

  * On Zend Server on my ubuntu install, I had to do a few things to
enable FastCGI:

% cd /etc/apache2/mods-enabled
% sudo ln -s ../mods-available/fastcgi.load .
% sudo ln -s ../mods-available/fastcgi.conf .
% sudo ln -s ../mods-available/actions.load .
% sudo ln -s ../mods-available/actions.conf .

Then restart your server, and you should be set.

   

Re: [fw-general] Team Development

[Matthew Weier O'Phinney]

-- Paul  wrote
(on Friday, 06 August 2010, 12:15 PM -0400):

> Can you run two instances of Zend Server CE, one w/ php5.2 the other with
> php5.3?


Yes. Zend Server has FastCGI enabled, so you can have mod_php with one
version of PHP, and create FastCGI vhosts for running projects on other
versions of PHP. The steps are relatively easy:

 * In your vhost, you add a few lines:

ScriptAlias /cgi-bin/ /path/to/zfproject/public/cgi-bin/
AddHandler php-fcgi .php
Action php-fcgi /cgi-bin/php-5.3.1

 * Create a "cgi-bin" directory under your "public" directory
 
 * Create a script named "php-5.3.1" (or whatever you want -- just needs
   to be whatever you put in your vhost definition), and have it execute
   the php-cgi binary:

#!/bin/bash
exec /path/to/php/install/bin/php-cgi "$@"

   Because it's a CLI/CGI version of PHP, you can pass additional
   arguments to it as well -- which is useful for setting things like
   the include_path, etc.

   Make sure the script is executable.

 * On Zend Server on my ubuntu install, I had to do a few things to
   enable FastCGI: 

   % cd /etc/apache2/mods-enabled
   % sudo ln -s ../mods-available/fastcgi.load .
   % sudo ln -s ../mods-available/fastcgi.conf .
   % sudo ln -s ../mods-available/actions.load .
   % sudo ln -s ../mods-available/actions.conf .

Then restart your server, and you should be set.

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

Re: [fw-general] Team Development

[Paul]

Well Tortoise Subversion is just a svn client.  I have that all sorted.  
The issue is where are the local copies stored.  Centralized dev server 
or each developer local machine.  Wanted to see most organizations do, 
and some best practices.


On 8/6/2010 1:51 PM, Deborah Dalcin wrote:
Should also check out tortoise subversion.  It's not without it's 
problems, but it's a pretty solid tool.


On Fri, Aug 6, 2010 at 12:18 PM, Paul > wrote:


We currently use PHING, I have heard of Apache Maven, will look
into this.

On 8/6/2010 12:00 PM, Hector Virgen wrote:

Apache Maven




--
www.pseudoworlds.gibbserv.net/mms 


www.killk.gibbserv.net 

Re: [fw-general] Team Development

[Deborah Dalcin]

Should also check out tortoise subversion.  It's not without it's problems,
but it's a pretty solid tool.

On Fri, Aug 6, 2010 at 12:18 PM, Paul  wrote:

> We currently use PHING, I have heard of Apache Maven, will look into this.
>
> On 8/6/2010 12:00 PM, Hector Virgen wrote:
>
>> Apache Maven
>>
>


-- 
www.pseudoworlds.gibbserv.net/mms
www.killk.gibbserv.net

Re: [fw-general] Team Development

[Paul]

We currently use PHING, I have heard of Apache Maven, will look into this.

On 8/6/2010 12:00 PM, Hector Virgen wrote:

Apache Maven

Re: [fw-general] Team Development

[Paul]

I agree, one of the benefits of having the local environment is forcing 
your developers to understand apache and setting that up.


Can you run two instances of Zend Server CE, one w/ php5.2 the other 
with php5.3?


Also does Zend Server CE, offer a way (was looking through documentation 
yesterday, but could not find), to update your configuration and package 
them so that it really is matter of the rest of the team just running an 
update to get the lastest server config updates (extensions).


That is my main concern with the local environment, managing server 
changes, adding external resources (say using tinyMCE, or even updating 
to a new version of ZF).  Say you have a team of 20 developers, this can 
start to become a nightmare.


Once again, I am surprised there is no more written on this subject as 
it seems so central to building a website that requires more than one 
person.


On 8/6/2010 11:52 AM, Jason Austin wrote:
We worked in the single-dev-server environment for a long time, but in 
the last year have moved to our own local development stacks.  So far, 
that has worked out a lot better and is far less error prone.


The biggest problem that we have had is just the minor nuances that 
come with developing on an os-x lamp stack and deploying on a linux 
lamp stack, but those are usually not a big issue.  We run Zend Server 
CE on the local boxes and have found that to be very good as an 
all-in-one install.  Also it forced our devs to be a little more 
familiar with apache configuration and setup, so that was a learning 
challenge at first.


Hope that helps,
Jason

On Fri, Aug 6, 2010 at 11:22 AM, Paul > wrote:


I was wondering if anyone had some good resources on the topic of
working on a project with a team of php developers.  In particular
looking at the local setup for a developer.  Should each developer
have their own LAMP instance (probably using a VM)?  Or is it
better to have one centralized dev server, where each developer
has their own user, and their local copies are on that machine,
and they connect either through samba, ftp, etc.

Surprisingly there is not much on team development, and instead on
how one developer can setup their own development on their local
machine.

Being a freelancer for the past few years, and then previously
working with a company who used their own proprietary
language/environment, I would love to know how other php shops
developing enterprise web application (using ZF of course :))
manage this.

What are some guidelines, best practices, etc.  I am looking to
the ZF community because I feel the standards here are high, and
part of the point of ZF is how to build php projects the right
way, or at least in way that helps promote best practices.  Just
compare the code from Wordpress to ZF:)

Cheers,
Paul




--
Jason Austin
Senior Solutions Implementation Engineer
NCSU - OIT - Outreach Technology
jason_aus...@ncsu.edu 

Re: [fw-general] Team Development

[Hector Virgen]

We use Apache Maven to create builds and handle dependencies. It can
automatically configure Apache for each project and probably PHP too
(haven't tried this).

It usually takes a little bit of time to set up each dev environment so we
keep instructions posted on our internal wiki. Most of it is pretty straight
forward -- install Zend Server, Eclipse and plugins, Maven, then check out
project and build.

On Aug 6, 2010 8:50 AM, "Paul"  wrote:

 Not to mention, managing slightly different versions or say having some
of your projects running on php5.2 and others on php5.3.



On 8/6/2010 11:49 AM, Paul wrote:
>
> Right.  Another issue with a centralized dev server, is usin...

Re: [fw-general] Team Development

[Paul]

Not to mention, managing slightly different versions or say having 
some of your projects running on php5.2 and others on php5.3.


On 8/6/2010 11:49 AM, Paul wrote:
Right.  Another issue with a centralized dev server, is using debugger 
tool to add breakpoints.


In terms of every developer getting their own copy, how do you manage 
custom extensions.  If we need to installed say an extensions and 
update a php.ini file, managing this across a team of developers 
(where some may be very junior) doesn't that really make management a 
hassle?  Do you run into those issues a lot?


On 8/6/2010 11:38 AM, Hector Virgen wrote:


We have each developer set up their own dev environment on their 
local machine. At my previous company we shared a dev server and it 
was a daily occurence that someone would "kill dev" by running an 
unoptimized query or infinite loop.


But each developer running their own dev instance is not without 
problems. We occasionally run into Windows/Linux issues like 
case-sensitivity. But overall development is faster.


--
Hector

On Aug 6, 2010 8:22 AM, "Paul" > wrote:


I was wondering if anyone had some good resources on the topic of 
working on a project with a team of php developers.  In particular 
looking at the local setup for a developer.  Should each developer 
have their own LAMP instance (probably using a VM)?  Or is it better 
to have one centralized dev server, where each developer has their 
own user, and their local copies are on that machine, and they 
connect either through samba, ftp, etc.


Surprisingly there is not much on team development, and instead on 
how one developer can setup their own development on their local 
machine.


Being a freelancer for the past few years, and then previously 
working with a company who used their own proprietary 
language/environment, I would love to know how other php shops 
developing enterprise web application (using ZF of course :)) manage 
this.


What are some guidelines, best practices, etc.  I am looking to the 
ZF community because I feel the standards here are high, and part of 
the point of ZF is how to build php projects the right way, or at 
least in way that helps promote best practices.  Just compare the 
code from Wordpress to ZF:)


Cheers,
Paul

Re: [fw-general] Team Development

[Paul]

Right.  Another issue with a centralized dev server, is using debugger 
tool to add breakpoints.


In terms of every developer getting their own copy, how do you manage 
custom extensions.  If we need to installed say an extensions and update 
a php.ini file, managing this across a team of developers (where some 
may be very junior) doesn't that really make management a hassle?  Do 
you run into those issues a lot?


On 8/6/2010 11:38 AM, Hector Virgen wrote:


We have each developer set up their own dev environment on their local 
machine. At my previous company we shared a dev server and it was a 
daily occurence that someone would "kill dev" by running an 
unoptimized query or infinite loop.


But each developer running their own dev instance is not without 
problems. We occasionally run into Windows/Linux issues like 
case-sensitivity. But overall development is faster.


--
Hector

On Aug 6, 2010 8:22 AM, "Paul" > wrote:


I was wondering if anyone had some good resources on the topic of 
working on a project with a team of php developers.  In particular 
looking at the local setup for a developer.  Should each developer 
have their own LAMP instance (probably using a VM)?  Or is it better 
to have one centralized dev server, where each developer has their 
own user, and their local copies are on that machine, and they 
connect either through samba, ftp, etc.


Surprisingly there is not much on team development, and instead on 
how one developer can setup their own development on their local machine.


Being a freelancer for the past few years, and then previously 
working with a company who used their own proprietary 
language/environment, I would love to know how other php shops 
developing enterprise web application (using ZF of course :)) manage 
this.


What are some guidelines, best practices, etc.  I am looking to the 
ZF community because I feel the standards here are high, and part of 
the point of ZF is how to build php projects the right way, or at 
least in way that helps promote best practices.  Just compare the 
code from Wordpress to ZF:)


Cheers,
Paul

Re: [fw-general] Team Development

[Hector Virgen]

We have each developer set up their own dev environment on their local
machine. At my previous company we shared a dev server and it was a daily
occurence that someone would "kill dev" by running an unoptimized query or
infinite loop.

But each developer running their own dev instance is not without problems.
We occasionally run into Windows/Linux issues like case-sensitivity. But
overall development is faster.

--
Hector

On Aug 6, 2010 8:22 AM, "Paul"  wrote:

I was wondering if anyone had some good resources on the topic of working on
a project with a team of php developers.  In particular looking at the local
setup for a developer.  Should each developer have their own LAMP instance
(probably using a VM)?  Or is it better to have one centralized dev server,
where each developer has their own user, and their local copies are on that
machine, and they connect either through samba, ftp, etc.

Surprisingly there is not much on team development, and instead on how one
developer can setup their own development on their local machine.

Being a freelancer for the past few years, and then previously working with
a company who used their own proprietary language/environment, I would love
to know how other php shops developing enterprise web application (using ZF
of course :)) manage this.

What are some guidelines, best practices, etc.  I am looking to the ZF
community because I feel the standards here are high, and part of the point
of ZF is how to build php projects the right way, or at least in way that
helps promote best practices.  Just compare the code from Wordpress to ZF:)

Cheers,
Paul

[fw-general] Team Development

[Paul]

I was wondering if anyone had some good resources on the topic of 
working on a project with a team of php developers.  In particular 
looking at the local setup for a developer.  Should each developer have 
their own LAMP instance (probably using a VM)?  Or is it better to have 
one centralized dev server, where each developer has their own user, and 
their local copies are on that machine, and they connect either through 
samba, ftp, etc.


Surprisingly there is not much on team development, and instead on how 
one developer can setup their own development on their local machine.


Being a freelancer for the past few years, and then previously working 
with a company who used their own proprietary language/environment, I 
would love to know how other php shops developing enterprise web 
application (using ZF of course :)) manage this.


What are some guidelines, best practices, etc.  I am looking to the ZF 
community because I feel the standards here are high, and part of the 
point of ZF is how to build php projects the right way, or at least in 
way that helps promote best practices.  Just compare the code from 
Wordpress to ZF:)


Cheers,
Paul