Re: [fw-general] ZF2, Doctrine 2, and Composer autoload class redeclared error.

2014-03-12 Thread John Wynstra
Meant to send this to the list, but had only sent it to Marco.



OK.  I HAD declared the class twice, and it was not apparent until I logged
onto the Linux server via putty to examine the directory.   My  Entites
directory contained the following two files both declaring the same class:

articles.php
Articles.php

ONLY ONE of them was present in my Zend Studio project. I had renamed the
file in Zend Studio, but it did not delete the other file on the server.
 After discovering this, I even tried a download from server and the extra
file did not come down.

 Thanks for offering to help.  It was actually your request for a gist with
file paths that caused me to discover this.   I have no idea why I decided
to log on to the server directly because I already had the project open in
Zend Studio.


On Tue, Mar 11, 2014 at 8:00 PM, Marco Pivetta  wrote:

>
>
> On 7 March 2014 21:10, John Wynstra  wrote:
>
>> I am experimenting with Doctrine 2 in ZendFramework 2 and am getting the
>> following error:
>>
>> PHP Fatal error:  Cannot redeclare class Application\\Entity\\articles in
>>
>> ../../ZendSkeletonApplication/module/Application/src/Application/Entity/articles.php
>> on line 8
>>
>
> This looks like a typo of some kind. The information provided is
> insufficient to debug the problem, though.
>
> Could you provide a gist with the file paths, autoloader config and file
> contents of the class?
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>


-- 

John Wynstra
Library Information Systems Specialist
Rod Library
University of Northern Iowa
Cedar Falls, IA  50613
wyns...@uni.edu
(319)273-6399



Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Ralf Eggert
Hi Matthew,

> As such, the above example would not have worked at any time in the 2.2 
> series.

Sorry, my mistake. The code snippet had the wrong use statement. It
should have been:

use Zend\Mvc\I18n\Translator;

Thanks and best regards,

Ralf

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Matthew Weier O'Phinney
On Wed, Mar 12, 2014 at 10:07 AM, Ralf Eggert  wrote:
> I found another one:
>
>   use Zend\I18n\Translator\Translator;
>
>   AbstractValidator::setDefaultTranslator(
> Translator::factory($this->config['translations']['validator'])
>   );
>
> Does not work, since AbstractValidator::setDefaultTranslator() expects
> the implementation of the Zend\Validator\Translator\TranslatorInterface
> which is only implemented by Zend\Mvc\I18n\Translator.
>
> Is this intended to pass the MvcTranslator instance from the
> Service-Manager and add the translation texts to it rather than having a
> special translator instance for validator messages?

Actually, this has been true since *2.2.0*! In that release, we
modified the Validator component to define its own
TranslatorInterface. Zend\Mvc\I18n\Translator was introduced at that
time as well, and, at the time, extended
Zend\I18n\Translator\Translator and implemented the validator's
TranslatorInterface. The MVC translator would be what you would need
to pass to validators to enable translation.

As such, the above example would not have worked at any time in the 2.2 series.

-- 
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

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




[fw-general] Zend Framework 2.3.0 Released!

2014-03-12 Thread Matthew Weier O'Phinney
Zend Framework 2.3.0 has just released!

10 months in the making, > 230 pull requests, 560 contributors... Nice
work, everyone!

The release aims to be backwards compatible with previous releases,
and provides a slough of new features and incremental improvements.
One important note, however: 2.3.0 is the first ZF2 version upping the
minimum supported PHP version to 5.3.23.

For the full release announcement:

- http://bit.ly/zf-2-3-0

-- 
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

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Ralf Eggert
Hi Matthew,

I found another one:

  use Zend\I18n\Translator\Translator;

  AbstractValidator::setDefaultTranslator(
Translator::factory($this->config['translations']['validator'])
  );

Does not work, since AbstractValidator::setDefaultTranslator() expects
the implementation of the Zend\Validator\Translator\TranslatorInterface
which is only implemented by Zend\Mvc\I18n\Translator.

