Re: A Javascript QuickForm Renderer?
| From: | Justin Patrin | Date: | Fri, 11 Nov 2005 03:38:50 +0000 |
| Subject: | Re: A Javascript QuickForm Renderer? | ||
| References: | 1 2 3 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-21887@lists.php.net to get a copy of this message | ||
On 11/10/05, Ken Restivo <ken@restivo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Nov 10, 2005 at 01:17:14PM -0800, Justin Patrin wrote:
> > On 11/10/05, Ken Restivo <ken@restivo.org> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Has anyone given any thought to, or started work on, a JavaScript Renderer for QF?
> > >
> > > I'm trying to add some JSON functionality to my application. I'd like to
> > > have any sub-forms built on the server side, as requested by the user, and ship them to the browser
> > > via JSON. This would need to be on-demand because some of my forms have quite a few sub-forms, which
> > > then can nest quite deeply, and it wouldn't be OK to render them all and hide them on every
> > > page.
> > >
> > > I prototyped this using QF's default renderer, rendering the form as HTML and
> > > shipping it to the browser, and using getElementById('somediv').innerHTML =
> > > subFormHTMLFromJSON to inject it into the page. And it worked!
> > >
> > > Sort of. Except for one fatal problem: the DOM doesn't seem to know about the
> > > stuff I inject using this innerHTML hack. And some of my my custom elements have JS which requires
> > > accessing other elements through the DOM. Drat.
> > >
> >
> > That's very strange. I'm almost 100% positive that I've seen this work
> > myself. What browser were you testing on?
> >
>
> Ah. OK, I think my problem had to do with execution order. It does
> indeed show up in the DOM even using the innerHTML method. Cool.
>
As I thought. Glad to hear it worked out.
> > > So, what I want to do instead, is have QuickForm render the form by generating
> > > JavaScript code instead of HTML: basically a series of createElement() and appendChild() calls.
> > > Then, I would Services_JSON::encode() it and ship it over to the browser, and instead of
> > > innerHTML'ing it, I'd eval() the supplied JavaScript, and my elements would get added to
> > > the DOM properly.. Or that's the idea, anyway.
> > >
> > > Has anyone done anything like this? Or know of any reason why it wouldn't work?
> > > I didn't find anything through Google. Anyone else interested in this kind of thing (and
> > > ideally helping with it) or would I be going it alone?
> > >
> >
> > Sounds interesting but also fairly time consuming. You wouldn't just
> > be making a renderer, but a (nearly) fill QF in JS. Using innerHtml
> > *should* work. However, if it doesn't you could try using an iframe
> > which you point to a script which outputs the sub-form. This will
> > almost certainly work. Or you could make a popup which holds the
> > sub-form (this was my first thought for sub-forms, but I went with the
> > "static" solution). A third option would be to get the output of an
> > HTML renderer then parse it and create the DOM objects yourself. Of
> > course, this is what the browser is supposed to be doing with
> > innerHTML. In fact, it has to be or it couldn't display it.
> >
> > I definately suggest looking further into your DOM issues. It should
> > work. As a last resort you could always load the content in an iframe
> > and them DOM your way into it and move/copy the element(s) into your
> > div. ;-)
> >
>
> Always good to know that there are multiple complicated solutions to
> simple problems. But in this case your first, simple suggestion was
> sufficient.
>
Thanks. I pride myself on being able to think of complicated solutions
to simple problems. It's what allows me to hack up scripts when I need
to. ;-)
--
Justin Patrin