Zend Framework 2

[masterpuppet]

Recién salido del horno Zend-Framework-2-0-0beta3

PHP 5.4 support = on

Saludos.

[pablofmorales]

Iniciado por masterpuppet

Recién salido del horno Zend-Framework-2-0-0beta3

PHP 5.4 support = on

Saludos.

Lo estoy probando, por ahi use ZF1 con componentes de ZF2

[GatorV]

Muy bien, siento que van mucho más rápido en el desarrollo desde que sacaron el B1...

[masterpuppet]

Es lógico que apuren un poco, la competencia se los esta comiendo.

He estado probando los modulos y la verdad "so far so good", se pueden instalar y sobrescribir la configuración, aunque enseguida te encontras con el problema de como modificar los templates si estos no están en configuración y extender para cambiar un template no es una opción así que termine utilizando el event manager, habrá que ver como estandarizan los módulos para que no sean un cacao y hablando de event manager, el StaticEventManager no me convence(smells ? :P).

Con suerte en 3 meses aparece el primer RC.

Saludos.

[GatorV]

¿a que te refieres con extender los templates? ¿Como twig? Es una idea interesante, sobreescribir las vistas sí estos están en un modulo con más prioridad...

[masterpuppet]

Me refiero a sobrescribir templates, después de configurar el modulo lo primero que vas a necesitar seguro es modificar el template, por ejemplo en el modulo para el usuario modificar el template de login, lo mas interesante es que actualmente se puede hacer con el event manager incluso se puede modificar el formulario.

Con respecto a Twig, sin palabras, no soy fan de los template engines pero Twig es excelente, incluso le tome cariño, lo mas probable es que lo utilice con Zend, la funcionalidad que tiene es increíble y los templates quedan muy limpios.

PD: soy yo el view helper action me lo robaron de Zend 2 ? porque ahora es cuando sirve.

[GatorV]

Interesante, tendré que darle un ojo a Twig... Cierto, pero por algo lo removieron, creo que la idea es que los módulos registren View Helpers para que los puedeas usar en tus plantillas.

[masterpuppet]

Efectivamente esa es la idea y de echo es muy simple, el problema es que en Zend\View\Helper no existe action, aunque me acabo de dar cuenta que esta en otra parte modules/ZendFramework1Mvc/library/Zend/View, por el lugar en el que esta debe ser algo como "Use at your own risk" :P, con la nueva arquitectura este view helper es esencial para crear widgets que hagan pull de controllers.

[GatorV]

Cierto, hay que ver que es lo que están planeando los de Zend, no creo que se les haya pasado algo tan crítico, para una arquitectura realmente modular...

[masterpuppet]

Zend 2 beta4 ready!, service managers, module mangers, view managers y composer, sweet!

[GatorV]

¡Perfecto! Gitpulleando

[masterpuppet]

Después de probarlo un poco puedo decir que las similitudes con Symfony 2 son pura coincidencia :P, muy bueno el composer y que lavado de cara le dieron al Form no hay ni decorators no se si volverá a tener en próximas versiones, otra cosa interesante es el bind, ese Stdlib en cada iteracion tiene mejor pinta ;)

Saludos.

[GatorV]

No he tenido chance de verlo todo pero me esta gustando mucho, aunque si antes se quejaban de ZF1 que era complicado, creo que ahora lo van a hacer más, pero realmente se nota lo empresarial de ZF2, el uso de patrones, la limpieza y como puedes modificar muchas cosas y extender el Framework es lo que me esta gustando y mucho.

[masterpuppet]

Pues para mi se ha simplificado al igual que SF2, mucho menos magia, cualquier dev con sólidos conocimientos de OOP & Patterns se va a sentir muy cómodo, y los que se quejan, bueno, esos siempre están...
Mirando un poco mas el componente Form tiene un TODO con muchas cosas interesantes, como estas:

Código TODO:

* Builder component
  * Introspect a class for annotations and build a form
    * Each "element" can specify:
      * filters and validators to use to build an input for the input filter
      * attributes for use with the form element
  * Should be able to generate a form class
 

