I always thought the original Apache::ASP (by Joshua Chamas) was the most underrated web framework around.

Me too! It's been in use on every Perl web application I've built since 2003 (or thereabouts). Joshua Chamas made my life (and the lives of many others) much easier with the release of Apache::ASP.



How compatible is your new code, for people on Apache::ASP who want to try migrating?

Mostly compatible. There are some breaking changes however.

For example, the "global.asa" file is replaced with subclassing GlobalASA.pm. $Response->Cookies has been simplified ($Response->AddHeader is there for complex HTTP header manipulation).

I can't promise the new API extensions won't change before the v1.0 release, so I wouldn't recommend migrating any production websites to it just yet. However - anyone who's used Apache::ASP and wanted feature "X" added in or thought "Y" should be different, now is the time to speak up. Once v1.0 is released I'm going to freeze the API.

I hope to release v1.0 by the end of this month (June 2007).

Aside from a different session backend, are there any specific advantages your version has over Apache::ASP?

Some advantages include:
• The introduction of "Apache2::ASP::Handlers" - an object-oriented approach to website development means you can write little or no code. I expect several independently-developed Apache2::ASP::Plugin::* modules in the future.
• "Handlers" can inherit from each other. So you could have base global "create", "update" and "delete" Handlers that other handlers simply subclass.
• File uploads go far beyond the old $Request->FileUpload(). Subclassing Apache2::ASP::UploadHandler or Apache2::ASP::MediaManager gives you the ability to set up callbacks like before_create(), after_update() or before_delete(). With a few lines of code you can build an upload progress indicator (see example on website).
• What's more fun than uploading your movies/photos so other people can see them? MediaManager makes this as easy as use base 'Apache2::ASP::MediaManager';
• As stated earlier, database-persisted Session and Application state means that your web application can span multiple servers. Servers may share roles or handle roles all by themselves (i.e. 3 WWW servers and 2 Media servers).
To help the Apache2::ASP API solidify, I'm building some web apps with it. The Apache2::ASP homepage is running it now. More sections will be added soon.

Thanks for commenting.

It seems you embed Perl, not VB or C# or whatever ASP developers normally use, into the HTML, so it's not like someone can port code directly from an ASP environment into apache+perl, is it?

Correct - it's a Perl module. Although Inline::WSC could potentially be used (on Windows) to allow for VBScript <% %> scriptlets, it would only work on Windows. Which already has VBScript for ASP. And who (among us) wants to write web applications in VBScript?



Why would someone want to use Apache(2)::ASP instead of HTML::Mason?

