QProxyControl within jQuery

Login or register to post comments
3 replies [Last post]
Offline
Joined: 01/09/2008

Hey folks,

Still experimenting with the v2.0 branch, I came across an issue with the QProxyControl.

The control renders the javascript inside a predefined tag, eg:

<input type="button" <? $this->prxControl->->RenderAsEvents(1); ?>/>

Which would render something like:

<input type="button" onclick="qc.pA('controlid', 'parameter')"/>

Now, with jQuery , we have replace the routines that render the javascript: no "onclick" any more, but .bind()!

2 ways to solve this (or maybe more, but I currently see 2 :) )
a) the old way, thus rendering onclick, and thus taking back some of the functionality that was there before, and also keeping full backward compatibility
b) make sure that the html control we are rendering the proxycontrol into has an id, and pass this id along in the RenderAsEvents() function to make sure that we can then do something like

<input id="mybutton" type="button" <? $this->prxControl->RenderAsEvents("mybutton", 1); ?>/>

which would the render:

$j('#mybutton').bind(qc.pA('controlid', 'parameter'));

Thoughts?

Thanks,
Kristof

Offline
Joined: 07/10/2008

Are you playing with the exp. branch I made? I don't think I got that far into the process if you are using my version of the old experimental branch.

What i didn't plan for in the experimental branch was controls that haven't been rendered on the page, or are shown through ajax (that have javascript functionality).

We would, i think, would like to get away from the inline javascript on controls, but rendered in a d.ready, the example above would obviously need to be fixed for this approach.

alex94040's picture
Offline
Joined: 11/06/2008

Kristof, I think this is a fine example where we can break backward compatibility slightly for the sakes of a cleaner model. Just make sure that if you go with approach 2, you have code in the RenderAsEvents() function that checks that the mandatory parameter(s) are actually not null.

Offline
Joined: 01/09/2008

thanks, this gives me some direction to work in! :)
What you both are suggesting is in line with what I had in mind: get rid of the inline javascript! Just wanted to get confirmation that this would be ok.

Thanks again,
Kristof