Staying with in the DotNetNuke 3.2 framework I'm attempting to find the best, simplest solution for making callbacks/RPCs/Ajax requests.
The biggest obsticles seem to be staying within the DotNetNuke framework recommendations:
***
1. Default.aspx - One page, one entry point
Staying with this is great because it handles security for me and all the DotNetNukish stuff.
***
2. Stay away from custom HTTPHandlers
Correct me if I'm wrong; to conform with DNNs "module installation packages" the web.config file can't be altered by DNN's "Upload & Install" method of distributing packages. I have looked in solutions such as JSON's Jayrock and it requires me to stick an HTTPHandler in the config file to operate. I'm not even sure if many hosting environments will allow this!
3. Google GWT
So sleek, so simple, so fast, so not IIS.
4. Telerik Ajax suite
Keeping in mind that there are WebControls loaded dynamically. Telerik's solution for this is to place them into a panel so it has a control that will produce HTML (I assume so it can get an ID from that control). I would like the controls I'm making to be somewhat self contained & able to be reused anywhere under the umbrella. I don't want to "need" to place them into a panel every time.
5. Use "DotNetNuke Client API Client Callback" in the WebUtility.dll
Testing with this method; the use of dynamically loaded control (LoadControl(cb_checkBox)) seems to mess DNN's method of performing the callback. The GetCallbackEventReference(Page, "blah", "blah", "blah", ...) can't give me a Control.ID because the control does not yet have one. The little JavaScript string is passes back then lacks the right stuff to make the call from the client later. Even if it had the right stuff... The control would not exist in the page control hierarchy untill after DNN goes search for it with the FindControl recursive function it uses to handle the callback request coming in.
6. Not callback, not RPC, not Real-Time
Looked at the ClientAPI DNN comes with to pass the stuff back in hidden forms on the pages themselves. This would work for me if the user posted back to the same page every time; but it's possible they will not sometimes. Then things that put in that "hidden forms bucket" are lost. I considered making the Default.ascx page being responsible for this that way that form would always be processed; that just would not conform to the DNN standards.
In summary; I'm just looking for a balance of what would be best for knowing what the user is clicking & typing making that information avaliable to all modules in my DNN solution(s). I like all the DNNish stuff that DNN does; but it just seems to be a pain when trying to implement something like this.