If someone wants to use HTML::Mason they probably have their reasons. HTML::Mason is mature (about 8 years old) and IIRC several large sites run on it (can't remember any off the top of my head though). Bricolage runs on it.

However, as I have discovered for myself, there are a lot more Microsoft ASP programmers than Mason/Catalyst/CGI::Application/EmbPerl/etc programmers. ASP is an acceptable paradigm and is easily replicated. To get more programmers using Perl it is wise to offer something familiar.

One thing I enjoy about Apache2::ASP is the use of "Handlers" to process non-navigational requests (i.e. forms, AJAX requests, etc). Without stepping entirely outside of the ASP paradigm I can still have access to the ASP objects ($Request, $Response, $Session, $Server, $Application). Since Handlers can subclass other handlers (i.e. MediaManager subclasses UploadHandler) you can get a lot of functionality just by composing your Handlers from simpler classes. If I'm not mistaken, Mason has some kind of "stacking" functionality for Components. I never really understood it.

Another difference between Apache2::ASP and HTML::Mason is that Mason uses Apache::Session while Apache2::ASP uses its own session-state manager. I've used Apache::Session before and ran into problems (framesets caused issues, plus I wanted my sessions table structured differently). So that's why Apache2::ASP doesn't use Apache::Session. A previous incarnation did, but no longer.

Regards

Bricolage runs on HTML::Mason.

I'm on the Bricolage dev team (Scott Lanning), so I was aware of that. :D Actually, why I looked up how Apache::ASP works is because I was wondering whether it'd make sense to add Apache::ASP as one of Bricolage's template languages.

One thing I enjoy about Apache2::ASP is the use of "Handlers" (....) If I'm not mistaken, Mason has some kind of "stacking" functionality for Components.

Mason does have dhandlers and autohandlers, and you can "chain" components, yes.

Mason uses Apache::Session

Mason doesn't actually have any built-in session handling, so you could presumably use the same method in Mason as in Apache2::ASP.

Thast depends on what you've written your ASP in. The problem is you're thinking that ASP is "normally VB or C# or whatever." Now it may *often* be, but ASP is a framework by design, and not a language. You can write ASP in Perl with ActiveState's PerlScript ISAPI extension for IIS. Although it's been a long time since I played with it, if I recall correctly PerlScript ASP on IIS to Apache::ASP was a nearly transparent port as long as you weren't mucking about with COM objects or system stuff.

--
In Bob We Trust, All Others Bring Data.

I would like to see an easy way to use Single Sign On. Maybe bitcard, openid or Apache2::AuthCAS.

This could be implemented easily through a call from the Script_OnStart() event in your GlobalASA class. Everytime an ASP script is executed, Script_OnStart() is called first. If the user is not logged in, they can't access the requested resource - just $Response->Redirect("/login_page.asp") or whatever.

You'll need to find/create a Perl implementation of BitCard or OpenID. This is the first I've heard of Apache2::AuthCAS - I'll have to check it out.

I would like to see an Example that everybody can copy and paste on his Apache2-Server.

I plan on including the source code for the Apache2::ASP Homepage with the distribution. The website's code will also be available from the website itself as a tar.gz archive.



This example should include an interactive HowTo. So it can point me to my mistakes and give advices, until I configured Apache2 and Apache2::ASP good enough to run all other examples.

I had thought of making a few video tutorials with CamStudio. I could cover installation, Hello World, custom Handlers, etc. - Would that work for you?

Even so - good work!

A small issue I spotted - in your Makefile.PL for lots of your dependencies you don't list a module version. This is a Bad Idea as some modules have changed their interfaces over time. Test::More being an example. You should only give an empty version number if you're certain that any old version will work.

I have to chime in here to disagree with what you seem to be advocating for Makefile.PL dependencies—if you know that a given version of a module is required (for a feature or a bug-fix, for instance), then of course you should absolutely put that in your dependency list. But if you say "there should always be a version number," you inevitably encourage people to put the version number they have installed (since that's the only one they can prove works), even if "any old version" would in fact be fine. Thus forcing a potentially unnecessary upgrade on anybody who wants to install their module, which is (in my personal opinion) bad manners.

This is not to say that I disagree with the general position that having the correct version number for module dependencies is important—for something with as many moving parts as a web framework, in fact, I'd encourage the author to do some checking to establish what the minimum version numbers actually are. But I find the "require the latest version of everything" philosophy can have very annoying results when applied indiscriminately (are you listening, h2xs? I thought not.), and this seemed an opportune moment at which to point out some of the objections to it.




---

If God had meant us to fly, he would *never* have given us the railroads.
    --Michael Flanders

I'm sure I'm not the only person to be amused that you dislike TT because it has so many dependencies...

I admit - TT does generally seem to Just Work these days. I think any problems I once had must have been resolved by the folks working on TT or perhaps on my end by just not trying to install it on a box running RedHat 9 :).

but your module has all kinds of dependencies which are harder to build and configure, such as Apache2.x and mod_perl2.x and at least the fifteen modules you list in your Makefile.PL!

I agree - Apache2, mod_perl2 and libapreq2 generally need some Know-How to get working properly. I hope to address this in the upcoming "How the heck to I install this thing" documentation.

As for the other modules - my limited experience has shown that they all install quite easily. My limited experience installing Apache2::ASP has been mostly on RHEL4 and Fedora6. Now that Apache2::ASP::Session::MySQL comes by default, I'll need to add DBD::mysql to the dependency list.

Before the v1.0 release is made, I'll make sure to adjust the required version numbers to the bare minimums.

Thank you for the constructive criticism - it is very much appreciated!

I found this page when attempting to do some research of my own: http://www.devstack.com/articles/apache2-asp-intro/