Reputation: 1128
I am making a new version of an "old" software based on the Zend_Frameword 1.x, this project use zend_form to create versatiles forms I like this aspect of the code, and i'd like to keep it.
But I need to be cross domain and to render the html with javascript, so I'd like Zend_Form to render in JSONP.
on the past I already experience the hard to understand decorators of zend_form and i don't think that I can use them to render in JSON, so, I think that the only way to go is to extend Zend_Form, to implement my own render method, but event so, I have the feeling that it won't be easy...
I'm this afraid of Zend_Form that I am thinking that maybe rendreing the form in html and parsing it on the javascript side to create a structure sufficient to then use it with handlebars (the javascript template engine) would be easier
Upvotes: 0
Views: 54
Reputation: 14184
Parsing html seems suboptimal to me.
Your initial idea - creating your own form class extending Zend_Form
and adding a renderJsonp()
method - seems a pretty reasonable approach. In the simplest case, your rendering could extract the form attributes and then iterate over the elements, extracting their attributes.
However, remember that a Zend_Form
instance is more than just a list of form attributes and elements with their attributes. There are potentially display groups (typically representing html fieldsets) and validators attached to form elements. Also, even if you do not change the decorators used to render the form, they are part of the rendering. A json representation of the form that does not reflect those decorators would probably render into html differently than you experience when Zend_View
is responsible for the rendering in a view-script.
While it may be possible to have that displaygroup and validator information reflected in the structure of your json output, it seems unlikely that you would be able to easily automate creation of client-side validation that perfectly parallels that on the server-side side.
One approach I have seen is to have your client-side front-end make an AJAX request to a specially defined route that renders the full html of the form. While I am not a fan of this approach, it does have the advantage that the form remains essentially DRY, all the information required for rendering the form resides back on the server side but is still available to the client. The only thing missing is extracting the server-side validation for use on the client-side.
Just thinking out loud, so not a great answer, but it seemed too long for a comment.
Upvotes: 1