Zend Framework 2, like all great PHP frameworks, provides thorough infrastructure for creating forms in your application. Whether that’s form objects, form elements, fieldsets, validation groups or that they interact with so many other components in the Zend Framework 2 default libraries. But how do you handle external dependencies?
Do you need to use different elements of a Zend Form, in multiple locations? Are you keen to reuse the same form class and avoid code duplication but don’t know how? Come learn about validation groups.
In today’s tutorial come and learn the new HTML5-specific form elements available in Zend Framework 2. You’ll learn how they work, how to use them, what they look like.
In Zend Framework 2, so much has been changed, updated and improved - with Forms receiving a lot of attention. In this post, I show you a simple, flexible and powerful approach to compose and use them everywhere in your applications.
In today’s post, we look at one of the simplest and most effective components of the Zend Framework that allows us to create extendable and extensible Zend Framework applications - Zend Application Resource Plugins (combined with the Strategy Pattern). If you want to ensure your apps can grow without heartache, read on.
If you’ve been using Zend Forms for any length of time, you’ll know just how flexible and configurable they are. There’s not much that you can’t do with them, But it’s not always easy and there are catches. Today we look at ensuring that module-based Zend Forms using the ViewScript decorator can always be initialised no matter what.
Welcome to the fourth and final part in the Zend Form Mastery with Zend Config series. Previously we looked at the basic form options, element and form wide prefixes, filters and element options. In this installment, we’re going to look at configuring Zend Validators via our XML config.
– Part 3 Standard Form & Element Options This is a Multi Part Series. Check out the other parts: Part 1 - Custom Filter Paths Part 2 - Core Form Configuration Part 4 - Configuring Zend Validators Options We’ve looked at custom form filters and we’ve looked at the core form configuration. But what about the other form properties? What about: setting an element as readonly an element as required ignoring an element and love them or hate them, what about decorators Element Options Outside of the options that we’ve looked at previously, there are a number of other options that we can consider implementing when configuring a Zend Form.
Today we move on in learning how to configure the basics of Zend Forms, such as action, method, enctype, accept, accept-charset et al with Zend Config XML. It couldn’t be simpler.
When you’re working with Zend Form you keep your configuration as much out of code as you can - right? Well, if you’ve been working withZend Form for more than a little while, you know that Zend Config really makes that pretty simple - well, some of the time. In this series we look, comprehensively at how to do it all with Zend_Config.
Let me describe said situation for you; The user has a list of items and they’ve chosen to delete one. Given such a volatile action, you want them to doubly opt-in and confirm that they want to do this.
The last thing you want your user to feel, after they’ve clicked the delete link, is “NO WAAAAAAIIIIT! I didn’t mean to do that”. So the user clicks &’delete&’ and is directed to a confirmation page (which is rendered with Zend Form). There are two buttons on the page; the first is “Delete Item”, the second “Cancel”.
If the user clicks either button, the form submits to itself, where the value of the button clicked is determined. If the user clicks “Delete Item”, then the deletion is carried out, deleting the item from the datasource. If the user clicks “Cancel” the user is returned to the list of items they were previously viewing, the item is not deleted and the user is provided a message, confirming the non-deletion.