ya se esta teniendo en cuenta la metadata, osea que generar forms a partir de entities va a ser muy sencillo(alguien dijo D2 ? :P), lo cual me parece genial, ya que los malditos forms en Zend 1.x consumen demasiado tiempo para una tarea tan repetitiva(ya me lo imagino integrado en la consola ), y bueno el bindeo al form a traves de los hydrators es una excelente idea.

De a poco iré mirando el resto de componentes y como siempre el código de Zend es un placer leerlo.

[GatorV]

Exacto a eso me refería, a lo solido por integrarse fuertemente a las bases de POO

Yo sigo contento con los ViewModels jeje, pero pronto iré a ver los Forms

[SetheR]

Desde la beta 1 que no le echaba el ojo (ni a PHP tampoco...).

Tiene realmente buena pinta. El tema de módulos me encanta y el composer es un verdadero ahorro de tiempo.. Desconozco si en Symfony es parecido.

Lo que no comprendo aún es porque se han complicado y repetido las cosas tanto en el tema de carga de clases (entre otros).
Por ejemplo que en un módulo tengas que definir los namespaces para el Autoloader y a su vez, un archivo autoload_function.php que implemente una función de carga; además no comprendo el uso de un classmap en éste sentido. Lo único que hace ésto es complicar la vida a los devs.

Creo que sobra bastante configuración. quiero decir, está bien que sea configurable al máximo,pero creo que un poco establecer unas pautas o convenciones para evitar la excesiva configuración inicial no estaría nada mal.

Yo de todas maneras, ya le estoy dando al FW, para lelgar con una buena base al RC

Saludos

[GatorV]

Creo eso es para la flexibilidad, y es por ahorita, una vez que este más estable las herramientas del CLI van a ayudar y hacer las cosas más eficientes.

Saludos.

[masterpuppet]

Tiene realmente buena pinta. El tema de módulos me encanta y el composer es un verdadero ahorro de tiempo.. Desconozco si en Symfony es parecido.

Composer es el mismo para cualquier fw.

Lo que no comprendo aún es porque se han complicado y repetido las cosas tanto en el tema de carga de clases (entre otros).
Por ejemplo que en un módulo tengas que definir los namespaces para el Autoloader y a su vez, un archivo autoload_function.php que implemente una función de carga; además no comprendo el uso de un classmap en éste sentido. Lo único que hace ésto es complicar la vida a los devs.

Ya no es necesario tener esos archivos, y la idea detrás de todo eso es acelerar la carga de las clases, también ten en cuenta que el classmap se genera a traves del cli, honestamente no veo en que te puede complicar algo tan sencillo que utilizarías cuando la app pasa a producción.

Creo que sobra bastante configuración. quiero decir, está bien que sea configurable al máximo,pero creo que un poco establecer unas pautas o convenciones para evitar la excesiva configuración inicial no estaría nada mal.

Es el precio de utilizar di en un fw tan desacoplado, de todas formas en cada iteracion se necesita menos config y si prestas atención ya hay un patrón que emerge, lazy loading en los getters.

Personalmente el fw no me preocupa, ya es excelente, el tema son los modulos, espero que no caigan en lo de los bundles de SF2 donde muchos de los mismos directamente no funcionan, o no siguen el ritmo de desarrollo de Symfony y quedan rápidamente obsoletos.
Esperemos que la gente de ZF Commons sea capaz de sacar esto adelante, ya tienen un par de modulos interesantes pero todavia falta la frutilla, el admin module.

Saludos.

[SetheR]

Iniciado por masterpuppet

Composer es el mismo para cualquier fw.

S, eso lo sé jaja. Me refería a la orientación que le dan a la arquitectura de módulos. Desconozco Symfony ya que lo único que he usado de él es el Loader de clases.

Iniciado por masterpuppet

Ya no es necesario tener esos archivos, y la idea detrás de todo eso es acelerar la carga de las clases, también ten en cuenta que el classmap se genera a traves del cli, honestamente no veo en que te puede complicar algo tan sencillo que utilizarías cuando la app pasa a producción.

Ajá, como dije arriba, hace mucho que no le echo un ojo. Y ésto lo desconocía. y sí, de cualquier manera, una mayor cantidad de archivos de configuración, aumentan la complejidad de manera notable, sobretodo a los que están aprendiendo a utilizarlo como yo.

Estoy seguro que los móulos de zfcommons no quedarán desactualizados así como así. ya en las betas, las labores de mantenimiento y actualización son bastante frecuentes.



