> > Either one is functional. It depends on what you are trying to do. Do > you want to "log" every single time you use the edit (Insert / Delete) > functions? If so, then write the code directly into the department > component. Does "AuditTrail" have any function other than logging actions > in department? If not, there is probably no need for it to be a separate > component. Perhaps it could be a private method inside the department > component?
AuditTrail doesn't do anything other than log events, BUT it will be used all over the place, not just in conjunction with departments. Since I'll be using this all over the place I wrote it as its own component and will plan to call it everytime a logging action needs to happen. > If you truly want to apply OO concepts to your design, you may want to > look into picking up an Object Oriented design book. If you can find one > that is language independent, it would probably be more beneficial than a > language-driven book. Of course. Picking up books is always useful. In this case, though I don't have the time that I personally need to absorb book larnin' to the point where I can directly apply it. So I'm proceeding as best as I can with the knowledge that I have... And the human resources I have available to me when absolutely necessary. > > I saw Ray mentioned the possibility of inheriting the auditTrail CFC in > the department CFC. That is probably not an OO solution, since a > "department" is not an "auditTrail". This would be an is-a relationship, > and is usually implemented using inheritance. Makes sense. > A department has an audit trail, though. This is a has-a relationship, > which is usually implemented using properties. You could make a property > with the type being "auditTrail". However, I am unclear as to how you > would access methods of "auditTrail" via the property of department. ( if > that makes sense). Hmm. Sounds like a possibility, but since I've not run across any articles pertaining to the use of component properties (or if I have I haven't read them through well enough) I've been staying away from properties. So far I've just worked with my departments component which contains doer-type functions... I haven't built components that make instances of anything real. Since "properties" make me thing of instantiatable objects, I haven't considered using them... Mostly because I can't fathom how I should use them based on how I've structured the component(s) I've built so far. Mom always said I had to learn the hard way. Unfortunately in this case (only!) she may be right. > > > > > -- > Jeffry Houser | mailto:[EMAIL PROTECTED] > Need a Web Developer? Contact me! > AIM: Reboog711 | Phone: 1-203-379-0773 > -- > My CFMX Book: > <http://www.amazon.com/exec/obidos/ASIN/0072225564/instantcoldfu-20> > My Books: http://www.instantcoldfusion.com > My Band: http://www.farcryfly.com > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
