|Perl Monk, Perl Meditation|
You're right, I should be using a role in that place. I've had in my mind that a limited number of roles would be easiest to manage, but I don't think that's right either. But on the other hand, do I really want a role for each system/element/connection/etc on our network
I'm also struggling from moving my mindset from normalized tables to object oriented constructs.
What I want in the final analysis, is to have a list of systems (on a web page using Apache/Catalyst/Mason) in a tabular format with basic information displayed in the list, including the user id for the point of contact (or owner) of the system. Clicking on the system name will bring up more detailed information about the system (elements, trouble tickets, maintenace procedures and schedule, disaster recovery... I've put in those tables, but they are commented out, at the minute). Click in the PoC will bring up additional info about the owner, such as email and full name.
I've built systems like this many times, but never in an object oriented fashion. I've always been a fan of OO and decided to try it, but I'm getting bogged down on the basic stuff... do I have to built the interrum tables, like the ones that mantain the relations between systems and roles or roles and users... when elements get added to the mix, do I add them through some interface on system or do I just add the element to the elements table update the relationship table by hand? For that matter... and I'm still reading... how do I retrieve the elements when I want to display them.
an example of a system:
--Jimbus aka Jim Babcock
Wireless Data Engineer and Geek Wannabe