Another question to go along with the 403 one: If I use decorators to
create the json config object, then the form can't be used as a normal
html form. I was thinking along the lines of something like the
decorators but only used in the json context - like jsonDecorators. So
on the form I would call $form->toJson(); to create the config to send
back as ajax. But the form could still be used in a normal view as all
forms are. Does this sound okay?
Deanna Bonds wrote:
Trying to finish up the design and prototype of the action controller
helper. The current name is enableAjaxExtJS, and you can pass it
options in the direct call. Options are a different context key,
either a list of methods to enable, or a list of methods to exclude
(the default is to enable context switching on all *Action methods),
and option to enable or disable throwing 403 errors if not an xhr
request. By default I have the 403 errors enabled as that seems to
be how I think most ajax routines. If you think it should be
otherwise I can reverse that. Also, I want to be able to enable or
disable the throwing of 403 errors on an action by action inside the
action method. If going with the default as enable as I have it now,
what would the best method name be to enable it that would make the
most sense in zend framework context.
disable403() That kind of requires the user to realize they aren't
getting normal template processing because of the 403 error.
enableStandardTemplateProcessing() Very long name
enableViewTemplates() not quite as clear but shorter
or something else. If going with 403 errors off by default then I
think enable403() would be be clear enough.
