Custom Modules

Re: AJAX and DotNetNuke

databasedude — Sun, 18 Jun 2006 14:07:08 GMT

This may come as a surpriese to anyone who has looked into the various AJAX technologies that are available, but over the past 4 months I've developed an AJAX technology for ASP.NET 2.0 that instantly AJAX-enables an entire website. Gone is the need for any AJAX wrappers or Javascript or special tags or learning curve. Gone is the need for your pages to inherit from a special AJAX base page. Gone is the need to make any changes whatsoever to your web pages or the way you program(unless you still use code blocks such as <% ...%> as in the classic ASP days, in which case you will need to replace these with some sort of control like a literal control).

You simply drop the .dll into your bin, add a few lines to your web.config and add one other folder and your website is instantly AJAX enabled. All postback events are automatically replaced with callback events on the fly. Javascript is invisibly rendered to update only the controls on the page that have changed in response to the callback. Even the viewstate is updated, although it is kept on the server in order to minimize the amount of data that is transmitted during callbacks and maximize the speed of round-trips. Lets say you have 30 different controls on a web page, including several GridViews, dropdown lists, text boxes, buttons, etc. and you click a button that makes changes or updates to 5 of the controls. Only those five controls are updated on callback. It works like magic.

Now let me tell you how I stumbled into the idea for this. As you know, it was Google that in the last couple of years popularized AJAX technologies through GMail and Google Maps. While building a asp.net server control wrapper for the Google Map API this past winter and spring, I wanted my map control to interact with other controls on a web page using AJAX, but I wanted to do so automatically without using special AJAX wrappers etc. I wanted to update other controls on a web page through click events on the map, and I wanted to make changes to the map (plot points, open info windows, draw lines, etc) by clicking other controls on the page and without doing a postback. During development of my Google Map server control I had become intimately familiar with Javascript and AJAX and soon figured out a way to accomplish this goal. I built this capability directly into my Google Map control so that the entire web page became instantly AJAX enabled simply by dropping my map control into the web page.

I then recognized the potential of this for all web pages, even those without my Google Map control. I then set out to extract the AJAX component from the map control and make it a separate technology that could AJAX enable any web page with any set of controls. I accomplished this in a matter of several days, in essence. It then took me another six weeks or so to refine the technology to work with the pecuiarities of many different controls. What I ended up with is a very powerful technology that adds AJAX capabilities to an entire web site without the need to change the way you program.

You say, "this sounds too good to be true!" I know it does but it is true. It works as "advertized" here...except for DotNetNuke sites. You knew there was a catch, right? The reason why my technology does not yet work for DNN sites is stated above. DNN still uses code blocks such as <% ...%> which are to my AJAX technology like kryptonite to Superman.

This is because code blocks are not controls. My technology needs controls with client-side ID's in order to emit html and get changed during callbacks. If only the core team replaced all code blocks with controls such as literal controls or whatever, then I could instantly AJAX enable every DNN 4.x website without a hundred different hashups that each module developer is making to AJAX enable their modules.

That's my two cents.

Re: AJAX and DotNetNuke

brian_c — Fri, 09 Jun 2006 17:37:09 GMT

I looked through the clientAPI docs and then went and renewed by telerik subscription :)

The hours I will save writing code is worth the renewal price.

I really think the clientAPI is a great addition but it goes too far into the programming side and hinders quick usage.

Re: AJAX and DotNetNuke

tuanhawaii — Fri, 09 Jun 2006 14:02:15 GMT

kingdona:
Hello all. I would first like to apologize that I have not responded to this sooner. I had asked a couple of people to send me a link to this post and that did not occur ;-) I just found it searching today (apparently I am not very good at searching). I would first like to go ahead and throw out a disclaimer about Mr. Shaw's payment of $100 to me. I at first refused the money and asked that he just do a sort of "pay it forward" and help someone else along the way which he has done and I appreciate it. I have been helped and have tried to help numerous people in these forums and other forums I have particpated in, and have never expected payment or been asked for payment. Mr. Shah however insisted I take the money which has been donated to sponsor a local flag football team for 5-6 year olds. Now with that out of the way...

