Running IronPython in DotNetNuke

• Download source files - 348 Kb

Introduction

If you have heard or used DotNetNuke and built some modules to it, you might be aware of the fact that as in web development usually, building small and quick functionalities into a website usually require a ton of coding with quirky (and usually pricy) IDEs. Just came up with an idea while thinking of building another module for creating macros inside DotNetNuke : hey, why don't we all use scripting.

Ok, nowadays everything is scripted - even parts of operating systems are scripted. As the speed and memory of computers keep getting bigger, it actually doesn't matter that much since with different kind of scripting languages we get easy and yet powerful access to various down-level functionalities that would otherwise require rather extensive knowledge on various technologies. With this in mind, I didn't think it would be bad idea to run interpreted language inside another interpreted language.

Requirements

You only need .NET 2.0 and DotNetNuke 4.x running website - .NET 2.0 is required by IronPython and thus the DotNetNuke 4.x. I'd love to see this working in .NET 1.1 and DotNetNuke 3.x but unfortunately IronPython relies heavily on Generics and can't be translated easily to .NET 1.1.

How it works

The basic idea is that we have DotNetNuke portal installed where we run various modules that are actually quite independent pieces of software that rely on the DotNetNuke core framework. Also the IronPython -module (still a working name) is a normal module that actually embeds the IronPython running engine inside the module that runs inside DotNetNuke ASP.NET application, which runs inside IIS's worker process. This allows developers to run quicly small (or even larger) python scripts inside the module while still having total control over current module's functions, DotNetNuke portal's or host's functions and even ASP.NET application's functions. This is done by providing following modules, objects and namespaces by default after initializing the actual python engine :

App - This is ASP.NET application object that contains DotNetNuke. With this you can access directly normal ASP.NET objects like Request, Server, Response etc. Also other application specific items are available, just type "dir(App)" to see them all.

DotNetNuke - Ok, this is obvious. This object provides all information about running DotNetNuke instance with all area access to Users, Tabs/Pages, Portals etc. Just fool around to see what you can find.

Handler - This one is object of "Web.HttpContext.Current.CurrentHandler" that contains as it says, HttpContext's current handler. At the moment I have no idea where to use this, but give me a hint if you get it. Just imported for TOTAL ACCESS :D

Page - This one gives user a raw access to ASP.NET page - yes, it's ASP.NET page, not DotNetNuke's Tab/Page object. You can also access this from "Handler.Page".

Web - This is a shortcut to namespace of System.Web from the .NET Base Class Library. For some reason the Web namespace didn't load automatically although IronPython engine is run under ASP.NET application but the System.Web namespace had to be located in the codebehind file by calling "System.Reflection.Assembly.GetCallingAssembly". Doesn't matter - works this way as well.

Then few objects that are more interesting :

Module - This is the actual module inside which we are running the IronPython engine. All DotNetNuke PortalModuleBase functionalities are available.

IronCanvas - Ok, now we are getting somewhere - propably the most interesting object. This is normal PlaceHolder -control where we can drop in other ASP.NET or DotNetNuke controls.

These are the basic modules and objects that are set up for developers to tweak around to see how it works. I'm not that good yet with python, so I just throw in few small code samples that gives you a raw idea what we are talking about.

Here's one small script that allows you to list all users in DotNetNuke :

uc = DotNetNuke.Entities.Users.UserController()
users = uc.GetUsers(False,False)
for n in users : print n.FullName + " = " + n.Username
print "\nUsers in system : "
print users.Count

And here's another that lists all pages (including Admin and Host -pages) :

tc = DotNetNuke.Entities.Tabs.TabController()
tabs = tc.GetAllTabs()
for t in tabs : print t.TabName

Get the idea ? You can also write directly to response stream with following statements :

App.Response.Write("Hello World")

Following redirects user's browser.

App.Response.Redirect("http://www.dotnetnuke.com/">http://www.dotnetnuke.com/")

Writing running scripts

Ok, with current version of module you have two options : you can either work around with IronPython Console or you can set up a script that is run every time module is loaded. This means that you can restrict module's running rights with normal DotNetNuke role based security settings. At the moment writing out the python script is not as easy as it should be, but propably future versions will have better working editor. At the moment you can access the simple editor by selecting "Settings" from module's dropdown menu. From there you should see "IronPython Settings" in the bottom of settings sections. After opening it, you see a simple textbox that allows you to write your own code. For starters, put there script like this :

Don't check the "Keep IronPython engine in user session..." since this seems to have funky results at the moment. After clicking "Update", you should see a simple ASP.NET calendar control inside the module. With reading the small code, you should get the hang of it. NOTE ! At the moment there is no solution to handle the events inside ASP.NET or UserControls so, please check for further betas in case you find this interesting. There is available "pyevent" module for you to import but while writing this, I haven't got the idea how to create a function that responds to events of ASP.NET controls - this might be because of the beta (6) phase of IronPython or the actual fact that IronPython is not designed for environments like ASP.NET.

Naturally you can also put to script input one (or both) of previous scripts - just to see how they work.

Ok, maybe this is enough this time - give feedback, ideas and correct me if something here is badly wrong. Hopefully once our module's version 1.0 is released the IronPython would be in it's final release as well so that we can get all the cool modules that can be found in "legacy" Python.