Saludos.

[masterpuppet]

Symfony 2 respeta el PSR-0 así que da igual como sea internamente, el composer solo tiene que saber donde esta la carpeta raiz para el autoloader.

Con respecto al autoloader, como te comente antes, no veo la dificultad, la idea es que antes de subir a produccion se haga via consola o que te hagas un builder para ejecutar cuando quieras, hace tiempo que hay una herramienta para hacerlo, pero supongo que se integrara en el cli final, actualmente no es mas que:

Código PHP:

php classmap_generator.php -w
 

Y en relación a zfcommons, yo supongo que ira bien, pero no se puede tomar como medida lo actual, actualizar un repositorio que no hace nada no es problema, el tema va a ser cuando esto realmente se entre a mover, de todas formas supongo que se tomaran precauciones y mas teniendo como ejemplo Syfmony 2.

Saludos.

[masterpuppet]

Buenas,

Hace un par de dias se hizo el último gran update de los forms, el cual trae Annotations , un pequeño ejemplo por si quieren meter mano:

Entity

Código PHP:

namespace Application\Entity;
 
use Doctrine\ORM\Mapping as ORM,
    Zend\Form\Annotation as Form,
    Zend\Stdlib\ArraySerializableInterface,
    Application\Model\PostInterface,
    DateTime;
 
/**
 * @ORM\Entity()
 * @ORM\HasLifecycleCallbacks
 */
class Post implements PostInterface, ArraySerializableInterface
{
    const NOT_DRAFT = 0;
    const DRAFT     = 1;
    const NOT_TRASH = 0;
    const TRASH     = 1;
 
    /**
     * @ORM\Id 
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue     
     * @Form\Attributes({"type":"hidden"})
     * @Form\AllowEmpty
     */
    protected $id;
 
    /**  
     * @ORM\Column()
     * @Form\Required
     * @Form\Filter({"name":"StripTags"})
     * @Form\Filter({"name":"StringTrim"})
     * @Form\Filter({"name":"StringToUpper"})
     * @Form\Validator({"name":"Alnum"})         
     */
    protected $title;
 
    /**         
     * @ORM\Column()     
     * @Form\Attributes({"type":"textarea"})
     * @Form\Filter({"name":"StripTags"})         
     * @Form\Filter({"name":"StringTrim"})   
     */
    protected $content;
 
    /**
     * @ORM\Column(name="created_at", type="datetime")   
     * @Form\AllowEmpty
     * @Form\Validator({"name":"Date"})
     */ 
    protected $createdAt;
 
    /**
     * @ORM\Column(name="updated_at", type="datetime")   
     * @Form\AllowEmpty
     * @Form\Validator({"name":"Date"})
     */     
    protected $updatedAt;
 
    /**
     * @ORM\Column(type="boolean")
     */     
    protected $draft;
 
    /**
     * @ORM\Column(type="boolean")
     */         
    protected $trash;
}
 

Controller

Código PHP:

public function indexAction()
{               
    $request = $this->getRequest();
    $builder = new AnnotationBuilder();
    $entity  = new Post();
    $form    = $builder->createForm($entity);
    $form->add(array(
        'name' => 'submit',
        'attributes' => array(
            'type' => 'submit'
        )
    ));
    $form->bind($entity);
    if($request->isPost()){         
        $form->setData($request->post());
        if($form->isValid()) {          
            $em = $this->getServiceLocator()->get('doctrine.entitymanager.orm_default');
            $em->persist($form->getData());
            $em->flush();               
            $this->flashMessenger()->addMessage('Entity persisted.');
            $this->redirect()->toRoute('home');
        }
    }
    return new ViewModel(array('form' => $form));
}
 

sencillamente fantástico :alabanza:, tengan en cuenta que es la primera aproximación.

Saludos.

[GatorV]

Gracias por el ejemplo, creo voy a cambiar el título del Thread por Zend Framework 2 Beta solamente jeje.

[masterpuppet]

Cambie nomas, es que yo me entusiasmo y mando post :P, dejo un par mas con opciones:

Código PHP:

