Callback solution for dynamicly loaded DotNetNuke controls

[superbee76]

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 GetCallbackEven tReference(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.

[Mark Rae]

<su********@gma il.comwrote in message
news:11******** **************@ d30g2000prg.goo glegroups.com.. .

The biggest obsticles seem to be staying within the DotNetNuke
framework recommendations :

You're absolutely right! DNN *only* works so long as you *never* want to
move away (even slightly ) from the defaults...

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.

Forget it if you want to do any serious development...
--
http://www.markrae.net

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

superbee,
you are making a post about an ASP.NET product that is written in VB.NET -
to the C# language newsgroup.
Try the asp.net newsgroup, which is a much more appropriate venue.
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"su********@gma il.com" wrote:

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 GetCallbackEven tReference(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.

[superbee76]

Wrong group for this posting; my fault. I was in the mindset of C# at
the time because I was writing my modules in that.