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
| [reply] |
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.
| [reply] |
I'm on the Bricolage dev team (Scott Lanning), so I was aware of that. :D
It's a small world, eh?
I was wondering whether it'd make sense to add Apache::ASP as one of Bricolage's template languages.
The next release will include documentation for Apache2::ASP::Parser - and the ability to choose a different parser engine if desired. It might be worth a look.
Mason doesn't actually have any built-in session handling
I just made the assumption after seeing the package name MasonX::Request::WithApacheSession - didn't mean to spread rumors :)
| [reply] |
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.
| [reply] |
