Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Perl Programming

Mason 1.0 Released 96

Sowbug writes: "Perl programmers rejoice! Mason 1.0 was released today, though prerelease versions have been in operation for years at websites like TechWeb, Salon.com, and AvantGo. Congratulations, Jonathan Swartz (principal author of Mason)!" I don't know much about Mason, but it seems like another cool addition to the Cold Fusion/PHP world of embeddable code in Web pages.
This discussion has been archived. No new comments can be posted.

Mason 1.0 Released

Comments Filter:
  • As long as I'm not the only grown man watching Tiny Toons, I feel a little better about it.

    If someone has a .WAV of this, it'd be much appreciated.

    Oh, and dude...I can't BELIEVE you knew the whole song.

    --Just Another Pimp A$$ Perl Hacker
  • Perl is the duct tape of the internet. If it was so vulnerable it wouldn't be so widely used.

    Hmm ... that's a strange logic. With such logic, we can logically deduce that BIND is the parangon of computer security, that sendmail is a great piece of software, and that Paul Vixie knows how to write code.

    Might be a bit too much.


    --

  • by Shevek ( 6397 ) on Thursday February 01, 2001 @05:04AM (#464889) Homepage
    I have been using Mason and related packages for a long time. I agree strongly with the people who say that mixing code and markup is a bad idea. I would go even further from my own experience, and say that mixing execution and display in any way is a bad idea.

    On receiving a web request, the first thing to do is process the input, perform any operations, and then set up necessary information for doing a page display, using a tool such as Mason, with the least possible amount of code. My Mason pages rarely contain more than a <% $object->get('foo') %>.

    In this way one has the versatility to redirect internally if an operation fails, and one doesn't have to cope with a page crashing halfway through display.

    Mason is an excellent tool for controlling a structured web site. Mixing markup and code, execution and display is a separate, general topic, and should be considered apart from any specific tool.
  • Some of us live in the third world where the cost of closed software is prohibitively high.

    Seems like it would be tough to come up with a computer to run Win98 on in the first place then, doesn't it? Buying a low end computer will run you about 10x the cost of a Win license, so you're spending 11 months wages instead of 10 for your initial purchase.

    Not that anyone should ever buy from MS, mind you - it just encourages them. My point is that if buying a computer isn't prohibitively expensive, buying the OS shouldn't be either.

  • Absolute Shitty Pages are not the way to go, EVER!

    If for no other reason then because it makes people think that your server is running M$ software and we can't have that now, can we?

    No really, ASP may be usable with Perl, but so is a lot of other embed-Perl-in-HTML stuff, so there isn't really any reason for using ASP unless you have lots of legacy code that uses it and developers that like it.

    HTML::Mason is available from CPAN, that and the fact that I like mason, is pretty much all the reason I need to choose it over everything else.
  • Hmmm ... I don't know, this sentence coming from a sysadmin kind of scares me. 'touch wood' ... Hmm.

    Doesn't surprise me much... in fact I bet if they did a study they'd find that sysadmins 'touch wood' more often than any other profession. (Or would they call it 'pounding the Penguin'?)

  • only on topics about 70s calculator ICs
  • If someone has a .WAV of this, it'd be much appreciated.

    The song is called "We Do (The Stonecutter's Guild)" and it's available on the Simpsons'
    CD "Songs in the Key of Springfield" (A play on the name of the X-Files CD "Songs in the Key of X").
  • OK, you don't like all ASP-like solutions.

    So, drop down all raw HTML fragments. Generate Perl list-of-lists representing the DOM you really need and dump it in HTML before sending HTTP response.

    I develop an http server working that way: Perlet Engine [halyava.ru]. Any ideas?

  • I looked into using Mason a while back for a site. It's a good framework to build web apps. However, you basically have to build stuff from scratch. Although there are a couple of good reference sites using Mason, there are no apps! Not really much in the way of sample code you can take and run with. With something like Zope [zope.org], you have lots of things built on it (Squishdot [squishdot.org], etc) and a library of other things [zope-treasures.com]. Lots of stuff available for PHP [php.net] as well. Mason's list is relatively weak [masonhq.com]. Perhaps this will improve over time. I hope so, but until then I think Mason is not the easy route!

    -bp

  • by Anonymous Coward

    Actually, Mason allows you to do just that -- it is by far the most powerful templating system I've ever used (and I've tried both PHP and JSP/Servlets).

    Check out the documentation for autohandlers/dhandlers and the object-like syntax -- these are perfect wrappers for HTML content. On the sites I manage, I've reduced the 'page' to the point where there are three parameters in the <%attr%gt; section (a template style name, a title, and a description), and then the basic HTML with a few component calls to embed database output (the components do the formatting).

    I'm considering moving the entire site (400+) pages into a database since there are only four fields required to describe a page and everything else could be handled by a dhandler. Never mind that, with Mason, you have access to all your CPAN modules.

    Put that in your PHP pipe and smoke it.

    • web sites running Perl are notoriously insecure
    Are you trying to claim that it's the half of the web which isn't running on asp that is insecure ;-)
    • It's not because Perl is insecure, it's because Perl makes it so damn easy to just "get something working", and clueless people are writing insecure scripts all over the place.
    Uh... you miss the point. You run the script (root 'sploit, not cgi) on the perl interptreter on your local machine - not the remote machine that you are trying to hack into. Which err... was my point - the hacker uses perl as a tool, perl isn't part of the problem.

    and if you are refering to cgi scripts that people have writen themselves - well when you write a cgi script you are writing a piece of software - and if the software that you write is insecure, then that is not a bug in perl, it's yer own damn fault.

  • so, don't use suidperl! i strip the suid bit off of that on any machine that i really care about having security. the only reason why you'd need it is if you're writing suid perl scripts.

    meanwhile, this argument is kind of stupid. there are no security holes "in perl" any more than there are security holes "in C." but both languages allow you to write bad code that has security holes. a properly educated programmer can avoid the pitfalls in both languages.

  • Fair point & worth making - but a couple of minor bugs don't support the original claim.
    • Especialy since there is a root exploit for every known version of perl in existance
    I think it is fair to say that perl is a relatively secure & bug free piece of software.
  • Why not just use HTML::Template? It should be a lot faster since it really doesn't have much more to do than plug in values and blat out the data. Unless Mason has some nifty other features that make this extra overhead worthwhile?
  • This certainly isn't Ancient, but it's Free.

    As to Accepted, well that's another matter entirely.

    [Myself, I'll be sticking to PHP...]

  • While I haven't used Mason, so can't really comment on it, another very nice Perl embedder that runs very well under mod_perl is embedded perl (HTML::Embperl). Makes application development quite fast and manageable, especially if you write reusable code in perl modules!

    Check it out at: http://perl.apache.org/embperl/ [apache.org]

  • As I understand it, the problem with perl and the web (as CGI anyways) is that perl runs with less than perfect permissions, and that leads to exploits if its installed incorrectly. Also, perl allows you to run shell commands as well as execute code stored in strings, so in poorly written programs that leads to exploits.

    However, these two problems are very well documented and workaround exist. I am going to assume that right at the start there will be exploits to Mason and they will be documented and worked around and things will be happy.

    At work I write ASP pages all the time and I think that the idea of embedded server script is very nifty. Its about time that other platforms had the ability to embed perl in webpages and have it executed by the server like IIS has been able to do for a while now.

  • Comment removed based on user account deletion
  • by Christianfreak ( 100697 ) on Thursday February 01, 2001 @12:08PM (#464906) Homepage Journal

    Mason looks okay but its still developing script within the HTML, when working with designers who don't know perl this becomes a problem. I've been using a mod called HTML::Template for some time now and I highly recommend it to anyone building web pages with Perl. HTML template allows a set of specialized HTML tags in that actual HTML documents that a separate script uses to insert data. It has varables and loops and if/else structures.

    HTML::Template can also do caching of HTML pages when used with mod perl, plus the tags are ignored by commonly used HTML editors such as Dreamweaver. All in all I think its a much better solution.


    "One World, one Web, one Program" - Microsoft promotional ad

  • In my experience, windows 98 runs better than X on older hardware. I had a 486dx2-66 with 8meg of ram and it ran win 98 more comfortably than it did X. Also my old hardware configured alot easier under windows than it did under linux.

    When you make comparisons like this compare apples to apples. If we had to compare the running speed of linux cli to straight dos, I think dos would win the race (although by a small margin) but it wouldn't be fair because linux provides a whole level of abstraction and extra functionality that dos doesn't begin to.

  • Yes, there is a security problem with running suidperl. As is there with anything that has the capability to be run suid root. So what?
    Just don't do it. It's bad practice to use suidperl.

    If you need to create files on the local filesystem (this can usually be avoided but not always), would you rather do it in a directory that is world writable (or writably by the web server process, which may as well be the same thing if you have lots of CGI/mod_perl/whatever) or would you rather have a Perl script that is setgid to some special group and only give that group write access?

    This is largely a moot issue with the proliferation of scripting languages running within the web server process, although sometimes it is worth taking the hit of a fork+exec(+perl startup (ugh)) in order to restrict access to important files.

  • "Cold Fusion/PHP world of embeddable code" PHP and Cold Fusion on the same line or even the same sentence! - a blasphemous use of the the English language.
  • it works well and has given no probs (touch wood)

    Hmmm ... I don't know, this sentence coming from a sysadmin kind of scares me. 'touch wood' ... Hmm.


    --

  • Hear hear!

    "But is ASP stronger?"
    "No! No. Quicker. Easier. More seductive."

    --Just Another Pimp A$$ Perl Hacker
  • thats like saying a tree is bad because you can make a baseball bat out of it to bash someone's head in with.

    damn blunt object reference again

  • by Anonymous Coward
    > So does C, and we all know how many root exploits that has Er... none... C is a language specification. Programs written in C can be prone to exploits, because untill C99, there weren't standard buffer-length-checked string handling functions, and stupid programmers tended to use the non-buffer-length-checked functions rather than putting in a few trivial little checks...
  • How much is ASP?


    alright by the time you have figured it out, perhaps you found out that PHP is free! Free to download, setup, and run!
    as far as Microsoft goes you summed it up for me: In addition, you know that Microsoft will always be there to fix ASP, but you can't be so sure with Mason.
    Because they release broken products, php will always be better.
    Good companys dont stick around to fix their shitty products. Good products have a cult following.



    Fight censors!
  • I'm probably braindead yet this morning, but how the hell can I exactly get away with not putting any HTML in my PHP code? I mean, come on, forms are pretty important. Also, I've yet to find a decent way to use templates with more of a serverside type PHP dev. If you have a good way to templateize (uh, new word?) PHP, please point me there!



    Dive Gear [divingdeals.com]
  • Some AC said, I imagine as a fundamentalist Christian, he might be a little appalled to find his life's work being perverted by being associated with a product named after a secular humanist anti-God, power-mad secret society. True, the ways of Satan are slippery and slimey, but I'm not loading any patches contributed by Adam Hauptman

    I apologize in advance for off-topicness and responding to a troll.

    Perhaps you're confusing masonry with Freemasonry. The product is called "Mason." Masons build structures from stone. Freemasonry is a society that seeks to build an ethical and spiritual foundation for men.

    Being a Freemason myself, I promised not get into arguments with folks outside the order. However, I can say this: Freemasonry is not a secret society. If most people know about it, and they meet in public places, have public bank rolls and public charters, then they are not secret! They are a society that has secrets, but that's different.

    Fremasonry is a spiritual organization, steeped in metaphor. We allow men of any spiritual bent to join, as long as he believes in a Supreme Being. Freemasonry is also a great benefactor towards many charitable causes. I hope this information helps to calm your fears.

    Yekrats, Freemason and computer geek

  • Try FastTemplate [thewebmasters.net].
    or Smarty [phpinsider.com] which also processes the templates into ordinary php files on the first run (to reduce overhead).
    Also PHPLIB [netuse.de] which has many other uses including session an database management.


    DILBERT: But what about my poem?
  • Seems like it would be tough to come up with a computer to run Win98 on in the first place then, doesn't it? ...

    My point is that if buying a computer isn't prohibitively expensive, buying the OS shouldn't be either.

    "A computer to run Win98" != "a computer". Computers that can run Linux might be even cheaper than the Windows license.

  • Once again, I apologize for driftiness...

    Shriners are the fez-wearers. Although they are associated with Fremasonry, it's a different group. (I think you have to be a FM to be a member of the Shrine.)

    Now, during meetings, the ceremonial leader wears a hat to identify himself as such to others at the meeting. I guess it's a token of respect and office. Sometimes, I've seen people wear a fez-like hat in that position, but I've also seen people wearing their hat from the closet.

    Yekrats, Freemason and Computer geek

  • available on the Simpsons' CD "Songs in the Key of Springfield" (A play on the name of the X-Files CD "Songs in the Key of X").
    More likely, it's a play on Stevie Wonder's classic Songs In The Key Of Life [amazon.com].

    --

  • At Buy.com [buy.com], Windows 98 Second Edition is $198:

    I don't know where you're buying your computers from, but they shouldn't cost $2000.

  • In third-world countries where the cost of commercial software is prohibitively high, so is the cost of hardware. There used to be a site called FreeBoxen that addressed this in the spirit of the open-source community, but unfortunately it was taken down. [google.com]
  • Besides, people can donate their old computers. They can't donate their old Windows licenses.
  • ...is what the BSD guys would call their port.
  • I've got a second hand apron...

    Your Working Boy,
  • Because the script becomes your template.

    I have programmed in Perl and PHP. When programming in Perl I always used templates, they are good, no disagreement. But you can program php in the same way. Look at the following example:

    Perl Template
    <html>
    <head><title>blah</title>
    <body>
    Date = $Date
    </body>
    </html>

    PHP script:
    <html>
    <head><title>blah</title>
    <?php require 'dateFunctions.php'; ?>
    </head>
    <body>
    Date = <?php printDate() ?>
    </body>
    </html>

    Hang on. That script is just like the template. The only difference is you don't have to load the template file, parse every line of the text and replace the approprate strings with their value. Now with the php, just like a template remember, if you want to add new functionality you just need to add a new function to the included file. Perl you have add the new function, then add the new string to the parsing function etc. Which is easier?

    Thus ends Web Programming101.
  • Akopia, recently acquired by RedHat, developed Interchange, which is an awesome web development platform for e-commerce websites. It's GPL. I highly recommend you check it out at: http://developer.akopia.com [akopia.com]
  • CPAN is what's great about Perl. But I was talking about Mason specifically. Mason allows you to create components that you can call from your web pages. There is a potential to have a wonderful library of pre-built Mason components to do various web things. The one good example is the clicktrail widget that automatically builds a hyperlinked "you-are-here" path. I wish there were more good examples.
  • There are some dynamic content where it's simply impossible to draw the line between "Presentation" and "Logic" - For example the good ol' calendar in an HTML table. At best you can code it as component and pass some formating parameter into it to alter the style. But basically you're forced to put at least some HTML markup in your code.

    Also, it'd be nice if all "web designers" are fully capable of actually creating the templates where you can easily drop in the outputs of your programs, instead of handing you a 50k program generated piece of crap filled with completely unneccessary table tags everywhere.

    The place where I work the general policy is that the graphics people sort out the look, hand me the graphics in Photoshop, and I'll look at them, determine what is the most efficient way of cutting things up and integrate it with the code, then hand the cut-up pieces of the graphics back to the graphics people and tell them to work on those instead and follow the EXACT same file names (somehow having images called "nav_border_left.gif" "nav_logo.gif" "nav_button.gif" etc is much more preferable to calling them "xxx_1_1.gif" "xxx_1_2.gif" etc that most graphics software generate...). By keeping all the files under the strict control of of us lowly mere developers at least we can be sure no one will never ever screw things up by using Dreamweaver or worse Frontpage on them...

    Also there are things that one can do by using the server side program to manipulate width and height tags of images depending on the database query/whatever... not exactly easy to separate into presentation and logic (of course, the database query will be a separate piece of code but you still need some fairly hefty "coding" for the display)
  • ...if you don't know the secret handshake?

    -----
    Who controls the British crown?
    Who keeps the metric system down? We do! We do!
  • Are you trying to claim that it's the half of the web which isn't running on asp that is insecure ;-)

    No, all I'm saying that of the insecure scripts that are out there, lots of them are written in Perl, because Perl is so nice and easy to use. Not so long ago a lot of people were saying that writing scripts in Perl was a bad idea because it's easy to leave security holes in Perl CGI scripts. I don't agree with those people, I'm just trying to figure out where the original poster got the idea that Perl is insecure.

    Uh... you miss the point. You run the script (root 'sploit, not cgi) on the perl interptreter on your local machine

    No. My point was that the original poster probably wasn't talking about exploits written in Perl, I think he was talking about CGI programs written in Perl. All he said was "perl is insecure" and you started talking about exploits written in Perl. How do exploits written in Perl make Perl insecure? I think you misunderstood what he meant.

    As you said, "if the software that you write is insecure, then that is not a bug in perl, it's yer own damn fault." I couldn't have said it better myself.

  • Some of us live in the third world where the cost of closed software is prohibitively high.

    Even the cost of a Win98 licence is more than the minimum monthly wage.

    The existence of open source and free products like Mason, Zope etc will go a long way to ensure that disseminating information is not constrained by the cost of the tools.

    Well done to the Mason group.

  • Is this realy a good idea? Especialy since there is a root exploit for every known version of perl in existance? Perl doesnt and will never run on my machine.

    Another constructive ****** user, no doubt.

    Perl runs on *at least* 50% of the Internet servers in the world, in some capacity or another. Now if there was a root exploit for every known version don't you think we would have heard about it in the news by now?

  • we use Mason on one of our commerical sites (though i didn't work on that site the guy who did left so i am maintaining it now) and it works well and has given no probs (touch wood). recommended.
  • No you are not following the logic at all. When someone finds a new hole in BIND it is all over the news (news sources for geeks anyway) and *everybody* knows about it. Same with sendmail. If Perl had root exploits it would get the same amount of attention. There should be links and stories all over the place about it. Now show me said proof and I'm willing to buy into it. About the only thing I can find on securiteam.org is something about Activestates Perl and a exploit having to do with Perl and IIS. Everything else looks minor and quickly patched or like using Perl to do exploits. Looks like there might be a couple of modules you would like to research also. Compare that to what a search on IIS reveals. :)
  • "You can emmbed php in html but not perl"

    I would call that a strike against PHP. I thought the whole concept of clean design was to separate content and presentation. It's difficult to do that if you're constantly embedding <? some php code ?> and then the site designers want the look to include mauve tilebars or something.

  • Sure, I'll give it a try. Would you mind providing a link to where I could find ASP support for Apache running on Linux boxen? Or Solaris, or HP-UX, or *BSD for that matter, I'm easy but I want my webservers to stay up without having to watch them every minute.

    DanH
  • I think he is refering to the fact that perl is a language commonly used for writing root exploit scripts

    Not that I don't think he was trolling, but try a google search on 'suidperl' and 'bugtraq' and you'll get a number of results [google.com] describing buffer overflows.

  • Oh sure - I don't agree with the troll - I was just clarifying what he was saying.

    And anyway, there's nothing wrong with blunt object references ;-)

  • Yes, there is a security problem with running suidperl. As is there with anything that has the capability to be run suid root. So what?

    Just don't do it. It's bad practice to use suidperl. Mason doesn't require it.

  • by ajs ( 35943 ) <{ajs} {at} {ajs.com}> on Thursday February 01, 2001 @05:46AM (#464942) Homepage Journal
    Mason is pretty nice, I checked it out when it was just getting started. They've done a lot since then.

    The high-level features are outlined on their site [masonhq.com]. Among them are: caching of HTML and data, use of the Perl debugger, and staging vs. production execution modes.

    The CPAN repository [cpan.org] is chock full of mind-bogglingly useful code, so it's nice to see more tools coming of age that allow you to take advantage of all of that through the Web. mod_perl is very nice, but for some tasks, it's just too cumbersome to work at that level. Mason nicely abstracts that away.
  • AISB [aisb.org]
    We tried to get this domain for the AISB (access indiana state backbone), too bad it was taken. lol
  • Whilst using Mason you have to wear an apron whilst standing on one leg, and slapping any other Mason's you see with a wet haddock.

    By slapping a Mason with a wet haddock you are agreeing to the terms of the Mason EULA
  • You're wrong. It's not a strike against PHP. Here's why.

    All templating systems require code to be embedded in HTML. It may be as simple as "put this variable here" -- but it's still code. A robust templating system that supports dynamic page generation, personalization, and database interaction will inevitably require common programming-language constructs, such as testing, looping and branching, at the presentation level.

    While it is sound practice to separate business logic from presentation logic, and presentation logic from look and feel, it is a practice that should be followed insofar as it is practical and beneficial. And no further.

    It's a lot like Einstein's position on simplicity: a theory should be as simple as possible, but no simpler. Do not follow ideas over cliffs.

    By providing a common language at all layers of an application, PHP allows the application designer the freedom to do the right thing, or the wrong thing. I'm fine with that. The smart designer will make a wise choice, and the dumb designer is probably using a different platform anyway.

  • On receiving a web request, the first thing to do is process the input, perform any operations, and then set up necessary information for doing a page display, using a tool such as Mason, with the least possible amount of code. My Mason pages rarely contain more than a get('foo') %>.

    Hopefully along with HTML and other markup. Generating HTML in code is the bigest sin of all *cough* slashcode *cough*

    -josh

  • ASP is fine if you want to live in an MS world the rest of your life and pay up the nose. The better route in my opinion is to go with Apache's Tomcat project with JSP. Hell, php is even better.
    Perl is a good language for quick and dirty things, but not for a large website. ColdFusion is like going down the ASP road, you are too dependent on the vendor.
  • Is this realy a good idea? Especialy since there is a root exploit for every known version of perl in existance? Perl doesnt and will never run on my machine.
    I think he is refering to the fact that perl is a language commonly used for writing root exploit scripts - perl is very powerful in terms of the fact that you can do a lot in a few lines of code (hence obfuscated perl contests).

    His mistake (or probably troll) is in the fact that the waekness is not in perl - perl is just usefull in expoilting the weaknesses in other software.
    Actually, I think he was referring to the fact that web sites running Perl are notoriously insecure. However, he doesn't seem to understand why. Maybe he spent some time on the h4x0r channels listening to what's going on without fully understanding it.

    It's not because Perl is insecure, it's because Perl makes it so damn easy to just "get something working", and clueless people are writing insecure scripts all over the place.

    You could have the same problem with any technology, but not so many clueless people are cabable of writing swiss-cheese-security programs in C. Besides, by now there has been enough yammering about input validation that most of the "CGI for Dummies" books cover security a little better than they used to.

  • I used to work with a guy that was a Shriner. I dont remember his name, but his fez is familiar...
  • I would go even further from my own experience, and say that mixing execution and display in any way is a bad idea.

    I agree. GUIs have no place in the world of true software.

    I mean, come on -- is mixing code with the display really that different from putting the display in your code?

  • I'm in complete agreement with you.

    Having used both Mason and PHP, I have found myself writing a templating mechanism in perl, which, being a fraction of the size of Mason, has helped improve the understandibility of code immensly. Variable substitution through passing of a hash (then $_->{VAR} in code), plus a little regex to allow <if comp="perl type comparison"> <else> <elsif comp="perl type comparison"> </if>. The result has proved extremely successful. If I ever finish my current project (d2, a shared webdiary app) it'll be freely reusable from the codebase.

    Additionally, the merits of seperating the code and the HTML should be obvious to the common perl hacker - ever passed a Mason document to a perl-unaware web designer and see their faces drop?

  • I agree. GUIs have no place in the world of true software.

    Actually... templating is more akin to the way GUI software for desktop machines (in C or whatever) is written. The GUI is severed from the code after display time.

    I mean, come on -- is mixing code with the display really that different from putting the display in your code?

    Templating circumvents both options.

  • I'm using it for my degree dissertation which is a case study into a working e-commerce project.
    It takes a little while to set up but the power afforded you is immense.

    (And anyone that disagrees is a hamsup lo)
  • > I think that the majority of new programmers
    > will choose Python over Perl

    In Japan the majority of programmers use Ruby [google.com] over Python. Might be worth checking out.
  • ...Mason will become a part of perl distribution.
    No more hype about php and others.
    Make no mistake, Mason is not like ASP pr PHP, it is more logical for production.
  • Perl is easy to use and learn. Not bad at all. But that is not the point of perl and nither it is a good thing.
    You begin feeling the power of perl when you become good in perl. Perl makes life easier for you to write complicated programs. In C++, Java: well it isn't very hard to write a "Hello world" program. But ones you need to be involved deeper programming concepts, it is easier to understand them in perl than in other languages. And ones you get to conccept (mainly meaning that ones you understand why that concept exists in the first place), it is easy to learn the implementation of it in JAva or C++.
  • You must be a little illiterate as I never said perl had a remote root explot, but now if your letting users use perl in their own web pages that opens the doors for soo much bad code that could result in various remote explots from the numerous (see cert advisories) local perl exploits.
  • by Anonymous Coward
    Perl runs on *at least* 50% of the Internet servers in the world, in some capacity or another.

    So does C, and we all know how many root exploits that has.
  • maybe he means if someone has root access to your box they can use perl to do bad stuff. though rm -r * might be a quicker "bad thing".
  • The problem is your now allowing users the ability to write their own perl code into web pages, wich was my original argument. Thats no different than allowing people to use C/C++ but with C/C++ the bugs are in other programs were with perl the problems are in perl it's self as it's a parsed language and the buffer overflows and other exploits are in perl it's self. I dont run perl because I dont know it well enough to write good code, and I probably wont as I can do everything with PHP and the code is alreay writen well. I give my users access to upload their web pages, but not cgi or perl, nor shell access. Allowing mason would be like pasting the root password on my main web page.
  • Yeah, right.

    Show me. Perl is the duct tape of the internet. If it was so vulnerable it wouldn't be so widely used. (ok, windows is vulnerable - but that is different. People use Perl by choice.)

    If you show me ANY of these "root exploits" with a recent version of Perl, you may have a leg to stand on, troll.

  • Give me a low level user account on your most vital important machine and access to use perl. Also a disclaimer that protects me from any legalities and lets see what happens.
  • As promising as Mason is, the maintainers have a very poor design philosophy. They consider it acceptable for the line numbers produced in error messages to *always* be incorrect! They consider it acceptable for the external and internal names of parameters to a component to use a common naming convention thus ensuring that you cannot use the %ARGS section if you want to use valid HTML parameter names that are NOT valid Perl names. The classic example: If you have an image input called foo, the browser will send parameters called foo.x and foo.y (you can't change this) containing the coordinates of where the user clicked.

    Oddly enough the idea of having a generalized mapping was rejected in part because they didn't want to make Mason "HTML specific"! Instead, apparently, they want to force everyone into a lowest-common-denominator between Perl and whatever they are using Mason to interact with.

    I used to think Mason was great, but this poor design philosophy forced me to abandon it in favor of tools that are designed with quality in mind.

    -JF
  • I have found myself writing a templating mechanism in perl,

    AAARGH! Another one! Another goddamn DIY html templating mechanism! Have you ever *thought* about looking on CPAN? Do you know that there are dozens of different html templating/perl embedding packages out there already?

    Code reuse. It's a good idea. This means you. Do some research before you start typing.

    Here's one:
    www.perldoc.com - HTML::Template [perldoc.com]

    Here's another:
    www.perldoc.com - CGI::FastTemplate [perldoc.com]

    And here's an archived thread of people who know more than we do talking about these things:
    templating:html_perl_separation_&_perl_embedding [grin.net]

    Personally, I recommend Mason. When in doubt, always go with the most powerful tool you can find: so you know the choice won't limit you later. And yes, it is possible to use Mason in an organization where the HTML people are too stupid to be let near perl: I've seen it done. You just keep the Mason calls simple, and keep the complexities out of their face.

  • by kyz ( 225372 )
    may I recommend that you use ASP instead?

    You certainly may, Mr troll. Anything that's good enough for Cleopatra is good enough for me.
  • Is this realy a good idea? Especialy since there is a root exploit for every known version of perl in existance? Perl doesnt and will never run on my machine.

    Absolutely. I threw my computer away because having one just an invitation to the script-kiddies.
  • I think he is refering to the fact that perl is a language commonly used for writing root exploit scripts - perl is very powerful in terms of the fact that you can do a lot in a few lines of code (hence obfuscated perl contests).

    His mistake (or probably troll) is in the fact that the waekness is not in perl - perl is just usefull in expoilting the weaknesses in other software.

  • chilisoft [chilisoft.com] ASP [chilisoft.com]
  • Modsnake [sourceforge.net]

    allows you to embed Python Power statements directly into HTML code. Perl is quite cool too, but I don't know how good it would be for new programmers (post 1994). I think that the majority of new programmers will choose Python over Perl, but older programmers who are familiar with Perl will probably stay with Perl.

    I've used Perl in several of my projects, but more often than not the project consisted more of Python code. Well, a mixture between Perl, Python, Java and C isn't unusual in some large projects, but 70% of the code, you'd find, will probably be Python.

  • by Anonymous Coward
    hmm. Can we say CPAN [cpan.org]?
  • Embedding scripts in HTML can be done in a way that minimizes problems when you change appearance and empowers designers. Generally, if you create some high-level functions with easy to understand parameters, you can pass that info on to people who are doing the client side design and have them incorporate things nicely.

    As a *simple* example, suppose I've got a list of frequently changing links that I want displayed on any page in a given site (let's also say frames are out). I can throw the links in a file or in a database, and create a PHP function
    showlinks();. I pass this on to the client side team, and wherever the list of links is to appear, they just include:

    It's just like they got a new tag to play with (hmmm. This reminds me of something else ... starts with an x...).

    This can get more difficult, obviously, as things get more complex, but if you're willing to put in the work to do the proper abstraction, and you have client-side folks with a few ounces of intelligence, it seems to work pretty well in many situations.

    --
  • The most bugs!

    ;-)


    --
    Fuck Censorship.
  • I agree that mixing code and markup can be a mess. It's easier for web designers to mess up your code and harder for you to see the logic through all the HTML presentation.

    Gee, have you guys looked at Microsoft .NET yet? It lets you separate the two very effectively. Even if you don't want to USE Microsoft products, it's okay to LEARN from them.
  • One that I think is particularly cool is the ability (also present in JSP, I believe) to create custom tags tied to a "code behind" mechanism.

    I haven't looked a .NET much yet, but I know they didn't invent custom tags. ColdFusion has had custom tags for years. JSP also has "taglibs" which do this.
    ---

  • They voted you down because you're black you know.

    -- Eat your greens or I'll hit you!

  • The Masons's play Onreal Tournament... kkk00L!

    -- Eat your greens or I'll hit you!

  • Just from glancing at Perlet Engine it seems to have so much HTML definitions (not tags, but you specify p then pass it attributes) inside the code rather than a template - why? I mean aside from remembering to close tags why does Perlet bother with tags that much? Why is this from Perlet any advantage over a regular anchor tag?: [a => {href => 'http://www.yahoo.com'}, 'Yahoo']

    -- Eat your greens or I'll hit you!

  • $495 for single CPU machine??? I don't think so. PHP all the way.

    DanH
  • ASP is backed by the world's largest company

    Um, GE has the largest Market Cap [yahoo.com]

    GM has the highest Revenues [fortune.com]

    GE has the highest profits [fortune.com]

    WalMart has the most employees [fortune.com]

    So what has microsoft got?

  • I imagine as a fundamentalist Christian, he might be a little appalled to find his life's work being perverted by being associated with a product named after a secular humanist anti-God, power-mad secret society.

    That's marvellously wrong. Masons are paid-up fundamentalist proddy godslaves (ie they believe in the OT+NT bible, the Queen, and the divine right of men to 0wn women). And from Larry's lovely chapter in the Open Sources book, I doubt he's a redneck fundie himself.
  • by AndyS ( 655 )
    Aside from the screaming obvious troll - unless you use perl in your ASP page you are virtually guaranteed that it will only run on IIS. Whereas using systems such as Mason runs on Apache, which is supported by IBM, a very big company that will be around for a very long time.

    This is assuming you want to embed this straight into HTML, which I'm personally not the greatest fan of, but that could just be me.

    Of course, you can always pay somebody to develop Mason for you, or do it yourself. Something you can't do with ASP. If Microsoft realise that putting content and style together is a really bad idea and create something new then you are stuck, whereas as long as people use Mason in large numbers you are more likely to find people who can help.

    So, instead of being able to hire some cheap VB programmers and be stuck to Windows, you might have to hire some programmers who actually have some idea of what they're doing and be able to use both Windows and Unix, as well as having significantly more control over your destiny and the destiny of the tools that you use. It's not quite as cut and dried as you make out.
  • Look, I've been using PHP and Perl for a few years now. For the last year or so, I've stopped putting any HTML markup in code.

    Doing so, plainly sucks.

    So whenever I see a tool that trumpets the virtues of putting perl/php/etc into HTML code, I really shudder. Because that will be an example of code that will be really hard to change/maintain later. (sigh)

    USE TEMPLATES!!! It will be so easy to change your interface later and to update your code too.

The moon is made of green cheese. -- John Heywood

Working...