I have a simple Hello World sample using Michael Schwarz's Ajax.NET component. It is very basic, not fancy at all. If it will help anyone I will be more than happy to send it your way to include the source (currently VB.NET and I will very soon have the C# version for you folks who would prefer that). If it will help someone get started that is great. I am not an expert on AJAX or anything but will be more than happy to participate in discussion concerning what I know and hopefully learn a little in the process as well.

Please let me know if you would like the bundle and I will send it your way.

Regards,

DK
AgileWise - Software at the speed of business.

I'm sorry for asking for the code this late, but I really want to see it,.
Can you send me a copy at tuanhawaii@gmail.com.
I really appreciate this.
Best Regards,
Tuan

Re: AJAX and DotNetNuke

ryedin3 — Wed, 21 Dec 2005 15:29:16 GMT

Check my posts in this thread: http://forums.asp.net/ShowPost.aspx?PageIndex=3&PostID=1035364#1035364

Make any user control into an AJAX control and let the server handle the markup generation and data processing. Each control can be it's own autonomous entity on the client, and you can extend the model to expose public interfaces/events for interacting with other controls on the page.

Since I posted the above, I have really expanded the model for my project so it is extremely robust. If I get some time I may elaborate on that expansion but the information in the above post is enough to get you going.

Re: AJAX and DotNetNuke

DeveloperMCDBA — Wed, 21 Dec 2005 15:15:38 GMT

http://forums.asp.net/1148241/ShowPost.aspx#1148241

So, Jon Henning has AJAX capabilities in the new release or two. Any of you in this thread using it? I haven't got it to work for me yet (the hello world sample module download) but I'm determined to get it.

As peter donker pointed out, there are many ways to implement AJAX, but if there is one main way to do it. it seems like the way to go.

Since I have licensing to Component Art's controls I tried and successfully got their callback control to work, but the call backs take around 6 seconds! yuck...where CA's samples are lightening fast. I was thinking since everything goes through default.aspx, that dnn was processing things in the page it really didn't need to....http://www.componentart.com/forums/ShowPost.aspx?PostID=14396

anyhow....I'm wanting to get the dnn example to work since it was intended for dnn. I'd like to hear from other's experiences here.

thanks!

Re: AJAX and DotNetNuke

ryedin3 — Tue, 25 Oct 2005 18:48:19 GMT

Jon, I read through your document. I like what you've done. It's not a typical generic Ajax library-esque implementation, and thus does not apply to my statements. That is one specific control, and IMHO you do a fine job with it. My post was not directed towards you nor was I implying your methods are wacky...

My whole rant is against the mentality that a lot of people seem to have about recreating the wheel on the client and representing their business objects there in complex abstractions in javascript. Serializing object collections, sending that to the client, then spinning through and deserialzing, then constructing entire controls there on the client.And doing all that for the sake of saving a postback.

I see so many people asking how to use ajax to create something like a sortable, pageable datagrid without having to do a post back. Then people reply saying "Well, what you gotta do is install such and such AJAX library, which will automatically return all your data types and objects as javascript abstractions (or JSON pseudo-objects) but you gotta remember to put certain attributes above your methods and call the AJAX initialization methods in the Page_Load and oh yea don't forget to set up a special HTTP handler in your web.config file and you'll have to create serialization methods for really complex objects, then you can use all that returned data on the client, then you have to use the DOM to create a collection of table rows and cells and create all the javascript that handles all the processing and different sorting and paging permutations...".. No... use the server control called DataGrid. Use the XMLHTTP object to request the control from the server... and javascript to put the returned HTML on the page (and by the way my method does not return any viewstate stuff, just the markup). No special library needed.

Re: AJAX and DotNetNuke

ryedin3 — Tue, 25 Oct 2005 17:11:38 GMT

Ok, sorry for my use of that word... not trying to start a war :)

