I a new to DNN, but a 'hack' developer. I posted the code in the page, and it did 'bang' off of Flickr (with a message that it doesn't support frames)… the 'duck' is just an image – not a widget – so it was of little help. Also, I don't understand from the example where the url is. is it the param value? The 'widget' I'm specifically am trying to embed has very poor documentation… they only provide: http://yourcompany.theirproduct.com/#@loadWidge… (I can get the SID)

sorry for the confusion… but I'm weary from wading through the documentation that is out there

Hope this is clear…
I am sorry this is frustrating….

I want to create a box(widget kind) of thing
feature of box should be:
1. it will fetch dynamic data from DB based on query string.
2. it should be configurable for admin to configure on home/inner pages…. where ever i want……

So please let me know how to handle these kind of things…. in DNN

W.r.t. packaging, Widgets are not an either/or choice with jQuery. In fact, you can use jQuery plugins just fine within Widgets.

On the performance front, if you have UI elements that you know will change visually, you should consider having a CSS style of “display:none” initially so that the Widget can do its thing. This may not always be practical and in those situations, using a Widget may not be the right choice.

As developers, we find it pretty easy to deal with <script> elements and jQuery plugins. End-users authoring content struggle with this. Widgets make it possible for you to integrate re-usable Javascript (be it jQuery, or YUI or something else) so that even end-users can add interactive elements to content. Ideally this would be done by providing a toolbar icon in the rich-text editor which shows a selection of Widgets, the user clicks on one and then fills in parameter values. The idea is to provide a level of abstraction from Javascript for a user who does not know how to program, but knows HTML. Content editors that are HTML-literate already do this when they embed Flash. Widgets build upon this knowledge.

Widgets may not be the right solution for everything. But the ability to package script so that it can be embedded in arbitrary locations with arbitrary parameters using HTML markup can be quite useful in many scenarios. As an analogy, consider that a DotNetNuke module is primarily a user control with a UI for managing its presence and settings. One could argue that it is pretty easy to add control references on an ASP.NET page and set attribute values as needed in code, thus making a module useless. This argument is true, but in some situations, a module is better and makes the user control that much more practical and useful. Widgets are no different if you think about them as packaged scripts that due to their abstraction, are easier to manage and more practical to use.

I'm not trying to be argumentative, and I'm doing my best to be informed (the STL DNN UG just spent an hour and a half on this and no one came away convinced), I just have yet to see a practical example of a useful DNN widget that isn't better handled through a external reference to a jQuery plugin.

Clean Markup, Reusability, and Behavior Injection and Modification – can be addressed just as well by referencing external Javascript files and jQuery libraries.

Testability and Maintainability – While I agree with this in theory, as you know, jQuery is a much more standardized Javascript framework that likely has existing plugins for doing whatever people need. If I'm going to package Javascript, it'd make more sense to do it as a jQuery than as a DNN Widget as that provides for a much wider audience.

Performance- From a usability standpoint, I actually see the post-rendering issue as a usability negative. The content is initially rendered one way, and then changed (usually a half second or more) later. This is very confusing/disorienting to the users I've interacted with. Rendering it once the right way, even if slightly delayed seems more usable to me.

Sincerely,
David O'Leary
Efficion Consulting