Is this intended to pass the MvcTranslator instance from the
Service-Manager and add the translation texts to it rather than having a
special translator instance for validator messages?

Thanks and best regards,

Ralf

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] ZF2 development visualization

2014-03-12 Thread Jeremiah Small
https://code.google.com/p/gource/

Jeremiah

> On Mar 12, 2014, at 3:26 AM, jmleroux  wrote:
> 
> A little bit off topic...
> 
> I don't know how to do this for ZF2, but this could be a good publicity
> 
> https://www.youtube.com/watch?v=NMjA5N7kbEQ
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://zend-framework-community.634137.n4.nabble.com/ZF2-development-visualization-tp4661846.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
> 
> -- 
> List: fw-general@lists.zend.com
> Info: http://framework.zend.com/archives
> Unsubscribe: fw-general-unsubscr...@lists.zend.com
> 
> 


Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Ralf Eggert
Hi Matthew,

Matthew Weier O'Phinney schrieb am 12.03.2014 00:29:
> That's a good point, and I'll make sure to point it out in the release
> notes. 

That will be ok for me if it is added to the release notes...

:-)

Thanks and best regards,

Ralf

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




RE: [fw-general] Configuration merging and callables

2014-03-12 Thread Demian Katz
Actually, after looking more closely at the PHP manual for callables (thanks to 
the suggestion of a colleague), there is a simple alternative: just use 
callable strings instead of callable arrays…

so:

array(‘My\Factory’, ‘myStaticMethod’)

becomes:

‘My\Factory::myStaticMethod’

Easy! I'll still consider the possibility of using separate factory classes 
under some circumstances, but when it makes sense to group stuff together, it 
looks like this offers the option to do so without breaking overriding.

- Demian

> -Original Message-
> From: Demian Katz [mailto:demian.k...@villanova.edu]
> Sent: Wednesday, March 12, 2014 8:31 AM
> To: Matthew Weier O'Phinney
> Cc: Zend Framework General
> Subject: RE: [fw-general] Configuration merging and callables
> 
> That certainly works, but it seems to add an awful lot of clutter – a separate
> factory class for every service. My application offers a lot of different
> options, so this would add hundreds of files and require PHP to do twice as
> much autoloading (which I realize isn’t that expensive, but it has to add up
> at some point). I considered putting a static factory method in each class to
> cut down on clutter, but this doesn’t seem like good design – it couples
> things unnecessarily. Having stand-alone factory classes that group together
> related objects seems like the most attractive option from an organizational
> perspective. Sounds like it may not be practical, and I know you’re the expert
> – but I would be curious to hear if anyone else has successfully approached
> this from another angle. If not, I’ll get to work moving all my factories
> around a second time. ☺
> 
> - Demian
> 
> From: Matthew Weier O'Phinney [mailto:matt...@zend.com]
> Sent: Tuesday, March 11, 2014 7:32 PM
> To: Demian Katz
> Cc: Zend Framework General
> Subject: Re: [fw-general] Configuration merging and callables
> 
> Use classes that implement __invoke() instead, and reference the class name.
> The SM is smart enough to autoload these when requested, making them a more
> robust solution than array callbacks - particularly for the use car of
> overriding.


RE: [fw-general] Configuration merging and callables

2014-03-12 Thread Demian Katz
That certainly works, but it seems to add an awful lot of clutter – a separate 
factory class for every service. My application offers a lot of different 
options, so this would add hundreds of files and require PHP to do twice as 
much autoloading (which I realize isn’t that expensive, but it has to add up at 
some point). I considered putting a static factory method in each class to cut 
down on clutter, but this doesn’t seem like good design – it couples things 
unnecessarily. Having stand-alone factory classes that group together related 
objects seems like the most attractive option from an organizational 
perspective. Sounds like it may not be practical, and I know you’re the expert 
– but I would be curious to hear if anyone else has successfully approached 
this from another angle. If not, I’ll get to work moving all my factories 
around a second time. ☺

