[Melbourne-pm] Perl web application framework recommendations

Daniel Pittman daniel at rimspace.net
Sat Aug 14 05:42:43 CDT 2004


On 14 Aug 2004, Scott Penrose wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 14/08/2004, at 7:43 PM, Daniel Pittman wrote:
>
>> I am looking at doing some web application development, both to keep my
>> hand in on the programming side and because I have a need for a couple
>> of database driven tools.
>>
>> I have taken a look at a variety of packages out there, and now I am
>> looking for recommendations about which ones actually work *well*.
>>
>> So far, the three options that look worth considering are OpenInteract,
>> Maypole and writing my own framework.
>
> Also consider http://www.axkit.org/

I should have mentioned looking at it, and deciding that XML and XSLT
were not what I wanted to use.  

>> Also, in terms of modeling the data, one issue that I have is that I
>> need to store an ordered set of objects associated with a given object.
>>
>> I also don't fancy writing my own database persistence layer, if I can
>> at all avoid it, so I have been looking at those.
>>
>> So far, only Tangram seems to offer this functionality, and this is not
>> well spoken of in a google search, and the lack of a home is also not
>> very inspiring.
>>
>> Does anyone have anything helpful to offer, or especially a Class::DBI
>> based solution with code, to achieve this?
>
> Hmm.. my problem with things like Class::DBI is that OO and Relational
> are not the same paradigm.

No, they are certainly not. If there was an OO-DBMS worth using as
anything but road filler out there, I would be looking at using it
instead. :)

> But you are probably talking more general data persistence, which can 
> optionally use a DB or similar.

What I want, pretty much, is something that does the hard work of
writing the annoying little SQL interactions for me, so that I can have
something that resembles a Perl object in my code, and that stores the
content in the database.

Class::DBI is good at this, since it doesn't try to do anything clever
or helpful to present OO semantics wrapped over relational data, but
rather automates the hard work of writing a wrapper class for every
table and relationship in the database.

> If you have just your local code talking, reading/writing to this data
> storage, you should consider using a file system with directories and 
> something like Storable (fastest of the serialisation code).
>
> The performance will be far greater than any other solution.
>
> There is two downsides though:
>
> * No indexes (although there are ways of doing this, eg:
> http://www.namazu.org/)

That would require a serialization that was more amenable to standard
search engine queries than Storable, though. :)

Also, this addresses object persistence to some degree, but does not
object relationships in a quick fashion, usually. 

> * Not standard with other code (eg: if you want to mix Java and Perl
> accessing same data)

I think you also missed the third, and fairly major, point here:

This also means writing my own serialization layer, and paying attention
to things like object identity and rapid storage.  This is a world of
pain that, like the framework itself, I would rather avoid if I can.

     Daniel
-- 
Heu! Tintinnuntius Meus Sonat!


More information about the Melbourne-pm mailing list