The more I think about this, the more that I think my second suggestion (I.E. an auditTrail property of the department) may be the best solution. Unfortunately, the documentation is scarce when it comes to properties and I have not done testing with component properties and how they relate to methods of those components. Do you have any additional thoughts on this one Ray?
At 05:18 PM 7/10/2002 -0400, you wrote: > > > > 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 > > > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
