Stephan, Just to add something here, Nathan's post below is a good example of OO in practice. As you can see, Nathan is addressing higher level concepts. Namely what an object should know and be able to do, and how various objects are related and should work together. I can tell you from experience, it takes awhile before it begins to click!
You'll very most likely need to get your feet wet on familiar ground before you can jump into using MachII. Joe's suggestion to start with attempting to implement a little OO in fusebox is a very good suggestion, especially if you're trying to work this out on your own, without an experienced mentor at your side. That's the route i took, after realizing that even to do the simpliest thing in MachII, i needed to know how to develop a an object oriented model. In other words, i needed to know how to think like Nathan is thinking below. And sometimes you need to think really hard about something before you feel like your model starts to click into place, especially in the beginning when you don't have much experience. "What should a user be able to do? Why not just let users authenticate themselves and save myself the work? Is a Permission an object in it's own right, or just a property of User? What should i call this object? What should i call this method?" And you'll probably change your mind many times on the way as you gain more experience about how best to do something. And you'll want to refactor / rewrite your OO cfc's and try it out. To use an analogy, starting OO in Fusebox allows you to begin in a "corner" of an app, like the user login for example, experment, and see it working, while leaving the rest of the app procedural. Then you get drawn in a little deeper as you begin to modify other corners. You then might find yourself completely rebuilding 2 "corners" in a different way and adding a "wall" between them. Then you might tear it all down, and do it again, this time properly encapsulating your objects and experimenting with using composition rather than inheritance. It's a lot of work to learn, but it's well worth it. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Dintenfass Sent: Tuesday, July 12, 2005 8:32 PM To: [email protected] Subject: Re: [CFCDev] OOP and creating a login section An alternative perspective is that "theUser" should not know how to "authenticate" itself. Rather, you might have an "Authenticator" that knows how to do everything that has anything to do with authentication, which can be passed the un/pw. "theUser" might have some kind of state ("isAuthenticated"), but even there you might ask the Authenticator (or some other authentication-related state checker) rather than coupling notions of authentication with theUser itself. [EMAIL PROTECTED] wrote: > Why do you need a method to a login screen? Wouldn’t a login screen be > more of a display compared to a logic object? > > > > You need to think about the objects involved, rather than the processes. > > > > You have a user… What does that user want to do? Authenticate, or Login. > > > > Object = theUser > > Method = public Authenticate(Login, Password) as Bool > > > > This way, you can “ask” the user if they are logged in when you need to > check the authentication of a certain page. This user object can also > hold their name, email, access keys, if they are authenticated, their > login, etc.. > > > > So, I would have the following in the page that the login form posts to : > > > > *If (theUser.Authenticate(form.login, form.password))* > > *{* > > * // login is good, do what we need to do here* > > *}* > > *Else* > > *{* > > * // login is bad. Tell the user and re-ask for username / password here* > > *}* > > > > Hope this helps, at least a little bit. > > > > -Nick > > > > > > ------------------------------------------------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Stephen Adams > *Sent:* Tuesday, July 12, 2005 10:44 AM > *To:* [email protected] > *Subject:* [CFCDev] OOP and creating a login section > > > > Hi everyone, > > When I'm trying to move to a more OOP style of building CF applications, > I always find that when it comes to building sections like a login > section or a message recording form, I can't relate OO to it. When I > read examples in both Java and CF they are always cars, people or > animals. I find it hard to turn the idea of having properties and > methods to a login screen. Then I find I fall back into procedural > programming. > > How do those who do use OOP create login screens or forms? > > Stephen > ---------------------------------------------------------- > 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). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
