\r\n Source: http://mwop.net/blog/2012-07-02-zf2-beta5-forms.html
\r\n\r\n Forms are a nightmare for web development. They break the concept of separation of concerns:
\r\n\r\n On top of that, the submitted data is often directly related to your domain models, causing more issues:
\r\n\r\n Add to this that the validation logic may be re-usable outside of a forms context, and you've got a rather complex problem.
\r\n\r\n Starting in 2.0.0beta4, we offerred a completely rewritten Form component. In fact, it's not just a Form component -- a new component, InputFilter, was also added. InputFilter is a component that provides re-usable validation and normalization logic, and can be used with forms or your domain model. The Form component is basically a bridge between domain models/validation and the view layer.
\r\n\r\n However, this means a bit more complexity for the end-user. You now must:
\r\n\r\n It's a bit of work. And there's more: we wanted to simplify the process of getting your validated values into your domain objects. For this, we added a concept of hydrators, which map the validated form values to an object you bind to the form. Now you have three pieces to keep track of -- form (and its elements), input filter (and its inputs), and a hydrator.
\r\n So, a few developers had an idea: use annotations on the domain model objects to define these items, letting you keep it all in one place.
\r\n While I'm not normally a fan of annotations, I immediately saw the appeal in this particular situation.
\r\n Let's consider a very simple example. The following domain object represents data for a user, and includes a variety of elements we'd represent in a form.
\r\n\r\n\r\nnamespace MyVendor\\Model;\r\n\r\nuse Zend\\Form\\Annotation;\r\n\r\n/**\r\n * @Annotation\\Hydrator("Zend\\Stdlib\\Hydrator\\ObjectProperty")\r\n * @Annotation\\Name("user")\r\n */\r\n \r\nclass User\r\n{\r\n /**\r\n * @Annotation\\Attributes({"type":"text" })\r\n * @Annotation\\Validator({"type":"Regex","options":{"regex":"/^[a-zA-Z][a-zA-Z0-9_-]{1,19}/"}})\r\n * @Annotation\\Options({"label":"Username:"})\r\n */\r\n public $username;\r\n\r\n /**\r\n * @Annotation\\Required(false)\r\n * @Annotation\\Attributes({"type":"text" })\r\n * @Annotation\\Options({"label":"Your full name:"})\r\n */\r\n public $fullname;\r\n\r\n /**\r\n * @Annotation\\Type("Zend\\Form\\Element\\Email")\r\n * @Annotation\\Options({"label":"Your email address:"})\r\n */\r\n public $email;\r\n\r\n /**\r\n * @Annotation\\Type("Zend\\Form\\Element\\Url")\r\n * @Annotation\\Options({"label":"Your home page:"})\r\n */\r\n public $uri;\r\n}\r\n \r\n\r\n So, what does the above do?
\r\n\r\n So, let's now turn to creating a form and consuming it.
\r\n\r\n\r\nuse MyVendor\\Model\\User;\r\nuse Zend\\Form\\Annotation\\AnnotationBuilder;\r\n\r\n$user = new User();\r\n$builder = new AnnotationBuilder();\r\n$form = $builder->createForm($user);\r\n\r\n$form->bind($user);\r\n$form->setData($dataFromSomewhere);\r\n\r\nif ($form->isValid()) {\r\n // $user is now populated!\r\n echo $form->username;\r\n return;\r\n} else {\r\n // probably need to render the form now.\r\n}\r\n \r\n\r\n You're not quite done, really -- most likely, you'll need to include a submit button of some sort, and it's always good practice to include a token to prevent CSRF injections. But with the above, you've accomplished the major headaches of setting up a form -- and using the data -- with minimal fuss.
\r\n\r\n The form support in ZF2 offers a ton of other features, some of which are not specific to forms even.
\r\n\r\n These features are all now available starting with the newly released 2.0.0beta5 version, which you can grab from the ZF2 packages site.
\r\n\r\n I'm really excited with the solutions we've created in ZF2, and even more excited to see people put them to use!
\r\n','\r\n Source: http://mwop.net/blog/2012-07-02-zf2-beta5-forms.html\r\n\r\n Forms are a nightmare for web development. They break the concept of separation of concerns:\r\n\r\n \r\n They have a display aspect (the actual HTML form)\r\n \r\n They have a validation aspect\r\n \r\n And the two mix, as you need to display validation error messages.\r\n\r\n\r\n On top of that, the submitted data is often directly related to your domain models, causing more issues:\r\n\r\n \r\n Not all elements will have a 1:1 mapping to the domain model -- buttons, CSRF protection, CAPTCHAs, etc. usually are application-level concerns, but not domain issues.\r\n \r\n Names valid for your domain model may not be valid names for HTML entities.\r\n\r\n\r\n Add to this that the validation logic may be re-usable outside of a forms context, and you've got a rather complex problem.\r\n\r\n Forms in ZF2\r\n\r\n Starting in 2.0.0beta4, we offerred a completely rewritten Form component. In fact, it's not just a Form component -- a new component, InputFilter, was also added. InputFilter is a component that provides re-usable validation and normalization logic, and can be used with forms or your domain model. The Form component is basically a bridge between domain models/validation and the view layer.\r\n\r\n However, this means a bit more complexity for the end-user. You now must:\r\n\r\n \r\n Create your form, which consists of elements and fieldsets.\r\n \r\n Create an input filter, consisting of inputs.\r\n \r\n Inform the form of the input filter.\r\n\r\n\r\n It's a bit of work. And there's more: we wanted to simplify the process of getting your validated values into your domain objects. For this, we added a concept of hydrators, which map the validated form values to an object you bind to the form. Now you have three pieces to keep track of -- form (and its elements), input filter (and its inputs), and a hydrator.\r\n So, a few developers had an idea: use annotations on the domain model objects to define these items, letting you keep it all in one place.\r\n While I'm not normally a fan of annotations, I immediately saw the appeal in this particular situation.\r\n\r\n An Example\r\n\r\n Let's consider a very simple example. The following domain object represents data for a user, and includes a variety of elements we'd represent in a form.\r\n\r\n \r\n\r\nnamespace MyVendor\\Model;\r\n\r\nuse Zend\\Form\\Annotation;\r\n\r\n/**\r\n * @Annotation\\Hydrator(\"Zend\\Stdlib\\Hydrator\\ObjectProperty\")\r\n * @Annotation\\Name(\"user\")\r\n */\r\n \r\nclass User\r\n{\r\n /**\r\n * @Annotation\\Attributes({\"type\":\"text\" })\r\n * @Annotation\\Validator({\"type\":\"Regex\",\"options\":{\"regex\":\"/^[a-zA-Z][a-zA-Z0-9_-]{1,19}/\"}})\r\n * @Annotation\\Options({\"label\":\"Username:\"})\r\n */\r\n public $username;\r\n\r\n /**\r\n * @Annotation\\Required(false)\r\n * @Annotation\\Attributes({\"type\":\"text\" })\r\n * @Annotation\\Options({\"label\":\"Your full name:\"})\r\n */\r\n public $fullname;\r\n\r\n /**\r\n * @Annotation\\Type(\"Zend\\Form\\Element\\Email\")\r\n * @Annotation\\Options({\"label\":\"Your email address:\"})\r\n */\r\n public $email;\r\n\r\n /**\r\n * @Annotation\\Type(\"Zend\\Form\\Element\\Url\")\r\n * @Annotation\\Options({\"label\":\"Your home page:\"})\r\n */\r\n public $uri;\r\n}\r\n \r\n\r\n\r\n So, what does the above do?\r\n\r\n \r\n The \"name\" annotation gives a form or element a specific name.\r\n \r\n The \"attributes\" annotation indicates what attributes to compose into the form or element.\r\n \r\n Similarly, the \"options\" annotation specifies options to compose into an element. These typically include the label, but may include other configuration that doesn't have an exact analog in the HTML attributes.\r\n \r\n The \"validator\" annotation indicates a validator to compose for the input for a given element. We also ship a \"filter\" annotation.\r\n \r\n The \"type\" annotation indicates a class to use for that particular form or element. In the specific cases used above, the elements actually provide default filters and validators, simplifying setup further!\r\n \r\n Last, but not least, the \"hydrator\" annotation indicates a Zend\\Stdlib\\Hydrator implementation to use to relay data between the form and the object. I'll cover this more shortly.\r\n\r\n\r\n So, let's now turn to creating a form and consuming it.\r\n\r\n \r\n\r\nuse MyVendor\\Model\\User;\r\nuse Zend\\Form\\Annotation\\AnnotationBuilder;\r\n\r\n$user = new User();\r\n$builder = new AnnotationBuilder();\r\n$form = $builder->createForm($user);\r\n\r\n$form->bind($user);\r\n$form->setData($dataFromSomewhere);\r\n\r\nif ($form->isValid()) {\r\n // $user is now populated!\r\n echo $form->username;\r\n return;\r\n} else {\r\n // probably need to render the form now.\r\n}\r\n \r\n\r\n\r\n You're not quite done, really -- most likely, you'll need to include a submit button of some sort, and it's always good practice to include a token to prevent CSRF injections. But with the above, you've accomplished the major headaches of setting up a form -- and using the data -- with minimal fuss.\r\n\r\n Much more!\r\n\r\n The form support in ZF2 offers a ton of other features, some of which are not specific to forms even.\r\n\r\n \r\n ZF2 supports a variety of hydration strategies, which allow you to pass data to and from objects. The example above uses one that suggests a 1:1 mapping between the inputs and the object properties; other strategies include using ArrayObject, using class mutator methods, and more.\r\n \r\n At this point, you can hydrate an entire form, as well as individual fieldsets!\r\n \r\n You can provide custom annotations. While this feature is not documented yet, you can tell the AnnotationBuilder about additional annotation classes, as well as provide listeners for those annotations so that they can interact with the form construction process. As an example, one contributor has already used these features to utilize Doctrine annotations to inform the builder about the name of a property, as well as indicate validators. (Side note: ZF2 now uses Doctrine's annotation syntax and parser by default.)\r\n \r\n There are a number of features targetting collections, so that your client-side code can return arbitrary numbers of a specific fieldset type (e.g., collecting addresses for an applicant), and the form will be able to validate each. You can read more about those features from the author himself.\r\n\r\n\r\n These features are all now available starting with the newly released 2.0.0beta5 version, which you can grab from the ZF2 packages site.\r\n\r\n I'm really excited with the solutions we've created in ZF2, and even more excited to see people put them to use!\r\n','Starting in 2.0.0beta4, we offerred a completely rewritten Form component. In fact, it\'s not just a Form component -- a new component, InputFilter, was also added. InputFilter is a component that provides re-usable validation and normalization logic, and can be used with forms or your domain model. The Form component is basically a bridge between domain models/validation and the view layer.','admin',35,'Website Administrator',1,'y','','y','','','2012-12-03 11:35:27','2012-12-03 11:42:29'),(25,'2012-12-03 00:00:00','Why Modules?','Why-Modules','\r\n Source: http://mwop.net/blog/2012-04-30-why-modules.html
\r\n\r\n I've blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.
\r\n\r\n In the autumn of 2006, Andi asked me to spearhead a refactor of the Zend Framework MVC, prior to a stable release. The idea was to address the growing number of issues and feature requests, get it well-tested, and document it thoroughly before we were ready for a 1.0.0 stable release.
\r\n\r\n Late in that refactoring, a few folks approached me saying they wanted support for "modules". The idea would be to have self-contained directories containing discrete MVC functionality -- controllers, views, related models, etc. Additionally, they wanted routing to take into account the module, so that we could have controllers with the same "name", but resolving to separate, discrete classes.
\r\n\r\n The "solution" I came up with basically worked, but was quite limited. You could drop modules into a directory, which the front controller would scan in order to be able to resolve URLs of the form "/:module/:controller/:action/*". (You could also explicitly define a module in the route configuration if desired).
\r\n\r\n This mostly worked, until we introduced Zend_Application, at which point it fell apart. Why? Because we couldn't quite get bootstrapping to work. Bootstrapping the application was easy, but adding modules and their bootstraps, and sharing dependencies between all of them, proved to be quite difficult, and we never truly solved it.
\r\n\r\n Add to this the fact that the only way to get dependencies into controllers was via Zend_Registry or the front controller singleton, and the end result were modules that could never truly be shared or simply dropped into an application.
\r\n\r\n\r\n\r\n One of the very first requirements for ZF2, therefor, was to solve the module problem. The goals were fairly simple:
\r\n\r\n Modules should be re-usable. Developers should be able to drop in third-party modules easily, and immediately utilize them with zero or small amounts of configuration. Developers should never have to directly alter module code, ever, to get them to work in their applications; customization should be easily achieved via configuration or substitution.
\r\n
\r\n Why?
\r\n\r\n The goal of any good application framework or content system should be to make development of websites as easy as possible. Good systems make it possible to use as little or as much of the framework as needed, and to make extension of the framework trivial. This latter point is perhaps the most important aspect: the quality of any good application ecosystem can typically be judged by the amount and quality of third-party plugins developed for it.
\r\n\r\n If your framework is making you write boilerplate code to handle authentication for every site you write, or making you write code for common application features such as blogs, comment systems, contact forms, etc., then something is wrong. These sorts of tasks should be done at most a handful of times, and shared with the community.
\r\n\r\n The end-goal is to be able to pull in a handful or more of plugins that do these tasks for you, configure them to suit your needs, and then focus on building out the functionality that is truly unique to your website.
\r\n\r\n I'll give a concrete example. In parallel with ZF2 development, I've been rebuilding this very site. I've needed the following pieces:
\r\n\r\n How much of this functionality is unique to my site, other than the content? Pretty much none of it. Ideally, I should be able to find some modules, drop them in, and create some custom view scripts.
\r\n\r\n Which is what I did. That said, I developed several of the modules, but in some cases, such as authentication, I was able to grab modules from elsewhere. The beauty, though, is that in the future, I or others can re-use what I've created, and quite easily.
\r\n\r\n This kind of building-block development makes your job easier as a developer -- and allows you to focus on the bits and pieces that make your site unique. As such, I truly feel that modules are the most important new feature of ZF2.
\r\n\r\n If you're developing on top of ZF2 today, I have one piece of advice: create and consume modules. Share your modules. Help make ZF2 a productive, fun, collaborative ecosystem that allows developers to get things done and create fantastic new applications.
\r\n','\r\n Source: http://mwop.net/blog/2012-04-30-why-modules.html\r\n\r\n I've blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.\r\n\r\n History\r\n\r\n In the autumn of 2006, Andi asked me to spearhead a refactor of the Zend Framework MVC, prior to a stable release. The idea was to address the growing number of issues and feature requests, get it well-tested, and document it thoroughly before we were ready for a 1.0.0 stable release.\r\n\r\n Late in that refactoring, a few folks approached me saying they wanted support for \"modules\". The idea would be to have self-contained directories containing discrete MVC functionality -- controllers, views, related models, etc. Additionally, they wanted routing to take into account the module, so that we could have controllers with the same \"name\", but resolving to separate, discrete classes.\r\n\r\n The \"solution\" I came up with basically worked, but was quite limited. You could drop modules into a directory, which the front controller would scan in order to be able to resolve URLs of the form \"/:module/:controller/:action/*\". (You could also explicitly define a module in the route configuration if desired).\r\n\r\n This mostly worked, until we introduced Zend_Application, at which point it fell apart. Why? Because we couldn't quite get bootstrapping to work. Bootstrapping the application was easy, but adding modules and their bootstraps, and sharing dependencies between all of them, proved to be quite difficult, and we never truly solved it.\r\n\r\n Add to this the fact that the only way to get dependencies into controllers was via Zend_Registry or the front controller singleton, and the end result were modules that could never truly be shared or simply dropped into an application.\r\n\r\n Modules in ZF2\r\n\r\n \r\n One of the very first requirements for ZF2, therefor, was to solve the module problem. The goals were fairly simple:\r\n \r\n Modules should be re-usable. Developers should be able to drop in third-party modules easily, and immediately utilize them with zero or small amounts of configuration. Developers should never have to directly alter module code, ever, to get them to work in their applications; customization should be easily achieved via configuration or substitution.\r\n\r\n\r\n Why?\r\n\r\n The goal of any good application framework or content system should be to make development of websites as easy as possible. Good systems make it possible to use as little or as much of the framework as needed, and to make extension of the framework trivial. This latter point is perhaps the most important aspect: the quality of any good application ecosystem can typically be judged by the amount and quality of third-party plugins developed for it.\r\n\r\n If your framework is making you write boilerplate code to handle authentication for every site you write, or making you write code for common application features such as blogs, comment systems, contact forms, etc., then something is wrong. These sorts of tasks should be done at most a handful of times, and shared with the community.\r\n\r\n The end-goal is to be able to pull in a handful or more of plugins that do these tasks for you, configure them to suit your needs, and then focus on building out the functionality that is truly unique to your website.\r\n\r\n Building Blocks\r\n\r\n I'll give a concrete example. In parallel with ZF2 development, I've been rebuilding this very site. I've needed the following pieces:\r\n\r\n \r\n A handful of static pages (home page, résumé, etc.)\r\n \r\n A contact form\r\n \r\n A blog\r\n \r\n Authentication in order to \"password protect\" a few pages\r\n \r\n A few view helpers (github status, disqus display, etc)\r\n\r\n\r\n How much of this functionality is unique to my site, other than the content? Pretty much none of it. Ideally, I should be able to find some modules, drop them in, and create some custom view scripts.\r\n\r\n Which is what I did. That said, I developed several of the modules, but in some cases, such as authentication, I was able to grab modules from elsewhere. The beauty, though, is that in the future, I or others can re-use what I've created, and quite easily.\r\n\r\n This kind of building-block development makes your job easier as a developer -- and allows you to focus on the bits and pieces that make your site unique. As such, I truly feel that modules are the most important new feature of ZF2.\r\n\r\n Fin\r\n\r\n If you're developing on top of ZF2 today, I have one piece of advice: create and consume modules. Share your modules. Help make ZF2 a productive, fun, collaborative ecosystem that allows developers to get things done and create fantastic new applications.\r\n','I\'ve blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.','admin',35,'Website Administrator',1,'y','','y','','','2012-12-03 11:39:47','2012-12-03 11:41:51'),(26,'2012-11-01 00:00:00','test title','test-title','\r\n Lorem ipsum dolor sit amet, meis homero petentium usu te, nusquam quaerendum eum ad. Ex eum saperet inermis, eum ei velit animal accusata. Te sed summo affert liberavisse, ei dicit
\r\n\r\n facete sit. No nobis admodum usu,
\r\n\r\n
\r\n Nemore feugait sit cu, ex velit nusquam nam, eos ea idque sonet ancillae. Te ius magna dolorem, diceret menandri vel ne. Vim ex solet aperiam salutatus, vis ex quas harum efficiantur. Eum tollit appetere in, cu eam novum epicurei. Novum ocurreret sed ex, eam eu oratio aeterno aperiri.
\r\n Lorem ipsum dolor sit amet, affert mollis impedit cu eos, salutandi iudicabit mei cu. Mel eu tritani omittam suscipit, feugiat detracto persecuti quo eu, modo tamquam te nam. Solum delicata ex vix, ne per quot civibus. Wisi definitiones per ut,
\r\n\r\n
\r\n Has et quod mentitum explicari, ea eam ferri facilis. Cu eum vide molestie, quo ea wisi liberavisse. Eos tollit ponderum consectetuer ea. Pri ex affert atomorum, at aperiri voluptatum sit, te eius equidem definitionem quo. Id per vero duis maluisset.