Appointed Nando the possibly-official Transfer ambassador of goodwill :oD Mark
On Thu, Mar 27, 2008 at 12:01 PM, Nando <[EMAIL PROTECTED]> wrote: > I'm not sure who has sample apps, but the first places i'd look would be > http://corfield.org and at Brian Kotek's site. Transfer has a google groups > mailing list. You might also try to work up a simple sample site using > ModelGlue. There used to be a great resource called Quick Start that walks > you through it. > > Full-on object orientation solves problems you most likely don't have. You > can dig into the pattern literature and eventually find that out for > yourself like I did, and then just settle into using the OO frameworks, or > simply use the frameworks from the very beginning. Transfer basically > creates your business objects, DAOs and provides basic gateway services for > you - saving you from writing a lot of code. If you want, write those > objects once with a single simple table to get it out of your system and > then use Transfer from then on. > > Coldspring creates object instances for you, particularly the persistent > ones in application scope, and wires them together. You can try and do that > on your own to get it out of your system, create a Factory whose job it is > to CreateObjects ... then sit down and try and work out how to get PersonDAO > into Person ... no, let's see ... ummm PersonService should have an instance > of PersonDAO ... no ... ummm, maybe the Factory has instances of all > services and creates them on application start ... wait, how should I do > this. Should I pass an instance of the Factory into each of the services so > it can create a DAO in them? or should the Factory create the DAO and pass > it into PersonService when it creates PersonService ... what's better? I > don't know! > > Think about that in circle for about 2 or 3 hours. Or if you want, start > asking everybody on the lists how to do it "properly" so you get a variety > of viewpoints ... and then drop it and just use ColdSpring and Transfer, > cuz that's where you'll most likely wind up anyway if you spend 6 - 8 months > trying to really get OO and develop your own architecture. > > I think it's important to have a simple overview so you understand the > basics of objects and functions and composition (one object functioning > inside another) and the rest of the basics like encapsulation, etc - but I > would focus on the frameworks if your goal is to be productive, particularly > Transfer. > > ;-) Nando > > > > > On Wed, Mar 26, 2008 at 11:11 PM, Stephen Judd <[EMAIL PROTECTED]> > wrote: > > Alan: I like the sound of your approach. Right now, I created manager > cfcs (service) in the application scope for the calendar and event objects, > and also have gateways, daos, and beans. I think I'll need to tackle > Coldspring, as I can see things getting messy with dependencies, and I > assume my service cfcs shouldn't be calling another service in the > application scope, especially if this may end up Flexified someday. > > > > Nando: I've been using Fusebox for some time, this is my first attempt at > a fully OO version. Do you have any good pointers for integrating > Coldspring and Fusebox....I've found some info, but no good sample apps or > tutorials? > > > > All: Thanks for the words of advice. I started out with Fusebox quite a > while ago, so figured I'd use it in an OO way so there'd be one less thing > to learn (though I did consider MG and Mach-ii). I'm trying to do this > first one without ORM or code generators, so I have a better feel for what's > going on. I think I'll have to pick up Coldspring, though. > > > > Steve > > > > > > > > > > > > On Wed, Mar 26, 2008 at 5:48 PM, Adam Haskell <[EMAIL PROTECTED]> wrote: > > > > > Wise words Nando. Just this morning I was contemplating "porting" Head > First OOA&D to ColdFusion. By porting I mean taking examples and exercises > and putting them into CF and augmenting chapters and explanations to fit > ColdFusion better. I thought it would be interesting to see what came out. > I have a theory that I would have a hard time get some OO design concepts > across accurately and other parts I would completely remove. > > > > > > I think learning basic OO Analysis concepts prior to picking up an OO > centric framework is helpful though. I'm not saying take the deep dive but > maybe get the basics down before diving into the framework. Certainly in > light of the initial question in this thread I think a framework would be > helpful. > > > > > > Adam Haskell > > > > > > > > > > > > > > > On Wed, Mar 26, 2008 at 4:44 PM, Nando <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Transfer makes it very easy to write OO applications. The time you > spend learning it is very well invested in my opinion. > > > > > > > > It's also important to realize from the very beginning if you have no > OO experience that ColdFusion is a unique environment because it is loosely > typed and because of the stateless nature of HTML based web applications. > Most books you will read on OO simply don't apply very well to ColdFusion at > all - and that's a significant part of the confusion right there. I'm not > sure if this is a correct statement, but if I had to do it again, I would > focus on learning Coldspring, Transfer and ModelGlue or Fusebox or Mach II. > I wouldn't make "learning OO" primary, but leave it secondary as you gain > experience, following a few sample applications. I think you'll progress a > lot faster that way. > > > > > > > > > > > > > > > > On Wed, Mar 26, 2008 at 6:43 PM, Adam Haskell <[EMAIL PROTECTED]> > wrote: > > > > > > > > > I don't think I can give you an answer that is right you have to > make that decision. What I do with my developers working on these types of > design decisions is give them some questions to ask themselves in hope that > it will get them to an answer. At the end of the day, especially when you > start, you will regret your decision for one reason or another so you want > to mitigate as much risk of making the worst decision by asking some > questions... Remember you must answer these I am not saying yes or no to any > of them. > > > > > > > > > > > > > > > >Have the event object just query the database and populate the > array itself. > > > > > > > > > > Is your event object becoming too smart at this point? Should it > know where calendars live? Where does the rest of your persistence > interaction live? How will you write a test case to test your object's > behavior without relying on a database? > > > > > > > > > > > > > > > >Have the event object ask the calendarManager for the array. > > > > > > > > > > How will this impact your coupling? Is this impact acceptable? Is > there an alternative to this approach that could impact it differently? How > will you write a test case to test your object's behavior without relying on > a database? > > > > > > > > > > > > > > > >Pass the array into the constructor when creating the event object. > > > > > > > > > > How big is this array? Will all of these objects be used or will the > creation be wasted? Are there alternative constructors? Can my object exist > and work without this array? How will you write a test case to test your > object without relying on a database? > > > > > > > > > > The only one I have a clear direction for is the last question "Can > my object exist and work without this array?" If the answer to that is no > then I would strongly recommend going this direction. From the sounds of it > that is not the case. Note I have a repeat question in all of them, "How > will you write a test case to test your object's behavior without relying on > a database?" Part of the benefit of TDD, objects that are hard to test tend > to be objects that violate design principles. Easy testing objects tend to > be good citizens. > > > > > > > > > > Does anyone else have any good architecture questions Steve can ask > himself to help him make the decision? > > > > > > > > > > Adam Haskell > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 26, 2008 at 10:58 AM, Stephen Judd > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I'm taking my first plunge into a fully OO application and have > what I think is a simple question, though I haven't found the answer through > searching: > > > > > > > > > > > > I'm developing an events calendar. An event can be on more than > one calendar, so when I display an individual event, I want to also display > which calendars it's on. > > > > > > > > > > > > So, when I construct my event object (I know, confusing name) > what's the best way to grab an array of the calendars it occurs on? I'm > thinking the array could be a property of the event, but I'm not sure that > my event should be asking the calendarManager for the array directly. > > > > > > > > > > > > Options I've contemplated: > > > > > > > > > > > > Have the event object just query the database and populate the > array itself. > > > > > > > > > > > > Have the event object ask the calendarManager for the array. > > > > > > > > > > > > Pass the array into the constructor when creating the event > object. > > > > > > > > > > > > > > > > > > Any thoughts? is this where I need to start using and learning > ColdSpring? > > > > > > > > > > > > Thanks, Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Nando M. Breiter > > > > The CarbonZero Project > > > > CP 234 > > > > 6934 Bioggio > > > > Switzerland > > > > +41 76 303 4477 > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > [EMAIL PROTECTED] > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
