ryantate has asked for the wisdom of the Perl Monks concerning the following question:

I'm a part time hobbyist coder, and the other day I realized I've spent two years already building my knowledge and Perl codebase toward the launch of a somewhat sophisticated database-backed website -- and I've still got a year or so to go.

I've come to love the perl components I'm using, including Class::DBI, Template Toolkit, Plucene and CGI::Prototype. I just migrated to an apache2/mod_perl2 installation from CGI and found it a surprisingly smooth transition. I don't regret spending two years learning about Perl and various modules, or the five years learning Perl prior to this project.

But today I began wondering if my wheel reinventing has gone beyond the educational stage and into the "wasting valuable time" stage. I began designing the data model for a needed feature -- Web content versioning inside the database -- and looked at how the (Open) ArsDigita Community System (history, what it is) does it, since that toolkit has been around for a while. Not only do they have a pretty sophisticated approach to this issue, platform developers have already solved a number of other problems I envision facing.

I have avoided ACS in the past because it is based on TCL and I already know Perl, and as a hobbyist my resume and skillset are NOT enhanced much at all by knowing more computer languages. As such it seemed a likely uphill fight to extend ACS. Also, it requires use of the AOLserver Web server, which does not have a mod_perl equivalent.

At this point, though, I am starting to think the time required to learn the neccesary TCL might be significantly less than the time needed to build what I need in Perl (and no one Perl package out there has it, although many are quite good in individual roles like CMS or simple CRUD).

This leaves one critical reservation: I have never worked with OpenACS and do not want to invest the time to learn the system IF it is going to be too hard or painful or inelegant to extend.

Thus my question: Have any fellow monks worked with OpenACS or ACS in the past?

Follow up questions: What was the experience like? Most critically, did you need to extend the system and what was THAT experience like? How was it working in TCL and did you feel held back not having CPAN at your fingertips?

Advice of all sort from all quarters welcome. Thanks for any help.

Replies are listed 'Best First'.
Re: Perl vets on OpenACS?
by kscaldef (Pilgrim) on Jun 24, 2005 at 02:44 UTC
    I know a little about ACS, but stopped using around the time OpenACS really got going. I can't say much about going from Perl to TCL, though, as I went the other way.

    TCL syntax is a little odd and has one or two tricks up its sleeve, but really only one or two. It's a very easy language to learn, and much harder to get into trouble with than Perl. (So long as you have the good sense to avoid uplevel and upvar).

    I think that the lack of CPAN will be greatly obviated by the fact that virtually all common functionality you might need to build a database-backed website is provided in one ACS package or another. Typically, the only place you will need to "extend" the system is for whatever it is that makes your site special and unique.

[reply]
      Thanks, kscalef, that's really useful feedback. I had heard similar things about TCL but from people already predisposed against perl and other "messier" languages. Also I agree ACS seems very complete. Interesting you stopped using ACS -- why was that?

      I guess when I say "extend," that's a little vague. Let's say I want to start a community-driven site devoted to, using a common example, beer. In addition to articles and Q&As and comments and reviews and all the usual ACS content, I also want the database to hold information on the beers themselves, including brewery and type (porter, stout, ale, lager) and so forth. Then one could query beers on all sorts of different criteria, from location to type to the date it was first brewed.

      I know how to do this in Perl using various modules, and I know the SQL that would be required for the DB stuff. I guess what I worry about is integrating such new "object" types with all the other services ACS provides, ranging from full text search to the comments and reviews.

      Another example would be customizing the full text search results to sort by date, or to screen for certain terms ("home brew" automatically puts the home brewing howto and forum first, for example). I could do this in a snap with Plucene but ACS -- not sure how easy it'll be.

      Anyway, thanks. At some point I guess I'll have to try this thing if I decide to stray a bit off the Perl path. It just seems like a very mature platform even though it's not Perl and Not Invented Here ;->

[reply]
Re: Perl vets on OpenACS?
by TimButterfield (Monk) on Jun 24, 2005 at 21:11 UTC
    I use both Tcl/Tk and Perl, depending on what I am working on. The Tk part is usable from Perl anyway, with Tcl::Tk. The Tcl language part is easy, possibly easier even than Perl. The biggest complexity, as with many things, is learning the library framework you are using it in, i.e., the CPAN vs OACS frameworks.

    If your module can work outside of OACS, even if it uses the same database as OACS, you may wish to investigate using both AOLserver/OACS and Apache/mod_perl together, even on the same server. The Apache/mod_perl could be the primary web server, listening on port 80, and it could use mod_proxy to pass OACS requests to AOLserver. There was also a mod_aolserver if you want to try getting OACS to run under Apache, though I do not know what the state of the module is.
[reply]
      Thanks Tim, this is great. I had no idea mod_aolserver existed -- I'll have to see how supported it is. RE getting perl to access and mainpulate the OACS data, this might not be as hard as it seems -- from cursory inspection much of the data model seems to be controlled on the RDBMS side by triggers and stored procedures.

      In fact if it is the case that the vast majority of db transaction logic lives inside the DB itself (as it would appear from a quick read of the docs for the current 5.2 version), perhaps even a PerlACS may some day be viable, using the same RDBMS code but called from perl/mod_perl2/apache2.

[reply]

Back to Seekers of Perl Wisdom