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

Fellow monks:

I've spent many hours each day of the last month learning as much about Perl and CGI as possible. I'm proud of the progress I've made and I've already written a few short but useful scripts. But now I'm interested in "graduating" myself to an intermediate level of Perl expertise by writing a more extensive and complex script. The goal I've set for myself is to create a web-based utility similar to this. So, yes, I am aware this idea has been done. As I said, I'm doing this for the experience.

Some of the basic requirements for this calendar are:
***It's searchable
***It is large enough to extend back one year in time and out one year into the future
***Others can post to it
***Postings must be approved by me
***It can handle repeat events (e.g. third Thursdays of every month)
***It's easy to add and edit entries
***It has a user-friendly interface (clickable text-based calendars, etc.)
***Speed...all web pages will be straight .html and created only when changed/edited.

I know something like this would be best handled with a database but I haven't learned anything about web-based databases yet. So instead, I thought about using a flat file directory tree structure to mimmick a calendar. I would have a "Year 2001" folder which contains its respective .html files and 12 folders for each month. Each of the 12 folder would contain the appropriate .html files and 30/31 text and .html files for each day. The text files would hold the actual data.

My questions to my brother monks:
Does this flat file approach sound like killing an ant with a shotgun? Is there a better, more efficient approach I should be looking into?
What modules would be most useful to me?
Any other general recommendations or helpful guidance I should consider before I start?

Replies are listed 'Best First'.
Re: General guidance requested
by chromatic (Archbishop) on Apr 04, 2001 at 22:06 UTC
    Depending on how often your calendar is called and how many people are likely to use it, that approach is certainly workable.

    For your sanity, I would recommend you invest a little time in learning how to write a module with a sane interface, so you can keep the data access methods in one place. In the future, if it becomes necessary, you can write another module with the same interface to talk to a DBM file or a relational database.

    It's much less work that way. It's also good experience.

    It would be more efficient and scalable to start with a database, but I'm starting to believe that you shouldn't add complexity you don't (yet) absolutely need.

[reply]
Re: General guidance requested
by dws (Chancellor) on Apr 04, 2001 at 21:51 UTC
    Representing calendar data is pretty straightforward. All you need is a way to represent fixed dates. Mapping those onto a calendar page is easy. But when you introduce the notion of repeating events, the problem space notches up in complexity. You then need a way to represent "events", and to provide a way for mapping events onto fixed dates.

    Martin Fowler, author of (among other things) Analysis Patterns has a paper called Recurring Events for Calendars which may well worth your time to read.

[reply]
Re: General guidance requested
by physi (Friar) on Apr 04, 2001 at 20:57 UTC
    Nice project ;-)

    But I think you should try to get familiar with databases, cause this project you're thinking of, IS a database. You can use for example CSV for a low budget Database, or maybe you use one off the free DB's.

    If you can handle perl in that way to build you calendar, it would be a easy thing to learn a quick SQL + DB before ;)

    Have fun with your plan. 

    -----------------------------------
--the good, the bad and the physi--
-----------------------------------

    [download]
[reply]
[d/l]
      Yeah, that's a question I should have asked: should I go ahead and learn how to use mysql first(which I do have on my server)? Your words are encouraging. For some reason, I have it in my brain that it's too advanced. I know the basics of databases and sql. How should I begin learning to work with them?
[reply]
        nysus asked:
        should I go ahead and learn how to use mysql first?

        That really depends upon what you are doing. MySQL is fast and it's okay for simple apps like guestbooks and things like that, but it's really not a great option for most serious work. It doesn't have built in foreign key restraints, doesn't allow views or multi-level selects. Probably the worst part about it is that it does not support transactions (these let you "rollback" changes if any changes fail). If, in the future, you need to expand the capabilities of your system, you may find that MySQL is a limitation -- though using DBI will alleviate much of the pain of switching to a new database.

        Of course, if all you have access to on your system is a choice between MySQL and flat files, I'd go with MySQL any day of the week.

        I know the basics of databases and sql. How should I begin learning to work with them?

        Believe it or not, the evil empire actually has a good discussion of fundamental relational database design.

        Cheers,
        Ovid

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
Re: General guidance requested
by Masem (Monsignor) on Apr 04, 2001 at 21:00 UTC
    It doesn't sound like you are doing the wrong thing -- sure, using a true database would be a better way, but there's nothing drastically wrong with what you are doing, except that searches will be long (though that could be sped up by running every so often an external program like htDig which can optimize a text search across a large number of files), or in some cases, impossible to do, but from your description, you're not looking to do these types of impossible searches.

    As for modules, you're pretty much looking at the standards that come with any perl dist: CGI.pm particularly.

    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]

Back to Seekers of Perl Wisdom