/**  
 * @ORM\Column()
 * @Form\Filter({"name":"StringToUpper"})     
 * @Form\Validator({"name":"Alnum"})        
 * @Form\Validator({
 *      "name":"StringLength",
 *      "options": {
 *          "min":3, 
 *          "max":255
 *      }
 * })        
 */
protected $title;
 
/**
 * @ORM\Column(name="updated_at", type="datetime")   
 * @Form\AllowEmpty
 * @Form\Validator({
 *      "name":"Date",
 *      "options": {
 *          "format": "dd-MM-yyyy"
 *      }
 * })
 */ 
protected $updatedAt;
 
/**
 * @ORM\Column(type="boolean")        
 * @Form\Validator({
 *      "name":"inArray",
 *      "options":{
 *          "haystack": [0,1]
 *      }
 * })
 */ 
protected $draft;
 

seguramente en el DoctrineORMModule se agregara alguna suerte de bridge para que automáticamente utilice la metadata de Doctrine.

Saludos.

[MichaelParra]

Me da gusto como va quedando, el parecido con Symfony2 es innegable, igual sí todo sigue así me darán ganas de hacer un proyecto en ZF2 xD, ojalá y tengan una opción para usar Twig, assetic y un routing como Django / Symfony2 y cosas nuevas... pero en lo general está quedando muy bien.

Ahora alguien me puede aclarar si ZF2 tendrá su propio ORM o Active Record, o tirará de Doctrine2 / Propel como Symfony2?

Saludos.

[masterpuppet]

Por fuera son muuuuuuy similares, cualquier dev de Sf no deberia tener problemas en trabajar con Zend y viceversa, con respecto a Twig y Assetic, actualmente están integrados en módulos ;) y se pueden utilizar sin problemas, de hecho yo utilizo el de Twig, nunca me han gustado los sistema de plantillas pero Twig es una sal.

Sobre el router, es muy similar a lo que había antes, no esta ni cerca de la sencillez del de Sf, pero, es muy potente y flexible.

En relación al ORM, la solución que trae Zend por defecto es Zend\Db que implementa TableGateway + RowGateway, de todas formas la integracion con D2 ya esta hecha en los modulos DoctrineModule, DoctrineORMModule, DoctrineMongoODMModule y creo que de momento Propel no tiene Module, pero no es mas que cuestión de tiempo.

Saludos.

[masterpuppet]

Zend 2 beta5 ready!, varios componentes desaparecen(Currency, Date, Locale, etc...) en favor de Intl y algo a tener en cuenta es que se ha optado por seguir el estándar de doctrine en annotations lo que genera una dependencia con Doctrine\Common, de todas formas se pueden agregar otros parsers :).

Saludos.

[GatorV]

Muy bien, ya agregaron un "Parameters" controller plugin para obtener parametros del route, de get, post, etc.

[masterpuppet]

No se si lo has probado GatorV pero no entiendo muy bien lo rápido que se tomo la decisión de dejar en un segundo plano al DI en favor del Service Locator(ala Symfony 2), que no es mas que un Registry con esteroides como comento uno de los devs.
Ahora se reduce a factories pasando el sl por absolutamente todos lados...

Saludos.

[GatorV]

No, no lo he probado, tengo que hacer el update pero he estado atorado en otras cosas, me extraña eso, tenía muy buena pinta, aunque al final era estar usando el di y pasándolo también desde el evento...

[masterpuppet]

Si pero es un cambio importante, antes era todo a traves del DI, ahora es algo asi:

Module.php

Código PHP:

public function getServiceConfiguration()
{
    return array(
        'aliases' => array(),
        'factories' => array(
            'FooService'  => 'Bar\Service\FooFactory',                
        )
    );
}
 

src/Bar/Service/FooFactory

Código PHP:

class FooFactory implements FactoryInterface
{
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        $config = $serviceLocator->get('Configuration');
        $config = $config['bar'];
        $fooService = new FooService($config['config']);
        return $fooService;
    }
}
 

pasamos de la metadata del DI al hardcode del SL, entiendo el porque, lo que no agrada mucho es que se haya decidido tan rápido el cambio, y me da la sensación que este cambio va a hacer desaparecer al DI, de todas formas el SL hace un fallback al DI con lo cual este último se puede seguir utilizando de forma transparente.

Igualmente seria interesante después que lo pruebes leer tu opinión

Saludos.