Scott, No what I am looking at has nothing to do with the actual signon.
To explain this a little better, this module that I am creating is designed for one of our customers, but it will be different depending on the customer. So I was looking at a façade to minimise the code, now if I understand this correctly. I should be able to write a piece of code that knows nothing about what it has to do, just do what it is told too. For example a CRUD might have a façade to the database drivers and the façade works out what database driver to use. So in this case, I want a façade to have methods called, but depending on the requirement it either asks for a car, or a bike object, and in this case if the required module for scooter was required but is not defined as an option to use then we use the default methods. So I guess if I had a database operation, and I didn't need to know what database I will be connecting to I would have a façade to interface to, which calls the crud methods without me knowing which database calls to make etc. And if the mySQL database hasn't been implemented then it would be using generic database calls. Hope that clears it up a bit better. Still learning here. Regards Andrew Scott Analyst Programmer CMS Transport Systems Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9699 7988 - Fax: 03 9699 7976 Quote: Dilbert's Words of Wisdom: Accept that some days you're the pigeon, and some days you're the statue. ---------------------------------------------------------------------------- -------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Monday, 28 November 2005 11:03 AM To: [email protected] Subject: Re: [CFCDev] Facade - how to? Hi Andrew, Sounds like your building a single sign in, with optional Authenticators being slotted in depending on the context of the user? If that is correct, inheritance can still play a role, but i'm thinking that facade is probably not the pattern you are after, more of a factory implementation (ie think CreateObject("type","path")) and follow suite. I'll take a stab here, and propose an alternative work-around that may help (assuming the above is the case). Using a configuration of some kind (XML, DB etc) you can assign what "Authenticators" get used and in what order, then when a user initiates a security handshake, this list is then processed accordingly. Its then up to the Authenticators themselves to carry out their respective operations (ie SecurityParentClass doesn't care "how" NTAuthenticator, DBServerAuthenticator etc carry out their life cycles, so long as an expected output arrives). This negates to the need to have a messy inheritance setup, as based on what you've outlined, i can only think that maybe composition is the best bet and using a "CollectionManager" style class to manage its creation/destroying/cache etc. On 11/28/05, Andrew Scott <[EMAIL PROTECTED]> wrote: > > > > Nando, > > > > I am writing a set of components that can be extended, these abstract > classes have the basic functionality required, which can then be extended > using objects very straight forward. > > > > The problem I have is that I have a situation where I have the ability of > multiple sign ins to a system, this system is company based. So when someone > logs into this application they can be from any company that is setup in the > system, now if I extend these components ti give each company the > functionality required for this particular task, and if we setup a company > that looks for that object if it isn't there then it is to use the super > method. > > > > Hope to have explained this a little better. > > > > > > > > > Regards > Andrew Scott > Analyst Programmer > > CMS Transport Systems > Level 2/33 Bank Street > South Melbourne, Victoria, 3205 > > Phone: 03 9699 7988 - Fax: 03 9699 7976 > > > Quote: > I bet the human brain is a kludge. - Marvin Minsky > ---------------------------------------------------------------------------- -------------------------- > > ________________________________ > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Nando > Sent: Friday, 25 November 2005 4:31 PM > To: [email protected] > Subject: RE: [CFCDev] Facade - how to? > > > > > Andrew, > > > > > > Something here i don't get. Why wouldn't a class be available? Did someone > forget to write it? Does your application accept "outside requests" to > create classes that may or may not exist? > > > > > > You could use a try / catch block and if CreateObject() throws an error, > catch it and create your default class. But if indeed that's along the lines > of what you're after, something seems a little amiss in the architecture. > There may be a more solid way to do what you need. > > > > > > Maybe the exact detail would help flesh it out, rather than a theoretical > explanation? > > > > > > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Andrew Scott > Sent: Friday, November 25, 2005 4:16 AM > To: [email protected] > Subject: [CFCDev] Facade - how to? > > > I was hoping that someone might be able to help me out here; I am looking at > creating a super class which can be extended by child objects, simple > enough. But I also need to create a fa?ade to interface to these objects. > > > > Now I have been reading this list awhile now and not 100% sure on how to go > about this. The fa?ade needs to know what type of object to return, based on > criteria for example this is what I am thinking. > > > > Vehicle Super > > > > Car Child > > > > What I am interested to know, is how to I go looking for the required class > and return a default class if the object I am looking for Is not there, so > if I was looking for a bike and that class wasn't available return say a > default of the Vehicle class or something. > > > > Anyway I have the concept just not the know how to go about it, so I little > code examples would be good thanks. > > > > Sorry if this has been asked a thousand times already. > > > > > > > Regards > Andrew Scott > Analyst Programmer > > CMS Transport Systems > Level 2/33 Bank Street > South Melbourne, Victoria, 3205 > > Phone: 03 9699 7988 - Fax: 03 9699 7976 > > > Quote: > "Space...is big. Really big. You just won't believe how vastly hugely > mindbogglingly big it is. I mean you may think it's a long way down the road > to the chemist, but that's just peanuts to space. " Douglas Adams > ---------------------------------------------------------------------------- -------------------------- > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] -- Regards, Scott Barnes http://www.mossyblog.com (?ryhq z?? &gu?q??+al? &q z?^yh~^zf7?&h}?.+[!W -x qab?ovrz7+-Uj)ZnW 0fr{(q?? ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
