Zend and jQuery - Forms composed from many actions

I am about to set sail on some complex web pages and forms in Zend. Since a lot of this will be new territory for me I am hoping you can give me some feedback on my approach before I start.

The information I am working with is typically 1-n, for example "1 organisation has n products". It's the child part of this equation that I am working on. In essence, I want to enable a user to add, view, update and delete children from a single URL such as mydomain/products/index.

Note that a user can have either 'member' or 'admin' privileges.

The key components I see are:

• Zend ACL
• an extended ActionStack Action Helper
• the AjaxContext Action Helper
• jQuery

Here's how I see it working:

• The ACL is configured early (as a resource plugin or an early-running front controller plugin)
• The requested action (e.g. /products/index) uses 开发者_开发知识库the extended ActionStack Helper to push actions to the stack
• The extended ActionStack Helper consults the ACL before adding the action to the stack (calling isAllowed())

This should get the initial page loaded. I am thinking that, for duly privileged users, it will include a table of all products, complete with columns for 'delete' and 'edit' links, plus a 'product add' form at the bottom of the table.

When the user click on a link:

• jQuery handles the event and sends an XHR request to the specific action (e.g. /products/add)
• the specific action (with appropriate contexts enabled), returns the appropriate response
• jQuery needs to manipulate the DOM to incorporate the new content

Does this sound about right? What would you do differently?

I have not used the ActionStack or AjaxContext Helpers before and have limited experience with jQuery. It all looks reasonably straightforward though.

Your thoughts are much appreciated!

You don't need the action stack in this case. The action stack is to dispatch multiple actions during one request. What you have here is "just" a products/index action which loads all available products (the view might render that into a table). All other actions are dipatched at a later moment, by a new (XmlHttp or not)Request.

What we've done in the past is using modals for some simple forms. The user clicks on "add product" and jQuery performs an XHR towards products/add. This action is ajax enabled (ajaxContext) and returns only the form without the layout. This response is rendered as content of the modal dialog. The modal has two buttons, one to submit the form and one to cancel it. The cancel is simple (see jQuery documentation, just close the modal). The submit triggers a submit for the form inside the modal and closes the modal afterwards.

With this setup we're pretty flexible. Also you can use <a> elements with additional arguments to render the modal:

<a href="products/add" data-title="Add a new product" data-submit="Add product">Add product</a>

We use the data-title to render the title for the modal and the data-submit for the value of the submit button. If you have ACL implemented, the XHR can look at the response code. For a 403 status, the content is simply a message saying this is a mistake and the user shouldn't be allowed to add a product. Actually you shouldn't have the link "add product", but it's imho better to implement the 403 status check as an additional measure.

What's next to tackle might be your 1:m relationship. For example, you add a product at the products/add page. There you have a <select> to choose the organisation from. Right after the <select> there is an "or add a new organisation" link. This link behaves like described above: modal, XHR, ajaxContext. After form submission, you also listen to the response. You can implement your action such it returns a JSON string after it successful persisted the organisation into the database. The JSON is sent back to the browser and fetched in the response of the XHR. You write a piece of code that takes this JSON data (eg. it is an organisation.id and organisation.name), inject it into the select (<option value="id">Name</option>) and select that option.

This method is flexible, can be made generic and is not really difficult to implement. The only part you need to be aware of are the form errors. After a POST, the form might be invalid. This means the response can either be a JSON return or html with the form and the error messages. For the latter, you need to replace the content of the modal with the response and let the user try again. A small catch but yet a very important one.