use Perl

• OpenInteract comparison (Score:2)

  by lachoy (1663) <chris.winters@gmail.com> on 2004.03.02 13:56 (#28963) Homepage Journal

  I haven't taken a detailed look at Maypole yet (no tuits), but just off the top of my head there are a number of similarities between Maypole and OpenInteract (I'll focus on the still-in-beta OpenInteract2 because it's got a lot more going for it). Generally OI2 is much more heavyweight and designed to adapt to more environments than Maypole. But that doesn't mean it's better -- as usual flexibility comes at a price, in this case complexity. And as usual whether this complexity is worth it really depends on what you're doing.

  • OI2 is very big. The HTML doc snapshot [sourceforge.net] for the next beta weighs in at 1.3 MB -- and some parts need better docs :-) As a result you need to do more work to startup a new system, although the quick start guide [sourceforge.net] helps out with that.
  • Both rely on the Template Toolkit, although OI2 supports additional content generation methods (pluggable, and it's distributed with support for HTML::Template and Text::Template)
  • Both are tied to an object-relational mapping solution -- OI2 uses SPOPS while Maypole uses Class::DBI. But I think both can use other solutions without too much problem (that is, using SPOPS objects in Maypole and Class::DBI objects in OI2). Class::DBI is generally simpler than SPOPS but SPOPS also does LDAP and some mildly interesting stuff with security.
  • OI2 seems to be more internally declarative. (Keep in mind, this is based on a cursory look at Maypole -- I wouldn't be surprised if under the covers they did much the same thing.) So in Maypole you map a URL to an action (represented by a PerlHandler) using Apache. In OI2 a package (or distributable application) contains an 'action.ini' file which registers classes (and optional parameters) with the framework and tells it what names it will respond to. Another component is responsible for mapping incoming URLs to names. You also declare if an action is secured, what methods are not allowed, and more. In fact comparing the beer DB example from Simon's weblog entry to the OI2 package development tutorial [sourceforge.net] is pretty useful -- note that the first part of the tutorial does things the "longer" way, the second part introduces the 'common' actions and does it more declaratively.
  • You can use OI2 under multiple environments. Currently Apache 1.x, CGI and LWP are supported, with a working (but probably suboptimal) version using Apache 2.x in the next beta.
  • OI2 focuses on creating distributable, standalone applications. So I can send you a zip file (foo-0.01.zip) and you can run
    oi2_manage install_package --package_file=foo-0.01.zip
    oi2_manage install_sql --package=foo
    And have it install that application's database structures, initial data, templates, static HTML pages and images, configuration, classes (including actions, TT plugins, normal Perl classes), localized messages (in the next beta), etc.

  There are almost certainly more differences, but I have a non-Perl day job to get back to :-) That said, I think the application server problemspace is sufficently complex that having multiple solutions are extremely useful.

  Reply to This

  • Re:OpenInteract comparison (Score:2)

    by Simon (89)

    On the whole, I agree with Chris! However...

    Generally OI2 is much more heavyweight and designed to adapt to more environments than Maypole. But that doesn't mean it's better -- as usual flexibility comes at a price, in this case complexity. And as usual whether this complexity is worth it really depends on what you're doing.

    True. Maypole aims to be as simple as possible, while still enabling you to do the complex things if you need to. The Orkut-alike was designed basically as a test to make sure May
    • Re:OpenInteract comparison (Score:2)

      by lachoy (1663)

      Maypole does this with attributes, which is quirky but fun.

      That's an interesting idea. For some reason attributes always seem a little peek-a-boo to me, but that's probably because I haven't hung out with them enough.

      One of the more obvious comparisons I forgot: Maypole has a much better name than OpenInteract!
      • Re:OpenInteract comparison (Score:2)

        by Ovid (2709)

        What do you mean by "peek-a-boo"? If handled properly, they can provide elegant solutions. For example, what if you want your subroutine to return a list in list context, a reference to an array in scalar context and die if called in void context? You might write this:

        sub foo {
            # do stuff
            return wantarray
                ? @array
                : defined wantarray
                    ? \@array
                   
        • Re:OpenInteract comparison (Score:2)

          by lachoy (1663)

          I understand what attributes are, it's just that they have a fairly large potential for misuse. (Then again, so does Perl...) I agree that they can be extremely elegant and the example you gave is great, but often they're used for application-level behavior like security, web services, etc. I have a suspicion (perhaps unfounded) that it's better and easier to maintain to have this behavior external to the code so it can be modified externally.

          But I'm probably concerned over nothing :-)