byterock

Well not really.

Any of us pre-web people might remember a nifty new language called Java that made a splash on the world just as the web was beginning.

The time I first started with JavaBeans there where a set of I think about 75 encapsulated GUI objects in a 'jar' file, get it 'a jar of beans' or at least that is what the myth is*.

Anyway one was suppose to use these beans to assemble you GUI program, and this was to lead to all sorts of time saving as you could just re-use componetes for all sorts of projects. I think in my about 7 years programming with Java I never ever actually used a classic JavaBean from Sun.

Anyway within a short few years the Web saw the use of JavaBeans expand and their use in non UI based roles absolutely dwarf their original intention as a building block in classic UI programs.

Well what does this have to do with Perl? It turns out the concept of a serializable object that allows access to its data only though setter and getter methods is a very useful tool when making web based applications.

Some years ago when trying to bring some order into a rather chaos filled Perl application I used the 'Bean' concept to consolidate about 3000 individual SQL calls on about 200 pages into about 70 little 'Beans'. A somewhat better situation.

Now at that time in the dim past about the most advanced perl project that was about was Dancer .8 and CGI was still state of the art.

Needles to say doing a bean at that time was rather laborious task as you had to write out each setter and getter like this

sub set_plan {
    my $self = shift;
    my $val = shift;

    # Assignment

    $self->{action_plan}{plan} = $val;

}

 sub get_plan {

    my $self = shift;

    return( $self->{action_plan}{plan} );

}

and if you happened to have 30 fields in a DB.Table you could taking quite some time merrily typing away and hopefully you did not have too many simple typos

At the start I just has some simple commonly named functions that I would overwrite for each bean and they where get_data, create_data, delete_data and update_data. A simple enough API though at this time the SQL was still all custom but that did not bother me too much as I sat in a room with 25 DBAs at the time.

The above approach did save some development time as any new page only needed a new Bean and some inline HTML to work. I at least banished the inline SQL spread over any number of pages.

So at the early stage I was able to consolidate a good deal of code in one place and at least take advantage of some code reuse and a little more rapid code production even had some of the business rules consolidated in one place.

I did start out with a CPAN module that would write the Beans for me but I soon dropped that as I made more typos creating the config files that just doing a copy and paste job from one bean to another.

I finally settled on a template Bean that has most of the base code stubbed in all I needed to do was substitute in my new values and rename the file. An improvement but not much of one.

* supposedly the naming of Java and its components is all 100% arbitrary after the fancy suit layers at Sun discovered 'Oak' would have trade-mark problems so they picked the first name that came up that could be more easily trademarked. The other story about the developers drinking too much WBS** coffee is much cooler though.

** Way before Starbucks