jamtronix

My current object design like this:

Base class - RESTicle (REST Particle)
 Attributes:
  ID:  (unique across all RESTicles)
  Parent: (pointer to another RESTicle)
  Name: (text for humans, not necessarily unique)
  Type: (text for humans)  
   
  Children:
  1 named collection for each type

 Methods (default implimentation in base class, can be overriden):
 
  html : (get only) render self to html (as form, in a table, with meaningful CSS class names)
  xml : (get/set) serialize/deserialize

Then a bunch of descendant classes of the above, that map to things like users & bills.

still haven't decided on persistence yet. some options here or maybe using perl hashes tied to DBM files.

But this is starting to look a whole lot an ISP billing and configuration management app I worked in the late 90s called Hyper(my second system actually). It was a colllection of C++ objects, each of which descended from a base class (HyperObject) that had a ToHTML() method that displayed a form of modifiable attributes, plus an ISAPI layer that could render a HyperObject including links to each objects child and parent objects. The advantage of this was that when implementing a new "business logic layer" object type, (say a DialupAccount) I just had to define the classes attributes, and take care of integrating those attributes with other systems, ie if you made a new DialupAccount object, it should get recorded in both the database used for billing and in the RADIUS database). But I didn't have to mess around building HTML forms - the framework took care of all of that. But the biggest problem with this design was there was no easy way to make the HTML look good, or build task-orientated (rather than object orientated) screens. i.e. to sign up a new customer for a dialup account (a fairly common task), you had to go to the app start page, click 'customers',click 'new', enter the customer details, click 'save' , which would bring up a customer record screen, then click 'dialup accounts', which bring up an empty list of dialup accounts, then click 'new' and put in the details for the new account. It would have been much nicer for the customer service people to have a single form that let you put in all the details for the customer AND the dialup details at once. But the architecture didn't really let you do that easily. Also, the HTML was pretty stark, since I didn't want to have font faces and background colours, etc, hardcoded in the C++ codes, and CSS - capable browsers weren't available yet.

Which is why the apps I worked on after that, I dropped the idea of self-rendering business objects,and went back to a classic '3 tier' approach with a bunch of asp/aspx forms with forms in it, and on each page, lots of tedious cutting & pasting & fiddling to map business layer objects to tables & forms that are boring to write but look nice and are easy to use.

Now in some ways this RESTicle design is really  just the Perl equivalent of those C++ HyperObjects. But it seems like CSS and AJAX allow building slick task-orientated user interfaces on top of a basic object-orientated web app. i.e. I can focus on building business logic, and have that logic easily available through a browser, and then some-one else can make that functionalitity useable and pretty.

Where's the catch? Apart from needing to find someone who can hack javascript & CSS of course.