Re: [fw-mvc] Re: [fw-general] Calling Dojo

-- Naimesh.Trivedi (Gmail) <naimesh.trivedi@gmail.com> wrote
(on Monday, 17 August 2009, 04:52 PM +0530):
> 1) Can you please give some example on your following saying :
>
>
>
> "This allows me to both do initial display of the forms from my application
> views as well
> as to fetch them dynamically using XHR -- which can be *very* fast. I've
> then created Dojo helpers that can take a JSON object of form error
> messages and display them above the form."

Let's say I've created a custom module named "foo". Within that, I might
create a resources directory, into which I place my forms.

>From within my client-side code, I can then fetch these with
dojo.xhrGet():

dojo.xhrGet({
url: dojo.moduleUrl("foo", "resources/FooForm.html"),
handleAs: text,
load: function(data){
dojo.place(data, "foobar");
}
});

The above would fetch foo/resources/FooForm.html, and have it replace
the element with id "foobar".

Within my server-side code, I would then add the resources directory to
my view scripts:

$view->addScriptPath(APPLICATION_NAME . '/../public/js/foo/resources');

which then allows me to inject the form using:

echo $this->render('FooForm.html');

As for the JSON error messages, I have created a widget for this that
uses a dojox.dtl HTML template to loop over the data returned
(basically, the result of $form->getMessages() passed to
Zend_Json::encode()). I'll post this somewhere soon for you to look at.

> 2) Well I found directly using digits in view gives more control on how and
> what to display, may be my lack of knowledge in customizing using directly in
> form.

Any attributes you can declare in Dijit markup may be passed to the
form elements as well -- as I noted, the chief reason to use the form
elements is to get the filled in values and errors.

> -----Original Message-----
> From: Matthew Weier O'Phinney [mailto:matthew@zend.com]
> Sent: Monday, August 17, 2009 2:39 AM
> To: fw-general@lists.zend.com; fw-mvc@lists.zend.com
> Subject: [fw-mvc] Re: [fw-general] Calling Dojo
>
>
>
> -- Naimesh.Trivedi (Gmail) <naimesh.trivedi@gmail.com> wrote
>
> (on Tuesday, 11 August 2009, 08:01 PM +0530):
>
> > What difference would be in performance, if using dojo in a class like :
>
> > class Default_Form_Prjhead extends Zend_Dojo_Form and declaring all dojo
>
> > elements below it
>
> >
>
> > against directly using in view - form.phtml as
>
> >
>
> > <div class="formRow">
>
> > <label for="firstName">First / Last Name: </label>
>
> > <input type="text" id="firstName" name="firstName"
>
> > dojoType="dijit.form.ValidationTextBox"
>
> > required="true"
>
> > propercase="true"
>
> > promptMessage="Enter first name."
>
> > invalidMessage="First name is required."
>
> > trim="true"
>
> > class="mytextbox.dojoInputField"
>
> > style="width: 10em;"
>
> > />
>
> > </div>
>
> >
>
> > According to my knowledge the latter approach using directly in view gives
>
> > more control, but not sure of performance. Do I need to custom build my
>
> > dojo.js using builder ?
>
>
>
> The benefit of using Zend_Dojo_Form and the various Dijits supported in
>
> ZF is that you also get server-side error messages and the ability to
>
> set the values for free. Without this, you have to hard-code that
>
> functionality into your form.
>
>
>
> That said, my typical pattern lately has been to *prototype* with
>
> Zend_Dojo_Form, and then, once I'm happy with the forms, capture them to
>
> client-accessible files within my custom JS module. This allows me to
>
> both do initial display of the forms from my application views as well
>
> as to fetch them dynamically using XHR -- which can be *very* fast. I've
>
> then created Dojo helpers that can take a JSON object of form error
>
> messages and display them above the form.
>
>
>
> This leads to a little more work if you need to change forms later, but
>
> allows for more flexibility for Ajax applications, as well as better
>
> performance (static files versus dynamic PHP files).
>
>
>
> --
>
> Matthew Weier O'Phinney
>
> Project Lead | matthew@zend.com
>
> Zend Framework | http://framework.zend.com/
>

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/