As always, thank you for your concise and informative responses as
well as all of your hard work on ZF. Much appreciated!
So what I gather is that the way
var values = diji.byId('myForm').attr('value');
.. works isn't so much a function of using ZF to create the form, but
a function of how dojo behaves period. I guess I knew this, since I
experienced this behavior on a dojo-enabled form I wrote purely from
markup (sans Zend_Dojo_Form) and containing an Editor widget as well.
I just wanted to be sure that I wasn't missing some option that could
be passed into the Zend_Dojo_Form_Element_Editor constructor to
achieve the behavior I was looking for.
> This is also true if you want to use
> dijit.byId('some-form').attr('value') -- the element simply will not be
> present, even though it _is_ in the form, because it is not a
> traditional form element.
Ok, got it. I forget this sometimes.
> One thing you could do is to extend dijit.form.Form to allow specifying
> Editor elements in the constructor (or via attributes), and then
> create a getValues method that gets both form values as well as the
> Editor values.
I haven't extended dijit.form.Form yet, but I have done something
simpler: in the dojo.connect() that listens for the form submit, I
check for a valid form as well as a valid Editor field and take action
depending on the results. While I feel fairly proficient at writing
dojo apps (hardly consult the api reference anymore), I haven't tried
extending any dojo widgets yet, although I suppose that task isn't as
arduous as I am making it out to be in my head. I suppose that if I
did that, I would then have a reusable form widget that I could plugin
any time I needed to have the Editor in a form....something to think
about. At any rate, I appreciate the explanation and know how to
proceed. Thanks again!
--regards,
Nathan Garlington
www.tandrtrailer.com
没有评论:
发表评论