Re: A Javascript QuickForm Renderer?

From: 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

« previous php.pear.general (#21887) next »