- Demian

From: Matthew Weier O'Phinney [mailto:matt...@zend.com]
Sent: Tuesday, March 11, 2014 7:32 PM
To: Demian Katz
Cc: Zend Framework General
Subject: Re: [fw-general] Configuration merging and callables

Use classes that implement __invoke() instead, and reference the class name. 
The SM is smart enough to autoload these when requested, making them a more 
robust solution than array callbacks - particularly for the use car of 
overriding.


Re: [fw-general] ZF2 development visualization

2014-03-12 Thread Marco Pivetta
This is generated via gource - you can usually run it against any vcs ;-)
On 12 Mar 2014 11:27, "jmleroux"  wrote:

> A little bit off topic...
>
> I don't know how to do this for ZF2, but this could be a good publicity
>
> https://www.youtube.com/watch?v=NMjA5N7kbEQ
>
>
>
>
>
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/ZF2-development-visualization-tp4661846.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
> --
> List: fw-general@lists.zend.com
> Info: http://framework.zend.com/archives
> Unsubscribe: fw-general-unsubscr...@lists.zend.com
>
>
>


[fw-general] ZF2 development visualization

2014-03-12 Thread jmleroux
A little bit off topic...

I don't know how to do this for ZF2, but this could be a good publicity

https://www.youtube.com/watch?v=NMjA5N7kbEQ





--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/ZF2-development-visualization-tp4661846.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] Re: Refactoring towards ZF2 (subfolders)

2014-03-12 Thread Stefano Torresi
D'oh! I'm sorry to have caused more confusion than anything else, let's try
and sort things out.

* why are there similar but different PSRs concerning paths and namespaces?
>

PSR-4 is an addition to PSR-0, and allows flatter directory structures.




> * what sis a "vendor specific prefix"?  In my case I am writing the app, so
> there is no 3rd party vendor.
>

A vendor prefix is just a namespace. While it is enforced by the mentioned
PSR standards, it's not actually mandatory to make a ZF2 application or
module work;
E.g. a common approach found in ZendSkeletonApplication is to have a main
'Application' module without any vendor prefix. That can lead to develop
additional modules also without any prefix, which will become inconvenient
when you'll want to move those modules outside the original application and
reuse them across other ones.
So, I would strongly suggest to consistently use a vendor prefix namespace,
because your present self may become a 3rd party vendor of your future
self. :P




> * why is your 'Prefix' equals '/src'?  I thought a 'Prefix' is a
> descriptive
> name for a 3rd party module like '/vendor/ZfcUser/..'
>

Sorry, i made the example quite unclear.
By 'Prefix' => '/src' that I meant that, in the example, the autoloader is
configured to search classes with the 'Prefix' vendor namespace in the
'/src' path.
I.e. in composer.json you would have the following lines:

{
"autoload" : {
"psr-4": {
"Prefix\\": "src/",
}
},
}



> * What is a Prefix?  Is that a namespace?  no... what's it for?
>

Yep, it is the vendor prefix namespace in the example.




> So far I am thinking that I will put my classes into `module/Device`
> folder,
> but I am so confused right now I don't know what to do..  I might just
> leave
> it in 'module/Device/src/Device/Entity' like I have now, because when it
> will come for porting to ZF2, I will have my structure already in place.
>
> I am not having a clear understanding on PSR-0, PSR-4 and which one to use
> and why.
>
>
take a look at this:
https://github.com/php-fig/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-meta.md

tl;dr:
There is no reason not to use PSR-4 because it's backward compatible (not
counting the old php 5.2 underscore notation, which is not supported any
more).
If you want a 1:1 class-to-path map you'll want to use PSR-0 structure, if
you want flatter directory trees you'll want to use PSR-4 structure.
Both cases can be handled by a PSR-4 compliant autoloader.

Cheers.


Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Norbert Máté
Thanks Marco. With --prefer-dist is working.

Norbert.

On 12 March 2014 11:12, Marco Pivetta  wrote:

