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

I've looked around and haven't found what I want, and being a perl hack, decided to write it. The problem is that I'm chasing my tail from meta-data and persistence, so I come to the masters for guidance.

My goal is an opensource web content management system based on an object-oriented database. One could simply express the form of a dynamic web site like this -- for example a book-club web site:

small group: leader(person), location, schedule
  members(person)
  books discussed(book): date, summary
  news: date, headline
   picture
person: name, address, phone, email
 news(news)
book: Title, author, publisher, number of pages, cover image, isbn
 reviews: writer(person), date, stars(1,2,3,4), headline, summary, tex
+t

[download]
This web site has three main sections: small groups, people, and books. Each of these sections have multiple content, group members, personal news, book reviews, etc. There's also a rough sense of path:
    /small group/Visionaries/members/Joe Smith
or
    /book/Wonders And Miracles/isbn

This means that the site creator has to be able to enter the meta-data for his site structure, and then of course the meta-data has a structure of its own (the meta-meta-data). I want both the data and the meta-data to saved to disk (ie persistent), and (why not) I'd like to use the same tools to implement the meta-meta-data:

classes: name, baseclass, envelope, view-template, edit-template, new,
+ update, del
  roles: name, access
  attribute: name, basetype, size, default, validation, indexing
basetypes: name, view, edit, update

[download]
I'm trying to get up to speed on modules like Class::Struct and Class::Constructor as well as persistance modules like Storable and Tie::Persistent. I had a pleasant diversion into POE, but decided that that's probably not where I'm going (although I might be mistaken) because it looks to offer persistence through a background task. I don't want to use Persistent::MySQL because there's no SQL on my target server. I also benifit for portability and ease-of-install if I can avoid DBI.

Firstly -- do I want my CMS's objects to be perl objects at all? If I write my own object interpreter I can effeciently implement persistence, access control, etc at the cost of re-inventing the wheel. But the structure is simple enough it is doable.

Secondly, if I'm using perl's objects what's the best collection of Modules to do meta-data -> objects w/ persistence?

Thanks for your enlightened perspective on my prediciment.

j

Replies are listed 'Best First'.
Re: metadata confusion for new perl CMS
by lachoy (Parson) on Jan 10, 2002 at 01:39 UTC

    IMO, this is definitely an area where you want to use objects. They will pay off many times over for nontrivial systems when you're adding behaviors that need to work on different types of entities.

    You can do the object relationship/serialization part with SPOPS. I think it's very appropriate here because it already dynamically creates persistence classes based on metadata. For instance, there's a module allowing you to build the object's properties at runtime based on the fields in a DBI table.

    Further, it dynamically creates relationships among objects from metadata -- a group has a leader(person), a book has multiple writers(persons), etc.

    Most people use it for serializing objects to/from DBI datasources but you don't have to -- creating a new serialization class isn't too difficult. (And then one of the benefits will be if you ever do move to a DBI datasource it won't be so painful.)

    I'm a little harried right now, but if you're interested you might want to hop over to the openinteract-dev mailing list and start floating ideas.

    Chris
    M-x auto-bs-mode

[reply]
Re: metadata confusion for new perl CMS
by jhanna (Scribe) on Jan 10, 2002 at 02:20 UTC
    Just as you were posting I found the SPOPS module. It bears more reading. I'm initially put off by its required modules and complexity, but it might do the trick. I'm also trying to understand the Class::Prototyped module and how it might fit into this... Ahh... so many modules, so little time... But I really am hoping to stay away from DBI.
[reply]
      You may be put off by the complexity of SPOPS because you haven't fully understood the complex things you are going to need to do to make your idea work. For example, staying away from DBI might sound good now, but if this thing works you may want to use it for a project with many concurrent users. A database like Postgres will handle the locking and concurrency issues well. If you roll your own with Storable, you will end up needing to do that yourself some day.
[reply]
Re: metadata confusion for new perl CMS
by jhanna (Scribe) on Jan 10, 2002 at 23:04 UTC
    and now I'm looking into Tie::Persistent... so many modules...
[reply]

Back to Seekers of Perl Wisdom