What I'm trying to get at is people should be using javascript to extend the server control's functionality (I did use those exact words in my original post in that linked thread), and not to re-create functionality that is already available on the server. If you use that "give me just the fabric and I'll sew the dress" approach on the client, then you lose a lot of benefits of the server, and you cross application design boundaries in the sense that the client, IMHO, should not know or care about the underlying data structures of your application.

Yes, the representation of the data CAN be smaller than the HTML used to display the data, but it can just as easily be the other way around too, especially if much of the data is hidden as in a paginated datagrid. So I guess you can build your DataGrid-like control in such a way to expose client events which re-query the server for just the page of data that is needed... but then once you get it you still have to parse it all out and redraw the grid to show the next page. I would argue the performance gain on that operation would be minimal if any.

Blindly passing data to the client, and then only relying on the client to process it (which can be just as slow or slower than a callback to the server to get the HTML for the control) is what I think is wacky. I say do as much of the work as possible on the server. When your control needs to do something that simply cannot be done on the server, like drag and drop or some other such interface type magic, use javascript then.

Re: AJAX and DotNetNuke

jhenning — Tue, 25 Oct 2005 16:19:41 GMT

I guess you are calling me whacky now... My reasoning behind the design are clearly laid out in this document. I'll include the relavant parts in case you don't want to review all 30 pages.

Before diving into the navigation abstraction it is important to have a handle on some of the design decisions behind the DotNetNuke WebControls. Unlike most ASP.NET controls the DotNetNuke WebControls are designed to send the XML representing the nodes, rather than the HTML to and from the client. This has the following advantages.

² Performance - Server Load and Bandwidth

It is usually a safe assumption that the representation of the data is much smaller than the markup to display the data. Stated another way, the XML for the data will almost always be smaller than the HTML for the rendering of the data. Thus sending down the XML yields smaller output in your HTML stream.

In many controls the maintaining of the Node's state is required. This is typically accomplished by placing the information in viewstate. Which when you break it down this is usually the same information in the data (XML). So what ends up happening in the control is it not only sends down the HTML for the data representation, it also sends down the data and the unreadable format known as viewstate. Thus, the HTML output is now twice as large.

If your data is somewhat static, it is possible to persist the data to an xml file and reference it in a browser like IE and have the data get cached on the client (just like an image or js file). Thus, future visits to the page will not require any data transmission at all.

² Functionality - Being able to render your controls on the client when given nothing more than the XML data allows for many more possibilities to implement client-side functionality

For example, the Solution Partner’s Menu Module released for DotNetNuke allows the menu to be completely customized (i.e. add/update/delete nodes, style changes, etc.) in a WYSIWYG mode. To leave the control's rendering up to the server would require round-trips to the server whenever the user wished to see the results of changing properties.

Enabling an on-demand loading of child nodes becomes quite simple. Simply make a client callback to the server passing the current nodeID, have the server return the XML for the child nodes, append the XML into the existing data, and re-render the control.

Typically controls that render on the client provide a much richer client object-model. This generally happens because the developer already spent much of the time getting things to render client-side. To add additional properties, methods, and events is not as far of a stretch.

That said, I would not think that just anyone should be writing code on the client to create controls, instead it should generally be up to the control developer to handle that. In the customization cases, the control should expose some simple events that the developer could hook into. This gets into the idea of having a rich object model available to the developer on the client.

Re: AJAX and DotNetNuke

ryedin3 — Tue, 25 Oct 2005 15:18:13 GMT

Anyone interested in an easy to use, generic AJAX framework that can be used to deliver any controls to a page, check out my response to the same thread jhenning cited.... http://forums.asp.net/ShowPost.aspx?PageIndex=3&PostID=1035364#1035364

You want a datagrid with sorting? easy. And you don't have to write all the crazy javascript to make it happen. People who use Ajax that way (query for raw data and then use javascript to parse it and rebuild whole controls on the client) are plain whacky, whacky I tell you. Use the server, get the HTML and put it into a div on the page... I explain the whole process in the above thread.

Re: AJAX and DotNetNuke

oledave — Thu, 08 Sep 2005 21:52:53 GMT