>
>
> On 12 March 2014 09:48, Norbert Máté  wrote:
>
>> Now I can't update zf2 using composer.
>> I didn't change anything in the composer.json. Yesterday the update
>> worked.
>>
>
> Hey Norbert,
>
> Github had serious hiccups yesterday, so it may be that. You can either
> retry with `--prefer-dist` or just increase the timeout if your connection
> is slow.
>
> This is surely not a ZF issue
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>


Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Marco Pivetta
On 12 March 2014 09:48, Norbert Máté  wrote:

> Now I can't update zf2 using composer.
> I didn't change anything in the composer.json. Yesterday the update worked.
>

Hey Norbert,

Github had serious hiccups yesterday, so it may be that. You can either
retry with `--prefer-dist` or just increase the timeout if your connection
is slow.

This is surely not a ZF issue

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


Re: [fw-general] Almost ready for 2.3.0!

2014-03-12 Thread Norbert Máté
Now I can't update zf2 using composer.
I didn't change anything in the composer.json. Yesterday the update worked.
Here is the output:

Updating dependencies (including require-dev)
  - Removing zendframework/zendframework (2.2.6)
  - Installing zendframework/zendframework (dev-develop e6ecdf9)
Cloning e6ecdf95c7d7cd7e24f431c54bb52779a1ef9130
Failed to download zendframework/zendframework from source: The process
"git clone --no-checkout 'git://github.com/zendframework/zf2.git'
'/disk2/www/beyazpano/vendor/zendframework/zendframework' && cd
'/disk2/www/beyazpano/vendor/zendframework/zendframework' && git remote add
composer 'git://github.com/zendframework/zf2.git' && git fetch composer"
exceeded the timeout of 300 seconds.


This is my composer.json:
"require": {
"php": ">=5.4",
"aws/aws-sdk-php": "2.4.2",
"zendframework/zendframework": "~2.3-dev",
"ocramius/ocra-cached-view-resolver": "1.1.*@dev"
}



On 12 March 2014 01:29, Matthew Weier O'Phinney  wrote:

> On Mar 11, 2014 4:08 PM, "Ralf Eggert"  wrote:
> > Matthew Weier O'Phinney schrieb am 11.03.2014 18:45:
> > > This is now addressed -- Norbert and Ralf -- can you each test again
> for me? :)
> >
> > I get this message:
> >
> >   Fatal error: Call to undefined method Zend\Mvc
> >   \I18n\Translator::factory() in /home/devhost/v3.travello.com/vendor
> >   /RalfEggert/travello-library/src/TravelloLib/Mvc/Router
> >   /TranslatorFactory.php on line 39
> >
> > for this code
> >
> >   use Zend\Mvc\I18n\Translator;
> >
> >   $translator = Translator::factory($config['router']['translator']);
> >
> > Zend\Mvc\I18n\Translator used to extend Zend\I18n\Translator\Translator
> > in 2.2.x and now it implements Zend\I18n\Translator\TranslatorInterface
> > and does not implement a factory method any more.
> >
> > I solved this issue like this:
> >
> >   use Zend\I18n\Translator\Translator as I18nTranslator;
> >   use Zend\Mvc\I18n\Translator as MvcTranslator;
> >
> >   $translator = new MvcTranslator(
> > I18nTranslator::factory($config['router']['translator'])
> >   );
>
> That's a good point, and I'll make sure to point it out in the release
> notes. The MvcTranslator is generally only expected to be pulled from the
> ServiceManager, and rarely instantiated directly, which is why we made the
> change. However, that assumption is clearly not entirely true, so we'll
> need to call out the change in constructor for use cases like yours.
>


Re: [fw-general] ZF2, Doctrine 2, and Composer autoload class redeclared error.

2014-03-12 Thread Norbert Máté
Does this happen when you try to run composer install?
Sometime it happens to me also. I have to disable apc cache (cli) to be
able to run composer install.

Regards,
Norbert.