Perlmonks is a bit of an embarrassment

The site is painfully slow, not really a good advertisement for Perl as a web implementation language. And now the latest revelation is that passwords were stolen because they were stored in plaintext. I hate to say it, but perlmonks is probably a significant reason why Perl is a language in danger of dying out. Not just the technical issues (although perlmonks is a painfully difficult site to use), but cultural as well as there's a rather hierophantic attitude on the site, maybe no worse than at similar sites of other technologies, but my impression is that it is.

Stripes

I came across a reference to Stripes while trying to figure out how to handle some mapping issues in Spring MVC, so I'm taking a look at it and trying to use it in place of Spring MVC on the view part of a learning app I'm building. My property mapping question is explicitly answered in the documentation, which makes me feel comfortable with the prospect of working with Stripes, although the instructions for installing and using the Stripes archetype failed badly in my environment. I'll come back to this at some point in the future, I suppose, assuming that Stripes does all that I would like it to and I'll skip that. But in the meantime, it doesn't appear that I really need it for what I'm doing, so I'll happily continue on my way as I develop my app.

CSS z-index not working

It's worth noting that z-index is only applied to absolutely positioned elements.

Arg, Perl attributes don't do what I want them to

Apparently, there is no way to get the name of a non-subroutine with an attribute. That means that if I want to annotate fields in a class for serialization, I need to identify the column for each one. On the plus side, I guess that means that I can move pass this particular hurdle (for now, at least).

Time to start again

I had thought that Attribute::Handlers was going to be the quick and easy solution to dealing with attributes for my ORM, but it turns out that it can only get the name of a subroutine with an attribute, not arrays (or hashes). I'm thinking that perhaps the solution is to (old-school) subclass Object::InsideOut and integrate with its attribute parsing code... This would also enable me to see the :Type attribute from OIO.

A roadmap for my Perl ORM

Mostly for my own purposes (and subject to modification).

0.1 Handle serializing a simple OIO class
0.2 Handle de-serializing a simple OIO class
0.3 Allow embedding classes (1-1 relationship) in a class (serialize/deserialize)
1.0 Allow 1-many, many-1, many-many relationships between classes (to separate tables, using join table if necessary)

Thoughts on ORM in Perl

One thing that I really admire from Java world is the EJB3 Persistence annotations. A class can be made persistent with a simple mark-up:

@Entity
class Foo {
   private int count;
   private String name;
   @Transient
   private int temp_var;
   ....
}

The @Entity notation indicates that the class should map to a table (unless overridden, it will use the class name as the table name). Every field then automatically maps to a column in the table (column names can be overridden) unless marked with the @Transient annotation.

I was thinking that something similar could be executed in Perl using perl attributes. I could do something like

package Foo;
use Object::InsideOut;

my @int :Field :Entity;
my @string :Field :Entity;
my @temp_var :Field;
...

Using something like Object::InsideOut seems essential for this sort of attribute-based mark-up, although perhaps I should look at Moose instead (although that does seem to have some significant performance penalties). There are some questions about how to handle exporting the serialization routines. Should I work towards a DAO solution or set up serialization routines directly in the class (perhaps as protected by default with the class making a decision about whether to provide public methods to expose these to clients.