That grid is amazing and gorgeous... anybody interesting in helping me add AJAX capabilities to the Advanced DataGrid? I plan on borrowing styling ideas... 3d backgrounds for the headers... why didn't I think of that...

Re: AJAX and DotNetNuke

donker — Thu, 08 Sep 2005 20:38:52 GMT

The whole UI suite of CA is just awesome. It uses Ajax whenever possible. Did you check out the new grid control they have? http://webui30.componentart.com/grid/features/ajax_grid/WebForm1.aspx The next best thing since sliced bread IMO. Having said that, I'm waitng for a DNN callback solution to use for free modules.

Re: AJAX and DotNetNuke

nokiko — Thu, 08 Sep 2005 13:19:43 GMT

well ive played with the telerik callback when it was in beta and its great, especially the ideas they have about integrating it with there current controls, the generic callback is nice for standard fucntionality but they also have a nr of standard asp.ent form objects like textbox radiolist etc and made these to use the callback as well so you can create very dynamic interfaces and OPA's

If you combine it with there latest rad.dock you an create some very cool UI apps

http://www.telerik.com/r.a.d.controls/Dock/Examples/MyPortal/DefaultCS.aspx

or check out this super slick store with is a combination of both the callback and the docking component

http://www.telerik.com/r.a.d.controls/Dock/Examples/ShoppingCart/DefaultCS.aspx ( imagine catalook looking like this , suzanne :)?

Re: AJAX and DotNetNuke

Ed_DeGagne — Thu, 08 Sep 2005 12:59:55 GMT

The CA component does raise an IsCallBack event on callback, much like the IsPostBack.

So far, testing on our portal product has gone very well using the RC1 release of the CA component. To say it's impressive would do it an injustice.

Our first test was simple, just wrapping the loading of a weather module as a call back. We had a weather module taking awhile to load, so we are loading it with a callback instead in the page_load event.

It's pretty slick, the entire page loads now without waiting for the weather service.

In other tests, we have tested the retrieval of data at timed intervals, then on another machine, update the seperate modules data. Watching the individual modules on a page update their info independently was pretty cool.

Over the next week or two, we'll be doing more testing with updates as well.

But currently, we are very impressed. I am sure Teleriks component is also of the same caliber as the CA component. Either one will be more than worth the price of admission, IMO.

Re: AJAX and DotNetNuke

locopon — Thu, 08 Sep 2005 00:47:30 GMT

what Jon Henning said about events is very important, and I think his commentaries about ajax make me need to see his solution. The problem is that many of us need a solution right now.

I saw many solutions offering a wrapper control that renders inner controls using ajax
I was looking into what is needed to make use of current solutions to make something to work like this:

1) The wrapper need to have controls inside (OK, template containers are currently supported in asp.net)
2) if not postback, the control must render all inner controls in the normal way, but changing the DoPostback buttons to custom ones. Now, we will have 3 status values: normal, postback, callback
3) if postback, make all the same as normal
4) if callback, the wrapper must receive the call and create its own internal page object (We need to send viewstate and current input tag values). As the callback result we will have the inner controls rendered html, and a simple .innerHTML javascript call can redraw it on the client.

This way, only the wrapper module have to know how to make callbacks

Now, it can be implemented at the following levels
1) Module, A module that wraps other modules(using this callback stuff).
2) An asp.net control that developer can use to wrap parts of a module.

Well, it is just an idea, but I think it could be the solution in the short term making simple to change to whatever solution comes later.

Re: AJAX and DotNetNuke

Ed_DeGagne — Wed, 07 Sep 2005 20:30:26 GMT

Nice AJAX sample for DNN.

A smal issue though. In using the current release version of Ajax.NET by Michael Schwarz, it is necessary for you to write the java function.

I believe in the CallBack components from Telerik and ComponentArt, this is done for you behind the scenes. All you have to do is write about 3 lines of javascript as a wrapper more or less.

I could be wrong, but thats the jist I got out of it so far.

Regardless, this is a technolgy thats going to change the face of web develepment immensly, so much so that the lines between a "thin" client web app vs. a "fat" desktop app will be brought closer together than ever.