use Perl

• OpenInteract comparison (Score:2)

  by lachoy (1663)

  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
  • Re:OpenInteract comparison (Score:2)

    by Simon (89) <simon-use-perl@perlhacker.org> on 2004.03.02 17:13 (#28974) Journal

    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 Maypole could actually do the complex things relatively easily. But OI2 is certainly bigger and chunkier, and possibly better suited to more environments - Maypole is meant to be sleek and generic, and I hope I've designed it well enough to be generic but it hasn't been stressed in as many environments as OI2 yet.

    OI2 is very big.

    That's because you have documentation, you cheat! :)

    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.

    Yeah. I wanted Maypole initially so that I could run up really really quick interfaces to databases. The fact that it does more is a bonus. I'm a big fan of obviating as much code as possible and generally doing what the user means. As you say, there's always a trade-off for that and Maypole and OI2 sit at different ends of the scale.

    Both rely on the Template Toolkit, although OI2 supports additional content generation methods

    Maypole does too, but the Template Toolkit is Too Damned Good so nobody's written any other View classes yet. :)

    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).

    Yep.

    Class::DBI is generally simpler than SPOPS but SPOPS also does LDAP and some mildly interesting stuff with security.

    There's your simplicity-functionality tradeoff again.

    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.

    Yeah. Now you can override the mapping method in Maypole - or indeed any of the methods - but it's intended to give you sensible defaults that do what you mean. In fact, the mapping method isn't in Maypole at all - it's in Apache::MVC.

    You also declare if an action is secured, what methods are not allowed, and more.

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

    In fact comparing the beer DB example from Simon's weblog entry to the OI2 package development tutorial [sourceforge.net] is pretty useful

    There's a much longer Maypole article coming out on DeveloperWorks soon, hopefully, which not only talks about simple stuff like the BeerDB, but also how I put together Flox.

    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.

    Again, you got there first, and nobody's implemented the front-end classes for Maypole yet. That said, I got some patches to support Apache 2, and so there'll probably be a CGI::Maypole coming out this Thursday.

    OI2 focuses on creating distributable, standalone applications.

    *nod*. Maypole doesn't touch this.

    I think the application server problemspace is sufficently complex that having multiple solutions are extremely useful.

    No quibbles there.

    Reply to This

    Parent

    • 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 :-)