Re: [CFCDEV] Tom Minderson and anti-OO
I like OO. I don't do full OO models in CF much. Java (where I spend the most time outside of CF) is a different story - and one where I have tools such as Hibernate ;). I really just wanted to comment on this statement: In addition, with the business objects we deal with, it seems unnatural for them to have behaviors, unlike a car being able to start(). We don't have cars, but we do have documents (which might publish()), user credentials (which might expire()), trouble tickets (which might close()), etc. Building a truly OO object model is incredibly difficult, because it necessitates a sharp departure from the procedural mindset that we are all forced to deal with on the web. And when I say incredibly difficult, I don't mean just for beginners, I mean for everyone. It gets easier as you practice (like anything else), but I don't think it ever gets easy. cheers, barneyb On 8/29/07, Justin Treher [EMAIL PROTECTED] wrote: I was browsing around some old OO ColdFusion posts and saw a lot of talk by Tom MInderson. It seems like he has about 50 posts spread out (by doing a quick Google search). They all pretty much say the same thing: OO complicates things for datacentric applications that ColdFusion is targeting. I.e. we don't control cars or automatic garage doors. Then he goes on about this Set Theory. The only thing I could find on set theory with Coldfusion was at http://cfdj.sys-con.com/read/41826_p.htm … the most complex ColdFusion article ever. Is anyone familiar with his anti-web app OOP mission? Do his arguments have any validity? What the heck is set theory programming? I felt like I was stepping back into philosophy 101 with syllogisms. I do see his point that trying to map objects to a relational database is where OOP starts to feel really unnatural. In addition, with the business objects we deal with, it seems unnatural for them to have behaviors, unlike a car being able to start(). Justin You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Sorting Objects
The typical way of doing this is via a comparison function and a generic sort routine. So you provide a function that compares two objects and returns their order. The order is often returned as in integer with -1 meaning the first is lesser, 0 meaning they are equal, and +1 meaning the second is lesser. Then you have some generic sort routine that accepts a collection of objects and your comparison function. That routine does it's sort using your function for all comparison operations. I'm not sure where such a generic sort routine exists (at least in CF), but that's the general idea. cheers, barneyb On 8/20/07, Justin Treher [EMAIL PROTECTED] wrote: I'm doing the OOP thing with the help of many tutorials from all over. I've run into a stump. I'm returning arrays of objects and using those arrays to populate tables and forms. My object is composed of another subject (member class has a membershipType class). I'm trying to figure out how to sort my array of objects by any of the instance properties (using the getters). Since I'm using a composed object, sorting directly from the database is out of the question. I'm guessing it will go something like this: unsortedArray = application.memberService.getMembers() sortedArray = arrayNew(1) //loop through unsorted array Loop from=1 to=arrayLen(unsortedArray) index=x //nested loop through sorted array Loop from=1 to=arrayLen(sortedArray) length index xx //compare strings, if true i.e. string 1 (sorted) is greater (further up the alphabet), insert at current If (stringcompare(sortedarray[xx].getFirstName(),unsortedArray[x].getFirstName( )) arrayInsertAt(sortedArray,xx,unsortedArray[x]) That's the basic of what I'm trying to accomplish, but I'm sure there must be a CFC out there for this type of sorting. I'd also like to have multiple column sorts like the order bys from the database. Thanks! -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Rails-Style Migrations (for fun and profit?)
Have you looked at my schema management tool. It's not quite the same idea, but reasonably close. Definitely covers the make sure the database schemas are in sync job. I just released an update not 10 minutes ago at http://www.barneyb.com/barneyblog/2007/07/13/schema-tool-update/. cheers, barneyb On 7/13/07, Eric O'Connell [EMAIL PROTECTED] wrote: Hi folks, I started to get anxious about keeping my developer and production database schemas in sync, so I decided to implement a rails-style migration functionality. I'd already implemented about 90% of it when I came across cf_rails, but I thought I'd show it off anyway. Like cf_rails, it is currently mssql-only, but a connection adaptor layer could be added fairly easily. Anyway, here's what the migration syntax looks like: cf_create_table tableName=foo force=true cf_column name=bar type=varchar cf_column name=baaz type=integer /cf_create_table cf_add_column tableName=foo name=quux type=datetime cf_remove_column tableName=foo name=baaz cf_drop_table tableName=foo And here is an actual migration script: cfcomponent extends=com.iba.migration.instance output=yes cffunction name=up returnType=void output=no access=remote cf_add_column tableName=cart name=discountCode type=varchar(30) /cffunction cffunction name=down returnType=void output=no access=remote cf_remove_column tableName=cart name=discountCode /cffunction /cfcomponent If anyone is interested in it, I could clean it up and release it. If not, oh well :) Eric O'Connell IBA Webmaster - 941-921-7443 x15 [EMAIL PROTECTED] www.bodytalksystem.com You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Is there a point to staying here?
If you're willing to drop the solar clock and go to a 6-day week, you could increase the length of each day by 3.4 hours. Might make interfacing with other humans a bit more difficult since daytime wouldn't necessarily line up anymore though. ;) cheers, barneyb On 5/24/07, Mark Drew [EMAIL PROTECTED] wrote: Hehe, All I would need at the moment is MORE TIME! I need another 4 hours in the day MD -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Is there a point to staying here?
CF8 has them, thank god. Not much to debate anymore. ;) On 5/21/07, Barry Beattie [EMAIL PROTECTED] wrote: anyone wanna start a debate about CF and interfaces? that'll fill up the chat logs... -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Is there a point to staying here?
They're the solution to the same thing they're the solution for in every other language; they allow sharing of a type hierarchy without an inheritance hierarchy. Mostly useful in API/framework code where you're building something for other developers to hook into, but there is some of that code in every application of decent size. Does the average developer that dabbles in CFCs really need them? Nope, and they can completely ignore their existence without downside. Do people that prefer the dynamic typing that CF half-uses need them? Nope, and they probably don't use explicit typing anywhere except the 'extends' attribute to CFCOMPONENT anyway. Do people that prefer the strong typing that CF half-uses need them? Absolutely. Here's a specific example. I was working on an application a couple years ago with a fairly shallow (three, maybe four levels) inheritance hierarchy. Requirements changed, and I needed to interface several classes from that hierarchy with a separate module in a separate app. The right solution would have been to subclasses those special classes and implement the interface to make them work with the other module. Instead, I got to import some of the client app into the main app and then create a combined inheritance hierarchy (adding a couple new levels to a whole pile of classes that didn't need them, plus the few that did), and basically bind the two separate chunks of code together in a really ugly way. That's why interfaces are awesome. It's worth mentioning that this fits the API for other developers to plug into model I mentioned above. I happened to be both developers in this case, but that's just a coincidence. cheers, barneyb On 5/21/07, Barry Beattie [EMAIL PROTECTED] wrote: why thank god? what pain have you come across where they're a practical solution? On 5/22/07, Barney Boisvert [EMAIL PROTECTED] wrote: CF8 has them, thank god. Not much to debate anymore. ;) On 5/21/07, Barry Beattie [EMAIL PROTECTED] wrote: anyone wanna start a debate about CF and interfaces? that'll fill up the chat logs... -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Is there a point to staying here?
On 5/22/07, Sean Corfield [EMAIL PROTECTED] wrote: On 5/21/07, Barney Boisvert [EMAIL PROTECTED] wrote: They're the solution to the same thing they're the solution for in every other language; No, no, no, no, no! Interfaces do not exist in most languages because - shock, horror - they are NOT NEEDED! I should have been clearer in my initial statement; there was an implicit 'static' at the end, between 'other' and 'langauge'. They are not needed in a dynamically typed language. But unless you have multiple inheritance (which I think everyone agrees is horrible), statically typed languages really do need interfaces. CF is not a strongly typed language, but it's not a loosely typed language either, it's some sort of hybrid. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] Is there a point to staying here?
On 5/22/07, Sean Corfield [EMAIL PROTECTED] wrote: On 5/22/07, Barney Boisvert [EMAIL PROTECTED] wrote: They are not needed in a dynamically typed language. But unless you have multiple inheritance (which I think everyone agrees is horrible), Hmm... well... actually, as one of the designers of C++ I don't think multiple inheritance is horrible but I do think it can be overused (well, any inheritance can be overused). I think Java has gone through contortions of its own to avoid multiple inheritance. Some problems are just easier to solve with multiple inheritance. I can't discount any of that. I've definitely run into situations where MI would have been nice, but I think not being able to go that way forces a bit more forethought into design, which is a good thing. Insert give yourself plenty of rope to hang yourself adage here CF is not a strongly typed language, but it's not a loosely typed language either, it's some sort of hybrid. I've seen this put forward in a couple of places recently and I'm not sure I buy it. The only type-checking in ColdFusion is on arguments and return types and that is done at runtime. The only ANYTHING ColdFusion does is done at runtime. Granted, runtime has a compile phase to it and execution-time checks only check execution paths, not potential execution paths as compile-time checks would. However, from the perspective of the developer, runtime is pretty much runtime. It'd be great to get exceptions during the compilation phase, but getting them during execution is still helpful. As gets pointed out every time this conversation arises, you don't need static typechecking to make a langauge useful. But I happen to like having it, and generally prefer static languages to dynamic ones. As such, I'm happy to see CFINTERFACE, as it provides some additional functionality in CFML that would otherwise be really hard to synthesize without throwing away all the typechecking. I'd expect CFINTERFACE to remain a runtime concept to allow mixins with CFINCLUDE in the psuedoconstructor, but I'm not on the Beta so I can't say if that's the case. If it were a compile-time check, I'd like it even more (in my selfishness), but I think that would have been a horrible design decision for the language as a whole. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] ACEGI Integration
I used it for a Java project last year, but never with ColdFusion. For simple simpler security schemes it's awesome, but it's pretty heavily tied to JEE's structure for web security. I thought it rather lacking for good ACL support, but we were only using the first ACL implementation. The new implementation was in a sandbox and not part of the official releases at the time. Not sure if that's changed. cheers, barneyb On 3/19/07, Adam Haskell [EMAIL PROTECTED] wrote: We're considering adopting ACEGI as out enterprise security standard. I was curious if anyone has had any experience with it in general and more specifically experience trying to integrate with ColdFusion at any level. Adam You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] ROI (was CFC best practice)
Quantifying ROI for learning some new technology is really hard. There's an intrinsic benefit to picking up new stuff, even if you never use it in real life, just because it makes you a better developer. As you'd expect, there's a period of lost productivity for picking up something new, so if you're stuck in a short project mentality, it's never going to make sense to learn anything new. Each time you learn something new, the project you're working on (and probably the next one) will take longer. But in the long view, I think it's pretty clear that picking up new things will be a time saver. I can say with utter certainty that CFC-based applications, Fusebox, and ColdSpring make me a more productive developer. Not having them available (or not knowing how to use them) would probably cost me 8-10 hours a week. So if learning how to use them effectively were to take me 2 months (which is probably not unreasonable), it'd make sense to learn if I were to intend to program CF for at least two thirds of a year (2 months * 20 work days * 8 hours / (10 hours / week) = 32 weeks to catch up). Which I certainly planned to. So it was a no-brainer to learn how to use them effectively. I didn't learn them all at once, of course, but over a period of time, and continue to do so. Like any investment, you have to keep contributing if you want it to keep serving you. cheers, barneyb On 2/19/07, Phillip Senn [EMAIL PROTECTED] wrote: Will I see a savings of time by the time I am done? That's been the unspoken question for so many people. I wonder what the group has to say about that. It used to be (back in the 80's) that you could cost justify an expense if you could show a 3 year Return On Investment (ROI). In other words, if a new piece of equipment paid for itself within 3 years, you could more than likely get it approved. Taking that analogy into the time-save category, and recognizing that we are now working on Internet time, Q: What do you think should be a good ROI should be for spending your time on a new technology? This might be helpful in making the millions of little decisions that I've been making all along. If I create this shortcut, will it save the amount of time that it took me to create it over the span of the next x years/months/weeks? If I put business logic in CFCs… If I learn this framework… -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDEV] fundamental question about Fusebox
the fbx_switch files makes it a bit of a challenge to appreciate what Fusebox does (and why). I really miss having the controllers I'm used to and sometimes it feels like FB is getting in the way or making things more complicated than it needs to be. that and being annoyed by the lack of abstraction like variables, queries, etc, created in one cfinclude but referred to in another within the same switch. it just seems to make it harder to get a good (quick) top-level grasp of each business process. it may just be this old version or how it's used, but FB feels like it's suited to easily build only one type of app - common head/footers, common nav, menues, etc, but with changing guts. The use of Remoting, Ajax calls and self-posting forms are do-able but not quite as straight-foward to what I'm used to. is this a fair summary or have I got a dog of an example to be underwhelmed by? Sure this is FB3 and FB5.1 is now out there, but as far as the core features of cascading fbx_switch and fbx_settings files, what pain do these actually solve? any advice, opinons most welcome thanx You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
Re: [CFCDev] Service Layer?
I always think of things like this: - gateways are encapsulated SELECT statements, typically that return queries, but sometimes return simple types (like a SELECT COUNT(*) query). - services are encapsulated behaviour that accept simple data (or transfer objects) and do something with them (create an entity; load, update, and save an entity; invoke some business logic; etc.). - domain objects (entities, workflows, etc.) are where business logic resides, and should be entirely hidden behind your services. Note that the service layer isn't necessarily where your business logic should reside. In fact, you generally want it to reside elsewhere. The services are really little more than adapters that turn raw data (i.e. form fields) into a message to pass to your business logic (a bean and DAO, for example). Almost all complex processing should exist as part of your domain model, and your services just provide a way for the UI to interact with the model through a simple API. cheers, barneyb On 6/28/06, Jeff D. Chastain [EMAIL PROTECTED] wrote: I am working on a simple contact manager type application using MG Unity and some other things I wanted to play with. I have built all of my low level data objects (bean, dao, gateway) for a Contact, which has one or more Addresses, which then has a State and a Country. Where I am getting stuck is on the service layer. In once case, I am looking to create functionality where an entire contact could be updated at once by passing in a struct (i.e. the form scope). So in my mind this means a ContactService with a method to update the contact and that method then utilizes the different contact, address, state, and country beans and daos. Another requirement though is to obtain a list of the 5 most recently updated contacts. Is this something that would go in the same ContactService or where would this go? I have never had a good grasp on what should go where in terms of a service layer, so I am looking for any input on how service layers are really built and organized. Thanks -- Jeff -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Odd datatype error
On CF, that should work just dandy, but not if you're using BlueDragon. Are you, by chance? If so, you'll need to switch ALL references to the fully-qualified name. cheers, barneyb On 4/7/06, Cameron Childress [EMAIL PROTECTED] wrote: I'm just checking my sanity here These two calls should create an object with the same datatype right? cffunction name=init returntype=myObject cfreturn this/ /cffunction cffunction name=init returntype=full.path.to.myObject cfreturn this/ /cffunction And when this object is used in a cfargument tag with strict typing, it both should pass the following type validation rule right? cfargument name=myObject type=full.path.to.myObject/ We are getting an odd datatype mismatch error and I've thoroughly confused myself trying to comprehend it. -Cameron -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Odd datatype error
I mix both styles all the time on 6.1. You have a typo somewhere maybe? On the package part of the FQCN in the method you want to pass the instance into? On 4/7/06, Cameron Childress [EMAIL PROTECTED] wrote: Nope - CFMX 6.1 actually, which may be part of the cuse as well. Anyone remember changes 'tween 6.1 and 7 that would have fixed a problem like this? Some bug in 6.1 that could cause this to break? -Cameron -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Odd datatype error
We had CF 6.1 start behaving strangely a month ago, and eventually traced it back to some totally unrelated exception with client variable in a different application that was causing NPE's in CF's exception handlers. Really weird, and the only way we found it was looking in the JRun logs (we run CF standalone, not J2EE). The problems weren't with the types of CFCs, but they were definitely totally random. cheers, barneyb On 4/7/06, Cameron Childress [EMAIL PROTECTED] wrote: The odd thing is that this code's been running like this with mixed style for months and just now started to error on one of two servers (yes, one and only one). Totally random (seemingly) and totally frustrating! Anyone else have input before I deepen the bruise on my forehead? -Cameron -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Expense of Operations?
A method call is more expensive than a variable reference, but the encapsulation the method provides is worth it in almost all scenarios. It's very unlikely that this would grow to a bottleneck since the more such operations you have, the more other stuff you're doing in the request (most likely). Only careful load testing will indicate if there's a problem, but I'd say you're safe to assume there won't be. A few request scoped objects is all you'll need in most cases. Most of your objects (including all those you listed in your email) should be instantiated into the application and/or session scopes for peristance across requests. That'll speed things up because of massively reduced instantiation overhead, and let you do stuff like caching. The number of lines of code in an object will affect instantiation of the CFC's FIRST instance (when it's read from disk), but not after that. The number of methods will affect instantiation of all instances (but exceedingly little). Again, until careful load testing has illustrated an explicit issue, don't even consider it to be a potential issue. The first and last items are saving you a couple ms tops, per request, but the middle item could well be saving you hundreds of ms per request. cheers, barneyb On 1/20/06, Peter Bell [EMAIL PROTECTED] wrote: Hello All, Does anyone have any kind of information on the relative expense (processing wise) of different operations? For example, assuming a user object has been instantiated, how much more processing does it take to getUserFirstName() (assuming it is just a return THIS.FirstName) versus just using dot notation against the THIS scoped variable for the object? If you have a few hundred such operations as page of processing a page request, would the choice have any substantive affect on application performance? I know there are guides on CF best practices for performance (avoid evaluate, use list compare instead of multiple string comparisons, etc.) but I can't find a good guide to the relative cost of OO operations in CF that would help to ensure a design would have a decent shot at being performant. Also, while I know it is extremely broad, in general what range of number of request scoped objects mught you instantiate in a common page request for a well architected app? I'm assuming that it would be common for a sophisticated page request to instantiate 10-50 objects between the controller, facades, domain objects, compositional objects and the DAL. Is that a fair heuristic? Finally, does the physical size of an object (the number of lines of code across all of the methods) have any substantive effect on initialization performance (does the entire object get loaded into memory or are the methods loaded into memory one at a time? For example, if you have an object with 20 methods each with 500 lines of code where any given page request may call only one or two of the methods, would you consider abstracting some of the methods into separate objects to cut down on object instantion time? I want to clarify, I'm not trying to shave page processing from 45 to 18ms, I'm just trying to make sure that pages with minimal db and file system access don't end up taking 300-400ms. Any thoughts much appreciated! Best Wishes, Peter -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Creating User Controls - cfc or tag?
I generally write my UI widgets as custom tags. Keeps things simple, since my view templates are all simple markup, be it HTML or CFML custom tags. Tags are also easy for designers to understand, since they'll already be familiar with nesting, attributes, and the like. How those custom tags work, I can't say for sure, but they usually take the form of query the model CFCs, render some HTML. Some widgets, of course, won't need the first part (like a pager for a paged record set), and some might not need the second part (I can't think of a good generic example). cheers, barneyb On 1/18/06, Peter Bell [EMAIL PROTECTED] wrote: Hello All, My introduction to OOP in CF is a rewrite of a CF5 application generator in CFMX 7. I have a pretty good domain object model but am having trouble finding best practices for the UI. All of the controller (index.cfm) and model (various cfc's with a simple façade abstracting the business objects) runs first and then the model uses rules to determine what screen template to include. For instance, if form validated, display a list and a added OK message, if it failed, re-display the form screen. It then calls the appropriate screen. The screen is currently looking like being a simple CFML template that knowledgeable graphic designers can edit and that is comprised of static HTML, support for variables and basic logic using a generic syntax (so I can generate in other languages), and a number of widgets. The widgets are produced by a code generator that generates (and can save to files at design time) common UI widgets (table with pagination, simple form, n-record update table, etc.) from a set of primitives. The generated UI widgets can then be passed certain runtime properties (object type to display, display properties for this instance, etc.) and generate the appropriate HTML which is then pulled together by the page and screen templates. I'm tempted to describe the widgets something like: Element name=PagedTable Property1=value1 . . . / for the designers. I can then use a Regex/parser to turn that into any appropriate format/include/call. How would you recommend calling the user interface widgets? I'm tempted to put them into methods of a UI CFC which returns the HTML string to display. That would also make it fairly easy to refactor to a Factory pattern to support n-output methods (optimized for different devices, etc.) but no less than Ben Forta suggests using custom tags for UI. Are there some considerations I'm missing? Be gentle on me. This is my first OOP projects and I've been thinking about this less than a week!!! Best Wishes, Peter -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CF on Wheels..
If the module is mod_rewrite (which I'd be money it is), there is an IIS equivalent. Googling for mod_rewrite IIS turned up several alternatives, none of which I'm familiar with. Of course, why not just use Apache? cheers, barneyb On 12/20/05, John Farrar [EMAIL PROTECTED] wrote: Wow… talk about getting things right. This project is a beautiful mix. That and looking at the Reactor project there isn't much reason for someone to jump over to Rails. With that said… has anyone else played with this project (CFoW) yet? I got it running on Apache but don't see any configuration files to get it running on IIS yet. Waiting for an answer from the author… but who knows. If anyone knows how to get it running in IIS then that would be great knowledge. It uses a module in Apache to do URL rewriting. It's quite a work! John Farrar -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] CF on Wheels..
I have some clients that use shared hosting... so getting them to move isn't as easy as getting them to let me build with CFoW Totally understandable. The moreso because no shared host is going to let you install ISAPI plugins. ; ) Now I want a good management interface for Apache that isn't expensive Really? I think of the config files that Apache uses as a nice feature compared that damn GUI that IIS uses. In particular, because it lets me keep the files in my Subversion repository for easy change managment, and syncing across the different servers in the cluster. It also lets you easily build generators (I create my conf files using Ant), run text processors for batch edits, and a whole lot of other really helpful things. cheers, barneyb On 12/20/05, John Farrar [EMAIL PROTECTED] wrote: I have some clients that use shared hosting... so getting them to move isn't as easy as getting them to let me build with CFoW. (I am not saying that makes sense... just the reality of the situation.) So if anyone knows of one that is good for the goose could they let the gander know also? I would like a tested one if possible. Oh... I moved our company over to apache for that reason. I agree with you Barney... it's good advice. But our intranet isn't going to resolve issues for others. (Now I want a good management interface for Apache that isn't expensive... want, want, want... isn't that the way?) John -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFIMPORT - Oh the pain
The reason inheritance doesn't work is because CFIMPORT is a compile-time directive, but each individual CF template is compiled separately. So if you compile the parent include, the CFIMPORT is processed, but when you get to compiling the child include, there isn't a CFIMPORT tag to deal with. And you can't just blindly inherit, because the child include might be included from multiple different parents. That's also the reason you have to use a hard path, not a variable. Variables don't exist until runtime. John got it pretty much right on the nose. You create a mapping (which you probably already have for your CFCs), and then use that mapping in your CFIMPORT tags. I happen to set up a mapping for each domain like /com/barneyb, which serves as my CFC root, and then /com/barneyb/tags would be my tag root. So I might have this: cfimport prefix=u taglib=/com/barneyb/tags/util / cfset myCFC = createObject(component, com.barneyb.myCFC) / cheers, barneyb On 12/19/05, Geoff Parkhurst [EMAIL PROTECTED] wrote: Suggestion... create a standard library of CF files off the site root and call it something like shared. Then put your custom tags in that directory. If that doesn't fix your issue you could use CFModule... but that should work on any sites. I create a set of tags for my apps in /share/sos and then map them with CFImport from all my apps to sos and call the apps like this... sos:skin ... /sos:skin Or public tags in /share/public public:myTag And that should solve your issues. It's not exactly how you want to do it... but it sure works. John Farrar I have some files like this: cfimport prefix=lh taglib=../extensions/customtags lh:nav h1Hello/h1 cfinclude template=blah.cfm /lh:nav In this case, if blah.cfm needs to call a custom tag, it needs its own cfimport line... So, why can't a cfincluded file inherit a taglib from its 'parent'? My guess is if blah.cfm was a CFC, having its functionality or resources being dependent on a library only made available by the invoking file would be bad... i.e. blah.cfm wouldn't be a nice self-contained module Geoff -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Finding subclasses via introspection
Nope, because an object doesn't care about subclasses. The superclasses, on the other hand, are critical, becauase they define both types and behaviour for an object. If you want some kind of dynamic awareness of subclasses, you'll have to scan the filesystem for suitable files. Keep in mind that getMetaData is for an instance, not a class. MM did a bit of a disservice to developers by using CFC to mean both a CFC class and a CFC instance, and this is a good example of why. cheers, barneyb On 12/19/05, Haikal Saadh [EMAIL PROTECTED] wrote: Hello all. Is it possible at all, with MX6.1, to find out what a components subclasses are? Finding the superclass is simple enough, using getMetaData(), but there appears to be no facility to find subclasses. What I am basically trying to do is an implementation of the Strategy pattern, and the idea is that new stragetegies can be implemented by simply dropping in addition classes that extend that particular strategy. I was hoping to use introspection so as to avoid having to manually keep track of what's available. Ideas? Thanks. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Anyone using java.net.URLClassLoader?
A class is defined by it's name and it's classloader, not just it's name. So if you want to extend something loaded by specific classloader, the extended class also has to be loaded by that same classloader or it's parent classloaders. That is, by a classloader in the same classloader tree. Since your classloader is the root of it's own classloader tree, it doesn't have access to any of the other classes that might be available in your JVM, so you can't extend those classes with classes loaded by your classloader. A URLClassLoader is really designed for loading wholly encapsulated sets of classes. That could be a collection of classes, or more likely, a JAR file. It's not designed for loading stuff into your existing JVM environment. I can't say with absolute confidence that that's 100% right, but it's generally right. Classloading (along with much of the JVM's internals) is friggin voodoo. cheers, barneyb On 12/15/05, Gareth Edwards [EMAIL PROTECTED] wrote: I'm having some troubles using this java class to load some custom java classes. I think it works find until you want to extend something in the custom class. (Not sure). Any help would be much appreciated. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern - yes this IS about Factory Pattern!
That'd be a registry, probably named DAORegistry in this case. But assuming the registry is part of a single app, I'd definitely take the time to wrap it up in a factory facade, because to the rest of the app, that's what it is. If the registry is floating outside the app (like a JNDI registry), or if you know that will be the eventuality for your app, then leaving it as a registry makes more sense. However, there's still an argument for wrapping the registry up in a factory for the sake of your application. So the 'factory' would actually be a facade/adapter in implementation. cheers, barneyb On 11/15/05, Patrick McElhaney [EMAIL PROTECTED] wrote: Creating objects and keeping track of instances are two different responsibilities. If one CFC covers both responsibilities, I don't have a problem with calling it a factory. But what do you call this? !--- First, create some DAO objects --- cfset userDAO = createObject(component, userDAO)/ cfset groupDAO = createObject(component, groupDAO)/ !--- Now, stuff them in my how the rest of the app gets the DAO objects object. --- cfset HtRotAGtDAOO= createObject(component, )/ cfset HtRotAGtDAOO.setUserDAO(userDAO)/ cfset HtRotAGtDAOO.setGroupDAO(groupDAO)/ !--- later, I use my HTRotAGtDAOO object to get the userDAO --- cfset userDAO = HtRotAGtDAOO.getUserDAO()/ Patrick -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern - yes this IS about Factory Pattern!
Surely you meant a DAOFactoryFacadeFactoryRegistry, right? You want to keep things as abstracted as possible. ;) I've oft wondered if people would be able to tell the difference between legit design pattern applications and totally spurrious extensions on the theme. Obviously the Factory Facade Factory Registry Pattern is rather a foolish one, but how do you make that distinction, ya know? Kind of an interesting problem, and one without a definite solution, but you have to make exactly that distinction many times throughout the course of designing even a single, fairly simple, application. I suppose thats why it takes a human to write code though, rather than just letting the machine do it for you. cheers, barneyb On 11/15/05, Patrick McElhaney [EMAIL PROTECTED] wrote: On 11/15/05, Barney Boisvert [EMAIL PROTECTED] wrote: That'd be a registry, probably named DAORegistry in this case. But assuming the registry is part of a single app, I'd definitely take the time to wrap it up in a factory facade, because to the rest of the app, that's what it is. Well, I would probably take your factory facade and hide it behind a DAOFactoryFacadeService. ;-) Patrick -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern - yes this IS about Factory Pattern!
Not to jump down your throat, Nando (though I know you were indirectly
referring to me about doing it ;), but I do have to disagree on some
level.
I'll certainly agree that a lot of the terminology is confusing, but
that's the case in any complex field. I surely don't consider medical
or legal terminology even remotely sane, but to the professionals in
the field, there's a need for the complex nomenclature. The same
thing goes in programming.
You say service, I say factory. Suddenly we can't communicate without
a Nandolian-Barnese dictionary, and that hurts us both. And heaven
forbid we want to talk to [fictional] John, who calls them managers.
Now we need three dictionaries.
So there's a very good reason to have a standardized nomenclature
within a community. Regarding design patterns, I think that pretty
much anyone will agree that if the GoF book speaks on the matter, it's
the authoritative source. For other topics, things are less clear,
but there is almost always an accepted lexicon.
In that vein:
An object whose sole purpose is to create other objects is a factory
object, not a service or a manager.
An object whose sole purpose is to expose discrete bits of
functionality through a formal API is a service object.
A pedantic rant, to be sure, but it's not without value, because it
facilitates easier pursuit of the non-pedantic aspects of what we do.
cheers,
barneyb
On 11/14/05, Nando [EMAIL PROTECTED] wrote:
Mike,
I enjoyed reading your posts this morning, especially the one about the
throngs of bank customers meeting in the road.
It's hard for me too. Someone will say, for instance, that a Service is X.
Then someone else will say that a Service is Y and that X is a Manager. Then
someone else will say that if you are using Managers in your model, you
don't understand OO design very well. Then Joe gets around that in
Model-Glue by calling them Controllers, and i think to myself, Gee, that
was clever! ;)
I'm going to call it a Service. Think of the guy in the truck selling hot
dogs to the throngs of bank customers crossing the road. That's a Service,
right?
Here's what i've done, in case it's of any help.
In Application.cfc/m instantiate Factory as a singleton. Then have Factory
make you instance of DaoService. When it does, pass the instance of the
factory into it, using this.
in Factory:
cffunction name=getDaoService access=public returntype=DaoService
output=no
cfset var DaoService =
createObject('component','DaoService').init(this) /
cfreturn DaoService /
/cffunction
In Application.cfc/m, or wherever actually needed.
(adjust as necessary)
cfif NOT StructKeyExists(application, DaoService) OR StructKeyExists(url,
reinit)
cfset application.DaoService =
application.Factory.getDaoService() /
/cfif
In DaoService's init method, you'll set the Factory instance you passed into
DaoService to variables scope so you've got ready access to it, and then
from within DaoService, have factory make all the Dao's you need and set
them to variables scope as well.
Then you'd access them using public getters. For example:
application.DaoService.getSomeSpecificDao().create()
application.DaoService.getSomeSpecificDao().read()
I've used this approach to instantiate Gateways into a GatewayService for
front end queries. It seems to perform very well, even on views that use
many queries to render the page.
I'm not suggesting that you specifically use an object called DaoService -
btw. It's just to demonstrate.
ciao,
Nando
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Query: Turn column into a list
Using an array rather than a list and then converting it at the end will be more efficient if you've got more than a few rows per column1 value. You should check your DB's docs too, as there might be a function that'll let you do with with SQL, rather than CF. MySQL has GROUP_CONCAT for exactly this purpose. cheers, barneyb On 11/8/05, Baz [EMAIL PROTECTED] wrote: If I have the following query: Column1 || Column2 ValueA || ValueX ValueA || ValueY ValueB || ValueX ValueB || ValueY ValueB || ValueZ And I want to turn the second column into a list, while keeping the first column unique - like so: Column1 || Column2 ValueA || ValueX, ValueY ValueB || ValueX, ValueY, ValueZ Is there a more efficient way to do this than: cfoutput query=QueryXXX group=Column1 !--- populate groups list --- cfoutput cfset ColumnToList=listappend(ColumnToList,Column2) / /cfoutput !--- add row to final query --- cfscript queryaddrow(FinalQuery); querysetcell(FinalQuery,'Column1', Column1); querysetcell(FinalQuery,'Column2', ColumnToList); /cfscript /cfoutput I'm sure there's a million ways to do this… Baz -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] Query: Turn column into a list
valueList will convert the entire column to a list, not individual lists for groups of records like Baz's code does. cheers, barneyb On 11/8/05, PCC [EMAIL PROTECTED] wrote: What about ValueList() Function Description Inserts a delimiter between each value in an executed query. ColdFusion does not evaluate the arguments. Return value A delimited list of the values of each record returned from an executed query. Syntax ValueList(query.column [, delimiter ]) See also QuotedValueList Parameters Parameter Description query.column Name of an executed query and column.Separate query name and column name with a period. delimiter A delimiter character to separatecolumn data items. http://livedocs.macromedia.com/coldfusion/6/CFML_Reference/functions-pt2115.htm -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: SPAM-LOW: Re: [CFCDev] Factory Pattern
Well, something for ORM would be useful, it's true, but I'm not holding my breath for a scalable production-quality solution in that space ;) Depends on what you mean by ORM. Things like Arf! or Reactor start to encroach on that space. Certainly not a conventional ORM solution, but they provide many of the benefits. No idea about scalability, but I suspect Reactor will be quite performant, since it does very little at runtime. I'm not sure about Arf!'s execution profile as I haven't dug into the implementation as far. cheers, barneyb On 11/5/05, Sean Corfield [EMAIL PROTECTED] wrote: On 11/3/05, Peter J. Farrell [EMAIL PROTECTED] wrote: I get the feeling that CS is not very well understood in the CF community. I think that's a bit of an understatement :) seriously suggest downloading the 13 page reference doc from the site to get an idea of what CS does and how it does it if you don't know about inversion of control or dependency injection. Yes, the documentation is excellent! I was a bit of a naysayer at first. Dave approached me about ColdSpring a long time ago and I didn't really take it seriously - I couldn't see the benefit. Then I hit a wall with a Mach II app at work and rewrote it to use Model-Glue and the ChiliBeans factory (supplied with Model-Glue). ChiliBeans was really my first hands on experience with inversion of control and it made the app much, much more maintainable. At that point, I took ColdSpring for a test drive and it all made sense! With Mach-II + Coldspring - application development is starting to become more of a silver bullet. Not sure I'd go that far - there are no silver bullets - but certainly an MVC framework (Fusebox, Mach II, Model-Glue) + an IoC/AOP container (ColdSpring) really does lift up your development to make you more effective at producing more maintainable applications. AOP is another poorly understood concept. Hopefully, ColdSpring (and Dave and Chris) will popularize that to some degree. Just add in CFHibernate if it comes out and you would great frameworks to do things easily Well, something for ORM would be useful, it's true, but I'm not holding my breath for a scalable production-quality solution in that space ;) -- Sean A Corfield -- http://corfield.org/ Got frameworks? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern
If you drop your packages in the web root, you can reference them without mappings. To put it another way the web root is implictly mapped to /. I can't think of a framework that forces you to use mappings, though there are advantages to doing it that way. For example, you can avoid duplicating framework code for each utilizing application, which makes bug fixes in the framework enormously easier to apply. It also ensures that you're never running mixed versions (because there's only one copy). There are other reasons as well. It's your call as to which is more appropriate. cheers, barneyb On 11/5/05, Nando [EMAIL PROTECTED] wrote: That sounds like an argument against using any standard framework? Not at all! Everything we've done is in Feuuu Feuuu ... Feuuu ... . http://helmsandpeters.com/audiofiles/HaP-FrameworkShrink.mp3 And i'd prefer to move it to model-glue ... just to clean it all up nicely. I use frameworks on a shared host without mappings. How? Please explain ... What we need is a simple, self-contained architecture that can scale out easily to say 10 - 20, maybe 30 installations a week and take no more than 10 or 15 minutes per installation. And i'd like that it can be InstalledAnywhere in the same amount of time. And each installation needs to stand on it's own. I'd be very happy to move it to MG ... but that would, i think, practically limit us to only offering this as a We'll host it for you package. We'll be making maybe $20 dollars a month on each installation. I'd like to sell 5000 of them or so and retire to a beach somewhere on a $80,000 a month income, and pay someone $20,000 a month to maintain it. All the customization requests would be extra. :) n. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern
You've created a situation where introducing an object that's not initialized the same way is painful. So instead of doing the right thing, you may be tempted to force your object to intialize the same as all the others. Otherwise, you have to introduce a -- *gulp* -- special case. I'd disagree. I've created a situation where it's sometimes easier to introduce a new object. I gotta write a getXXX() method anyway, just sometimes I get to skip it. Also, aren't you a fan of strong typing? What do you make the returntype of a method that returns lots of different types? Yes I am, and an abstract superclass meets this need very well. An interface would be better for certain things, but in general it works well enough with out it. cffunction name=createBarGateway cfreturn createGateway(bar, variables.dsn)/ /cffunction Only this way you don't need a switch statement. Yeah, I suppose that'd work just as well. Interesting how there's always to multiple to skin a cat (I prefer head to tail). What's going on here? We drag someone through the mud for advocating get(fieldname) and set(fieldname, value). Then Hal does the same thing with his isNull(fieldName) method. Now you and Nando are getting into the game. I thought I was perfectly clear in stating that the design goes against convetional wisdom. You illustrated above a better way to go about it. I'm not against it for the 'lots of public methods', or whatever other reason, I just happen to like gatewayFactory.getInstance(user) rather than gatewayFactory.getUserGateway(). And I certainly wouldn't go blindly applying the same design to other scenarios. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern
Hey, no worries. Email sucks for having charged discussions, because anything short of careful politi-speak invariably comes off with you're an a**hole inflection. But until people can mind-meld over long distances and record the interplay for others to sample later, I think we're stuck. ; ) You made a very good point that it's NOT a good way to go, and most importantly (at least in my view), backed it up with a better alternative and why it's better. Convinced me. Now if only I didn't have thousands and thousands of lines of code that work my way, and no ability to refactor cheers, barneyb On 11/3/05, Patrick McElhaney [EMAIL PROTECTED] wrote: Barney, I apologize. My email was worded too strongly -- especially the tangent part. Patrick -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern
Enforcing that rule solves the problem of not knowing which arguments to pass at create time but introduces the new problem of having to remember to call certain sets right after creating – a strange dependency. No, it doesn't, actually. The code that wants an instance of whatever object knows what it's doing, so it's going to do it. Either the set methods you refer to are tied to the specific task the calling code is doing, or they're not. If the former, they can't happen anywher except the calling code (and the calling code better remember to do them, or it's not going to be doing what it's supposed to). If it's the latter, then they should be set in the factory (by init(), most likely), because they'll be the same for all instances, no matter how they're going to be used. This could cause even more problems because how am I even supposed to know which sets are mandatory right after create and which are just regular sets that can be performed anytime. If they're mandatory for an instance to exist, then either the factory should be in charge of setting them, or the object needs to be built in such a way that it fails fast if the property isn't set. i.e. the propery defaults to an unset state that can be tested against, and it explictly throws an error if it's not set. In all the code I've written, I can't think of an example where I've needed to do this. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] Factory Pattern
I'll typically have a service factory that is used by the UI (or UI's), and then where I'm using entity objects, I'll have a factory per entity type. Of course, I don't actually build dedicated factory objects, I build managers, which include the getNewUser method, but also have various other methods for managing user entities. You could certainly call those objects factories, but I prefer manager to differentiate them from objects that ONLY act as factories. So both yes and no. ;) You'll find that you get that answer a lot in the OO design world, because there's so rarely a single correct answer for anything. cheers, barneyb On 11/1/05, Scratch [EMAIL PROTECTED] wrote: Sorry for the triple-post... u guys gave a lot of material! Barney, in your example you have a UserFactory class - was that just an example or do you normally build such granular Factories? How many factories do your apps usually have? Cheers, Baz -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factory Pattern
I happen to like that style (though I use getInstance), even though it goes against one of the common tenets of OO: never pass in behaviour-dicating method arguments, make separate methods instead. Like Scratch/Baz suggested, getInstance will delegate to class-specific factory methods where appropriate, but some classes of object (gateways come to mind) are frequently initialized in the same way (pass in the DSN to use). With a single getInstance, I can have a 'default' initialization routine, and specialize it where needed, saving some code. It's also a structure that'll work no matter whether you can make that code reduction or not, and consistency, consistency, consistency. So I completely agree with you, Nando, even though it goes against best practices. A good example of one of those places where it's a good choice to blatantly go against conventional wisdom. And sorry for the three-in-a-row posts. I was without internet all day, and while I don't like the jump in after the topic dwindles, I wanted to specifically address these three points, cheers, barneyb On 11/2/05, Nando [EMAIL PROTECTED] wrote: What's with the load() method? Well, load() gives you one public interface to code to. The implementation details within Factory can change without affecting the rest of your app. Do you see a drawback to that? Maybe there is one ... my working hypothesis at the moment is that it would be better in the long run to stay with a single interface and work out any drawbacks in another way. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Message Handling
Yeah, it creates and returns an ErrorSet object. Validate creates an
ErrorSet, populates it as needed, and then stores it in the object's
instance state for later recall with getValidationErrors. It also
returns it, since that's usually what the calling code wants. Each
time validate is called and any of the instance data has changed, it
creates a new set and populates it. Obviously if no state has
changed, there's no need to do the whole validation routine (with a
new notable exceptions, such as uniqueness checks).
function validate() {
var errorSet = new ErrorSet();
// check field X
// check field Y
variables.errorSet = errorSet;
return errorSet;
}
cheers,
barneyb
On 10/30/05, Scratch [EMAIL PROTECTED] wrote:
Hey Barney,
In your example does Customer.Validate() return an object? If so, was that
object created inside the Validate() method?
Baz
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Message Handling
In that scenario, you'd say 9 ErrorSet instantiations, but you'd sacrifice the encapsulation of the object. In my setup, every object knows whether it's valid or not, and it uses the ErrorSet object to do it. No object means the state isn't known, and needs to be checked, a zero-element object means there are no errors (that is, it's valid), and a one-plus-element object indicates there are errors that must be resolved. By passing in your ErrorSet object, you force the object to keep track of that in a different way, and probably force it to dynamically compute the ErrorSet's contents every time it's needed, rather than only recomputing when a value changes. Passing a single ErrorSet will be faster, but probably not measurably faster, and to me, it's not worth the ramifications. At least not until it's been proven an issue with load testing and profiling. And even then, theres probably better ways to save that millisecond or two. cheers, barneyb On 10/30/05, Scratch [EMAIL PROTECTED] wrote: Thanks Barney, you have been most helpful. A great majority of your CFCs must be using the ErrorSet object. And lets say in one request you needed to validate 10 different CFCs, each one would create an Errorset object. If instead you created one main ErrorSet object in your controller and then passed into each CFC, do you there would be a significant performance improvement? Is that bad style? Cheers, Baz -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Global Function Libraries
The 'utils' CFC instance is a property of the CFC, accesible via getUtils(). The UDFs aren't copied into the variables scope directly. To take things the next step up, in an app you often have peer CFCs that need to know about each other, as well as standalone library-type CFCs that all the others need to know about. If all the CFC instances are created by a factory, then you can just pass that factory around and each CFC can get what it needs when it needs it, rather than passing around individual instance (like the utils object). I.e. factory.cfc has getUtils, getUserService, getNotificationService, etc. Each of those CFCs has an init() method that takes a reference to the factory that saves it to a variable, and then within it you can say variables.factory.getUtils().myUDF(), or variables.factory.getNotificationService().sendUserNotification(...). Bump that up one more level, and your factory object becomes a single element in your larger application configuration object. So your CFCs receive a 'config' object, with things like DSN, mail server, your object factory, and whatever else. So now you have a single thing that you can pass to all your application objects, and it has everything any of them need. cheers, barneyb On 10/30/05, Scratch [EMAIL PROTECTED] wrote: Hey Ryan, Why the additional getUtils() function rather than just referring to the functions as variables.myUDF()? That method wouldn't be used outside the CFC would it? Baz Suggestions so far: 1. Pass the function library to each CFC that needs it. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Message Handling
Just getValidationErrors(), which creates the error set if needed (caching it, of course), and returns it. isValid would be implemented as getValidationErrors().size() EQ 0, and that's just as easily to put in the calling code, since you'll need the error set to display the errors, and it might be a compound error set as we've discussed. It's a slight over-coupling of the calling code to the object, but one I'm comfortable with. I don't have a hasModified either, because it's irrelevant to external users if an object has been modified. What's relevant is if the calling code *thinks* the object has been modified. I.e. calling a setter doesn't necessarily change something (i.e. set a field to it's same value). The setters null out the validation set when called, of course, and the object maintains an internal list of properties that have changed. Then when a save/update is requested, the object can tell if it actually needs to run a query on the DB, and what specific fields need to be included. That makes for smaller queries, and in some cases avoid spurrious UPDATE statements all together. And yes, all this is major implementation details of my persistance layer. It's all encapsulated within an abstract superclass that all my business object derive from. cheers, barneyb On 10/30/05, Scratch [EMAIL PROTECTED] wrote: Makes a lot of sense. So you probably have something along the lines of these functions in all your CFCs: - isValid(): Checks existence of ErrorSet or ErrorSet.ErrorCount() gt 0 - hasChanged(): Returns the value of variables.Instance.Modified which gets set to TRUE on every setXXX() method? Baz -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Message Handling
I do something like the latter
cfset errors = customer.validate() / !--- or .getErrors() ---
cfset errors.appendErrorSet(order.validate()) /
cfif errors.size() GT 0
...
Since the customer is going to return an ErrorSet, there's no need to
create one explicitly and then merge both results into it. Just use
the first's return value for the subsequent objects.
cheers,
barneyb
On 10/29/05, Scratch [EMAIL PROTECTED] wrote:
Hi,
In my applications, if a user sends invalid data, I like to let them know
about all of the problems at once rather than one by one.
So for example, after submitting a form, a user may get a msg like this:
- Please make sure your TITLE is less than 25 characters long.
- Please provide your age in integer format.
- Please choose a price in numerical format.
To handle this, I have a MSG CFC that stores the relevant messages of the
current request.
The process looks something like this:
1. User sends data
2. Validate customer details, update MSG component with any errors
3. Validate order details, update message component with any errors
4. If there are any errors, display messages and abort
My question is where and how should the MSG CFC be instantiated? You will
notice that almost all my other CFC's use it, so should I create a new MSG
CFC in each of them? Or should I just create a main one and pass it in to
each CFC every time?
Example A (Pass in one MSG CFC)
1. MsgCFC=createobject('component','Msg').init()
2. Customer.Validate(MsgCFC) - updates MsgCFC by reference
3. Order.Validate(MsgCFC) - updates MsgCFC by reference
4.
OR
Example B (Create a new MSG CFC in each object)
1. MainMsgCFC=createobject('component','Msg').init()
2. Customer.Validate() - another MsgCFC is created inside Customer
3. MainMsgCFC.Merge(Customer.getMSG()) - merge customer MSGs with MainMsgCFC
4. Order.Validate() - another MsgCFC is created inside Customer
5. MainMsgCFC.Merge(Order.getMSG()) - merge order MSGs with MainMsgCFC
6.
Example A seems cleaner and more proper, but I am not that comfortable
having every single one of my CFCs rely on another component as an argument.
Also in example B I have the choice to merge the messages or not. Sometimes
I want to suppress error messages for a certain component. I guess this can
be achieved as well in Example A by creating a new MSG object for each
validating CFC, passing it in and then merging the result back to the main
MSG CFC, but all of a sudden the solution isn't so clean anymore.
So basically it comes down where the MSG component should be declared,
inside or outside the related CFCs? What do you think? How do you guys/gals
handle messages from components?
Cheers,
Baz
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Framework or Not
Make sure you're not stripping the framework without proving that's the problem. Very likely it's not, and stripping the framework out will save a handful of ms per request and increase the cost of future enhancements and maintenance. Far more likely, you can implement some memory caching or DB tuning and get back far more performance, without having to sacrifice the benefits a framework can provide. Bottom line, until you know (via load testing) what the bottleneck is, don't go making any drastic changes to the app, or you're just shooting blind. Heck, it might be concurrency constraints on the DB, improper settings in the CF Admin, or network issues, and not related to your code at all. cheers, barneyb On 10/28/05, Ian Skinner [EMAIL PROTECTED] wrote: Not using a framework maybe what this application requires. From my framework session at MAX last week, that was one of the main points. One of the biggest goals of a framework is to save developing and maintenance time, usually the most expensive time of an application. But this comes to some degree at a cost of performance. If pure performance is required, then a more barebones approach maybe called for, with the trade off of more time spent in developing and maintaining the application. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFSQLTool debate
The way I've always thought about it is that the XML is the exchange format between the developer and the application. Gotta pass the data somehow, and XML happens to be a format that both can interface with natively with a minimum of fuss. I don't know about anyone else, but I've yet to learn to read any DB's binary file format, as hard as I've tried. cheers, barneyb On 10/28/05, Joe Rinehart [EMAIL PROTECTED] wrote: The reason is that XML is primarily an exchange language. Because it is based on an abstract syntax notation, DTD, it is very easy to overload and mis-use as a data store such as in Mach. Yes, it stared as an exchange language, but the ability to build structured, checked documents lends itself well to other applications - this isn't a misuse. A butter knife does a good job spreading jam; does that make it a misuse? I think others agree: Fusebox, Mach-II, Model-Glue, Struts, Spring, ASP.NET, Coldspring, J2EE, heck, even Cisco routers now use XML for configuration. A web application can have 1000s of events, as such, a management system is a better choice to store events. An application-level event management system of any use needs to be able to show these events in a structured format where application flow can be seen. XML provides a very nice structure for this. -Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFSQLTool debate
Assuming you're referring to the comment about if/ in FB, there's really no way around it with the current architecture. The only place you can have DO tags is in the XML, and you need to be able to call DO tags conditionally, or they're utility is GREATLY reduced. The DO-in-XML problem (as I've dubbed it) is probably my biggest gripe about FB4, but it's also the central tenet that makes it work. I don't think it's getting solved until there's an object-centric core behind the framework though. This is one very nice thing about Mach-II and Model-Glue. In both frameworks, your DO-equivalent is an in-code construct (announcing an event, or setting a result), not an XML construct, which means you don't need the conditional in your XML To go tangent surfing, FB's declarative nature is very nice. You can trace application flow through the XML. Mach-II is the other end of the spectrum, where you can see the list of potential events, but have little way of knowing how the app flows. Model-Glue is right in the middle, where the _potential_ flow is declaratively documented, but the actual logic controlling the flow is in-code, where it belongs. In this arena, I think Model-Glue's the best of the three, because it doesn't put logic in the XML, but it also lets you get the declarative benefits of the XML. cheers, barneyb On 10/28/05, Hal Helms [EMAIL PROTECTED] wrote: Patrick, I'm completely with you about being extremely dubious about having logic in a config file. I've fought this more than anyone. But there are a few, rare, unusual, scant, [insert adjective here] times when it's needed -- or at least is very convenient. We added it most reluctantly and still have to fight people who want a switch statement in the config file. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFSQLTool debate
To my knowledge none of the three frameworks allow multiple apps from the same config file(s). You can partition a single large app and use certian pieces in different UIs, I suppose, but it's still all one big app. Mach-II will let you run multiple applications in a single CF application, but each Mach-II app is still totally self-contained. Fusebox does not currently have that capability, and I'm not sure about Model-Glue. I believe Fusebox would be the closest in that you can use a single circuit.xml file concurrently in multiple separate fuseboxes, but again, that's just a reusing a file level thing (kind of like a custom tag can be used in multiple apps), not really any sort of multi-application support. cheers, barneyb On 10/28/05, John Farrar [EMAIL PROTECTED] wrote: Hal, On the other hand... we could just hire a developer to manage the file for us in M2, MG or FB. When you add an application to a system does the core config file automatically update? My guess is not. So rather than charging the customer the cost of a OO DB, we charge them for paying us to do the work. (Strangely enough that is usually what a customer would prefer.) Yet, it seems that for larger customer who understand project costing this would be a more responsible solution for someone like UPS or MM (oops, rather Adobe) when they use something like this. It could actually could function after both manner of schemes. XML for the simpler less automated solution... and an OODBMS for the enterprise solution. John Farrar P.S. Good use of terms like pesky... it is a great debate technique to subtle implications. One of the advantages of a DB (not even requiring a OODBMS) is the ease of installation of another app in the site and updates. M2 does (this is a question) allow multiple applications to run through the same config file doesn't it? If not then perhaps it is not needed and my assumption is wrong all together. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Process for Updating Database Records
I was actually thinking about one step further, where you actually get
the connection from CF's pool, rather than just the connection info.
So you let CF take care of everything (as it does normally), except
that you have complete control over the connection rather than letting
CF manage it. And really, my greater hope would be for that
functionality on BD, because it'd alleviate some of the
transaction-related issues it has (not bugs, per se, just
implementation details that prevent certain solutions from working).
But if it worked cross platform (with a check for the server to tell
how to get the connection, of course), that'd be the best scenario.
cheers,
barneyb
On 10/25/05, Doug Arthur [EMAIL PROTECTED] wrote:
Just to slightly modify what I've already done, is this what you're
refereing to Barney?
The only downside is that since the password is encrypted in the structure,
the password would still have to be supplied.
cffunction name=dump
cfdump var=#Arguments[1]#
/cffunction
cfscript
namedDatasource = db;
password = password;
ServiceFactory = CreateObject(java,
coldfusion.server.ServiceFactory);
datasources =
ServiceFactory.getDataSourceService().getDatasources();
if(StructKeyExists(datasources, namedDatasource))
dataSourceStruct = StructFind(datasources, namedDatasource);
try {
Class =
createObject(java,java.lang.Class).forName(dataSourceStruct.class);
DriverManager = createObject(java, java.sql.DriverManager);
conn = DriverManager.getConnection(dataSourceStruct.url,
dataSourceStruct.username, password);
stmt = conn.createStatement();
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] VARing component instances
No, you have a single instance and multiple references to it, where each reference is method-specific. You'll need to create a messageHandler instance inside each method and use it, rather than a global instance of it. I.e. change getMH to return a newly created instance instead of a shared instance. Since you're returning the data inside the messageHandler, there is no need for it to live longer than a single method invocation anyway, aside from the cost of instantiating them all the time, but that can be mostly mitigated by pooling. And that instantiation cost really isn't all that large, so I wouldn't even consider it until load testing indicates it's a bottleneck, and then you can consider pooling. cheers, barneyb On 10/25/05, Ryan Guill [EMAIL PROTECTED] wrote: Hey guys, i just had a thought and need to know exactly how this works. I have a component that I am using in composition in some of my other components. I have a messageHandler, which an object is being created of in all of my daos. In every method that runs, it inits() or resets the object, the method uses the messageHandler methods, it then returns the information stored in the message handler. then the next method that runs will init() and reset it again and the process repeats. I am createing an object out of the messageHandler in every dao when the dao object is created and then the same messageHandler object is being reused over and over. I am bringing it into each method like so cfset VAR mh = getMH() / and getMH() just returns the reference to the object. So my question is this: since i am using VAR inside each of the methods, is it really creating it locally? My worry is that it is not even still, and so if one method of my dao starts to run, and another method starts to run before the first one is completed will the init() of the second method clear out the data of the first ones instance? If so, then the only way I see around this is to create the messageHandler object for each method, or put exclusive locks in every method. I hope this really isnt the case... thanks, -- Ryan Guill BlueEyesDevelopment [EMAIL PROTECTED] www.ryanguill.com (270) 217.2399 got google talk? Chat me at [EMAIL PROTECTED] -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] VARing component instances
Instantiation is expensive, so you want to avoid it as part of request handling. It's not specific to CF and/or CFCs, DB connections have the same issue, and myriad other things do as well. The solution is a pool of already-instantiated object that are sitting unused. When you need an instance, instead of creating one from scratch (slow), you just pull an already ready instance from the pool (fast). That instance is yours forever, so you avoid the concurrency issues you currently have. So you don't really save any time overall (you still have to instantiate everything), but you avoid having to do it while a client is waiting for a request. With CF, you'd probably set up a scheduled task or event gateway that runs every X time and ensures that your pool has enough instances, creating more if needed. If the objects are well suited, they can be released back into the pool after they're done being used, further reducing the number of instances that have to be created. That's not always possible, however, depending on the type of object. If you do this, then you'll also want your periodic check to ensure there aren't too many instances in the pool. If there are, you're wasting memory, and some should be killed off. cheers, barneyb On 10/25/05, Ryan Guill [EMAIL PROTECTED] wrote: Alright, im with you on everything except for pooling. What exactly do you mean by that? On 10/25/05, Barney Boisvert [EMAIL PROTECTED] wrote: No, you have a single instance and multiple references to it, where each reference is method-specific. You'll need to create a messageHandler instance inside each method and use it, rather than a global instance of it. I.e. change getMH to return a newly created instance instead of a shared instance. Since you're returning the data inside the messageHandler, there is no need for it to live longer than a single method invocation anyway, aside from the cost of instantiating them all the time, but that can be mostly mitigated by pooling. And that instantiation cost really isn't all that large, so I wouldn't even consider it until load testing indicates it's a bottleneck, and then you can consider pooling. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC return types
If CF eventually has support for checked exceptions, I'll gladly spend the time to refactor as that'll be a huge asset. However, it's also orthagonal to many of CF's basing principles, so I'd be ridiculously surprised if it ever happend. And similar suprise levels would be warranted if MM found another (non-confusing) way to use the 'throws' attribute. Similar arguments go for 'deprecated', the moreso because it's a documentation (not functional) datum. I.e. execution doesn't care about deprecation, only docs do. So to me, the odds seem greatly in my favor, especially considering the productivity gains I collect by having those attributes there for me to use while I'm working against an API. But then we also all know how hard-headed I can be about stuff. ; ) cheers, barneyb On 10/25/05, Sean Corfield [EMAIL PROTECTED] wrote: On 10/25/05, Barney Boisvert [EMAIL PROTECTED] wrote: If you use CFCDoc, it will recognize a 'throws' attribute to CFFUNCTION, along with 'deprecated', and include them in the generated docs. ...although adding additional attributes might mean your code is broken by a future release of CFMX that happens to add new attributes with the same name (and a specific meaning). For example, CFMX 7 added description=short text description of function. -- Sean A Corfield -- http://corfield.org/ Got frameworks? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] VARing component instances
Instantiation is expensive, so you want to avoid it as part of request handling. I think that's overstating the issue rather dramatically Yeah, I know. Ryan asked about pooling, so I was explaining the impetus and the how, with no regard to the should I/shouldn't I. Oversight on my part. This is way complex for most apps - I really think it's overkill and I would not recommend it as a 'default' approach. I whole-heartedly agree. I mentioned that pooling should be reserved only for load testing confirmed bottlenecks in my first email, and should have reiterated in my second. I, for one, have never had a need to implement a CFC pool, and while I can't say I work on massive apps, they're of decent size with decent load. Still way cheaper to tune some SQL, add some caching, or even buy another box than it would be for the improvements pooling would bring. At least with the architecture we're currently using. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC return types
I don't have an answer to your question, but CFPROPERTY should be on that list too. On 10/25/05, Adam Cameron [EMAIL PROTECTED] wrote: For example, CFMX 7 added description=short text description of function. Interesting. How does this differ in intent from the hint attribute? Is it kinda like the displayname attribute of cfcomponent (that I have never worked out a sensible use for). Also... Most CF tags are rigorous in the enforcement of valid attributes, aren't they? I thought the laxness on cffunction and cfcomponent (?) was by design... So that people COULD add their own attributes, for their own needs? Is that not the case... Was it just an accident that the attributes aren't enforced on those tabs? Or is it some sort of (pardon the term) indian gift? -- Adam -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC return types
In some scenarios, you're better off raising an exception than returning null, but it doesn't work in all situations. Where you can't do it, you have to declare returntype=any, as you've discovered. For example a getSpouse() method of Person CFC should raise a UnmarriedException when called on an unmarried person, rather than returning null. cheers, barneyb On 10/22/05, Andrew Scott [EMAIL PROTECTED] wrote: I have a situation where I want to return null, or an object in coldfusion so far the only way I can do this is by not specifying a returntype. Is there any other method to decided whether the object was found or not. I know I other languages by returning null signifies nothing was found, how would this be translated in coldfusion mx 6.1? Regards, Andrew Scott -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC return types
Here's the skeleton of the function: cffunction name=getUser returntype=userCFC ... cfif doesUserExist cfreturn theUser / cfelse cfthrow type=UserNotFoundException / /cfif /cffunction And then calling it: cftry cfset user = getUser() / .. do stuff .. cfcatch type=UserNotFoundException .. deal with the invalid user .. /cfcatch /cftry Just for references, with a null return value the function would return some kind of null instead of throwing the exception, and the calling code would look like this: cfset user = getUser() / cfif user is null .. deal with invalid user .. cfelse .. do stuff .. /cfif cheers, barneyb On 10/22/05, Andrew Scott [EMAIL PROTECTED] wrote: Barney, If you don't mind I would like an example to clarify, in this example I am checking to see if a user exists, it returns the user object if it does. So when it returns back to the caller how do I handle it, if you can give me an example to help clarify what your saying that would be much appreciated. Regards, Andrew Scott -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
[CFCDev] XPOST: My GMail Issues
Apologies in advance to all who get a bajillion copies of this. I have seemingly found the source of my troubles, and fixed the problem. I just wanted to share the good news, and let other GMail users know so they can avoid the same issue. GMail lets you specify a encoding for outgoing messages, as you'd expect. If you select UTF-8 as the encoding, it not only switches to UTF-8 instead of ISO-8859-1, but it also switchines the transfer encoding from quoted-printable to base-64. Silly me had selected UTF-8, rather than the default, and it caused all kinds of issues. Fortunately, those seem to be resolved now, as long as I don't want to send anything outside the latin-1 charset (which is mostly valid). It's unclear why they decided to make it function in that manner, but whatever. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Easy way to check if oneCFC == twoCFC?
No, of course not. But you can do it on your server(s), and any third-party CFCs you install will magically have it. It's certainly not perfect, but since CF's base component doesn't have any of those handy utility things that java.lang.Object (and other langauges base classes) have, you gotta fake it one way or another. But rather than getUUID(), i'd recommend an isEquals method. Then you can override it as needed in subclasses, and the implementation doesn't matter (i.e. my server uses a UUID, your server uses System.identityHashCode), but we can both rely on the existance of isEquals. cheers, barneyb On 10/18/05, Mark Mandel [EMAIL PROTECTED] wrote: Barney - Are you trying to suggest I change every /web-inf/cftags/component.cfc file in the world to have this proprietry getUUID() method? I mean, I'm strong in the Force and all, but even that is a big try ;o) Mark On 19/10/05, Barney Boisvert [EMAIL PROTECTED] wrote: The UUID mechanism works well, as long as the implicit superclass is where the method is defined, rather than in some explicit superclass. That'd be Java's java.lang.Object, and CF's web-inf.cftags.component. Just throw your method in there, and every CFC on your server will magically have the method. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] Easy way to check if oneCFC == twoCFC?
cfc1.equals(cfc2) should work, though I haven't tested.
cheers,
barneyb
On 10/17/05, Mark Mandel [EMAIL PROTECTED] wrote:
All,
I'm not sure if my mind is doing a complete blank on this or what...
or if I just missed something really obvious.
If i have 2 CFC instances, and I want to check if they are the same
instance, is there an easy way to do this?
Trying to write:
if(oneCFC eq twoCFC)
Produces an error, as you can only use the 'eq' operator on strings
and numerics.
To do this, I've been forced to utilise the
java.lang.System.getIdetityHashCode() to determine if they are the
same object, but this seems a little cludgy.
Is there an easy option that I'm just not seeing?
Cheers,
Mark
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
b.n�+� qׯN�r��zǧu�ޙ qׯq�3�w�� �a{
+v˧���r��y��u�ڲ�^���y�h~�^zf��!B
�ⲻ�o � �'{ 0q�3�w���v˩���y��UǢ�b�
0�-�x �`�7���.��+��[�װ�Z�֦jG�热�(�m
���ej{Zr ��l��ny�ڂ���w^���v�r�z�7��+-�Ưj)ZnW�� 0���j�!o�}�^���Ήޢ�
Re: [CFCDev] (Admin) Blank mail
I didn't do anything, except bitch at Google about it. I'm sending from GMail in Firefox just like you, so it wasn't on my end. I suppose it's possible that they listened to me and fixed something within minutes, but I highly doubt it. The reason I suspect the mailing list software is that at least two on-list messages got blanked, but an off-list message to one of those who got blanks came through fine. All messages sent through the same GMail instance. cheers, barneyb On 10/14/05, Bill Rawlinson [EMAIL PROTECTED] wrote: I don't think it has anything to do with the list. Barney did something with his last email and it came through fine. However, for a brief period I was getting all of his emails in an encoding my reader (firefox with gmail) couldn't decode. Bill On 10/14/05, Raymond Camden [EMAIL PROTECTED] wrote: Barney emailed me yesterday to say that the list is having an issue where blank emails are coming through. I don' thave time to look into this now as I'm trying to wrap up work before MAX. I just wanted to let folks know it is on my radar and I'll try to get it, but it may be two weeks before I can. I'm assuming people now are just dealing with it, but if it becomes too much, please email me offlist. -- -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] inheritance advice
For the first part, I'd go with an abstract content object that
doesn't define getContent, and which Module, Category, Product, and
Page all extend. That's where you'd house all the common
functionality, leaving just the 'getContent' method up to the
individual implementations.
I didn't quite understand the Template stuff. But it sounds to me
like the templates aren't really nested, they're just applied in
sequence, right? I.e. for a category, the 'page' template has no idea
that a 'category' template was applied, it just knows that it's
getting some content from somewhere. Is that accurate?
cheers,
barneyb
On 10/13/05, Paul [EMAIL PROTECTED] wrote:
I'm experimenting with inheritance… I'll try to be concise explaining what
I'm up to…
My app contains Pages, Modules, Categories and Products, all objects that
are quite similar. Each is used to generate a static page to display in the
browser, and each has common attributes (ie meta_keywords, filename,
template_id etc.) The only difference really is in the way they get their
actual content; pages fetch simple html from the database, categories fetch
and display their associated products, and a product fetches its description
etc. Modules actually read xml config files to build very specific content
– store locator functionality and the like.
So am I on track to assume I can have my Modules, Categories and Products
extend Pages? Then I just overwrite the getContent() function to suit the
specific needs?
If that much makes sense, how to I handle nested templates? For example a
Page uses a Template to render itself, as do the other objects mentioned.
But a Category will have a Template of type Page (to render the browser
page) and also a Template of type Category (to determine the way its
products should render on the page). Similarly, a Product needs a Page
Template as well as a Product Template.
It scarcely makes sense to me, so if I need to clarify let me know…
(By the way most of the conversation on this list goes over my head so use
small words and speak slowly… ;))
Thanks,
Paul
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
b.n�+� qׯN�r��zǧu�ޙ qׯq�3�w�� �a{
+v˧���r��y��u�ڲ�^���y�h~�^zf��!B
�ⲻ�o � �'{ 0q�3�w���v˩���y��UǢ�b�
0�-�x �`�7���.��+��[�װ�Z�֦jG�热�(�m
���ej{Zr ��l��ny�ڂ���w^���v�r�z�7��+-�Ưj)ZnW�� 0���j�!o�}�^���Ήޢ�
Re: [CFCDev] inheritance advice
Would be nice of Macromedia would ad interfaces.
Not for this reason. CF is not a compiled language, and the
typechecking that interfaces do happen at compile time. Bit of a
catch-22, because the checks you want HAVE to happen at a place that
doesn't exist in CF's world.
The real reason for wanting interfaces is for the runtime typechecking
that CF does. I.e. declare an interface, specify the interface as an
argument type or return type, and then pass CFCs that implement the
interface. This is a far more important reason for wanting interfaces
in CF, and fortunately, it's one that doesn't require a paradigm shift
in CF language processing to implement, so it might actually happen at
some point.
cheers,
barneyb
On 10/13/05, Chris Stoner [EMAIL PROTECTED] wrote:
Seems to me more like this would be a good use of an interface (which we
don't have in Cold Fusion). But you can create a PageInterface CFC that
describes the page interface and procedurally implement it, that is make
sure you have a method for each method in the interface without a compiler
enforcing it for you.
Would be nice of Macromedia would ad interfaces.
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
b.n�+� qׯN�r��zǧu�ޙ qׯq�3�w�� �a{
+v˧���r��y��u�ڲ�^���y�h~�^zf��!B
�ⲻ�o � �'{ 0q�3�w���v˩���y��UǢ�b�
0�-�x �`�7���.��+��[�װ�Z�֦jG�热�(�m
���ej{Zr ��l��ny�ڂ���w^���v�r�z�7��+-�Ưj)ZnW�� 0���j�!o�}�^���Ήޢ�
Re: [CFCDev] inheritance advice
it is my understanding that cold fusion
is itself a cf to java compiler (among other things)
Yes, it is. However, unlike a real compiler, you don't get full
perspective of the app at compile time. When you compile Java, you
have to have all the resources for the whole app available to you so
you can do all the typechecking. CF, on the other hand, does it's
compilation piecemeal. And it does it iteratively. In other words,
if CFC X depends on CFC Y, that's great, but CFC Y can be recompiled
at a later time without CFC X being recompiled. That can lead to
undetectable type issues, because the issue is with X's dependance on
Y, and therefore in the code of X, but X isn't part of the compilation
unit, so CF cant notice until runtime.
So while CF is a compiler, it's not a compiler like Java has.
I agree this is the overall desired goal of interfaces in CF but if the
interface is not enforced it becomes somewhat useless doesn't it?
You don't define methods in a CF interface, because there isn't any
way for that to work. You don't care about methods when you're doing
typechecking on arguments and returntypes, only whether the type being
passed is an instance of the type declared in the CFARGUMENT or
CFFUNCTION tag. Right now, you either have to pass the declared type,
or a type that extends the declared type. With interfaces (without
method validation), we'd suddenly be able to pass objects around that
impelement an interface, and thereby avoid having to use a whole lot
of really contrived inheritance hierarchies.
That's the value of interfaces to CF, if you ask me. Method
validation is arbitrary in CFC, and intentionally so. Heck, you can
even dynamically add and removed methods on an object instance, which
would make any compile-time method checking (if it were possible)
meaningless anyway.
cheers,
barneyb
On 10/13/05, Chris Stoner [EMAIL PROTECTED] wrote:
While I agree that it isn't a compiled language in the same sense that you
compile it yourself within your IDE, it is my understanding that cold fusion
is itself a cf to java compiler (among other things). So the compile time
checking could happen, but not in the same why you would see in java. At
first run (compile) time the interface implementation could be checked and
an error could be thrown/displayed to the page like any other CF Exception.
The real reason for wanting interfaces is for the runtime typechecking
that CF does
I agree this is the overall desired goal of interfaces in CF but if the
interface is not enforced it becomes somewhat useless doesn't it? What good
is type checking if the CFC/Object doesn't fit the description of what that
type is?
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
b.n�+� qׯN�r��zǧu�ޙ qׯq�3�w�� �a{
+v˧���r��y��u�ڲ�^���y�h~�^zf��!B
�ⲻ�o � �'{ 0q�3�w���v˩���y��UǢ�b�
0�-�x �`�7���.��+��[�װ�Z�֦jG�热�(�m
���ej{Zr ��l��ny�ڂ���w^���v�r�z�7��+-�Ưj)ZnW�� 0���j�!o�}�^���Ήޢ�
Re: [CFCDev] inheritance advice
Hopefully this will go through... The problem is with the way CFML is compiled. You can't make those compile-time checks work consistently, because changing a one class doesn't require recompiling other dependant classes. In other words, CF doesn't recompile a CFC that extends another CFC when that second CFC gets recompiled. Therefore your claim to implement status would be invalid as soon as that happened in the same scenario with interfaces rather than inheritance. The same thing happens with dynamically assembled objects. I.e. I create a CFC that FAILS the interface method check, but then dynamically add some methods to make it legal. In that scenario, I'd want to be able to pass the instance of the CFC as the interface. CF simply can't do any sort of compile-time checking of your application; it's a runtime language, and intentionally so. cheers, barneyb On 10/13/05, Chris Stoner [EMAIL PROTECTED] wrote: On 10/13/05, David Ross [EMAIL PROTECTED] wrote: The type checking is the most important feature, as it enables you to... While your second solution is a resonable idea, why would you not marry it with compile time vaildation and your extended (improved) method not implemented error messages? I agree that runtime interface validation/method checking would be a hog but there is no reason that the object cannot earn the right to claim to implement at compile time. I dislike people who are intolerant of other people's cultures and the Dutch -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] ImageCache experiments
Your image has to be served in a request that's specifc to the image. So like your image.cfm example, but with CFCONTENT, rather than CFOUTPUT. You'll be better off, though you'd be even better off using a disk-based cache, and letting Apache (or whatever) serve the static files rather than a CFM template. cheers, barneyb On 10/6/05, Nando [EMAIL PROTECTED] wrote: I tried , but cfcontent cuts off all other textual output on the template if i place with other content. I need it inline. The docs even say that's how it should behave when using the variable attribute. The reset attribute is disabled when the variable attribute is used. Is there a trick to get that to work? I tried for quite awhile. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] ImageCache experiments
I definitely think your problem is something aside from disk access. Have you monitored the reads it's doing under load and confirmed that it's really at it's max? Any decent filesystem will do in-memory caching of commonly requested blocks, so unless you're hitting a wide variety of disk-based content, you shouldn't be hitting the disks at all. Do you have trusted cache enabled in CF and your CF templates on the same physical device as the graphics in question? If you do, then it's definitely not a disk issue. Bottom line, I'd make sure that's really your problem before you bury your CF server in a massive number of requests, and completely slaughter it's ability to serve real pages. cheers, barneyb On 10/6/05, Nando [EMAIL PROTECTED] wrote: So i should move the cfcontent out of the getImage method, and return a struct instead with the image type and image data. (or do i really need different type attribute values for the different image types?) It's working with the cfoutput tags, but maybe that's not as efficient as it could be. The reason i'm trying to serve these images from memory is because the interface is very rich in graphics - and it seems the performance bottleneck might be at the disk access point. There's plenty of memory and enough cpu available, and when it bogs down, it's the graphics that are coming in one by one, 15, 20 seconds apart. My reasoning is that all threads could have more or less instant read access to memory, but they'd need to que for access to the disk. Does that make sense? thanks for your help! Nando -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
Re: [CFCDev] Multiple Instances
You can't run it in a separate memory space without having a significant performance cost for method calls. In-memory access is very fast, but a separate memory space necessitates a non-memory access. If you're running your backend on separate servers from your front end (like you would with a JSP frontend for an EJB app), then you just cope, because the advantages outweigh the disadvantages. In this case (with a single platform for the entire app), I can't see that it makes any sense to segment the memory space within an app instance. cheers, barneyb On 9/28/05, Mehdi, Agha [EMAIL PROTECTED] wrote: Damon, That's my biggest worry. I thought of creating mappings for my service layer but I first wanted to see if there was a better way to run service layer in its own memory space where it doesn't share other applications resources. Do you think it'd still be a performance issue if I bumped up the memory allocation for service layer? (BTW, how do you about increasing the memory?) Thanks Agha Mehdi IDT - eBusiness Program Manager -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC Assignment Query
Line 9 isn't deleting the object, it's deleting a REFERENCE to the
object. The object is only dead when all references to it are gone.
cheers,
barneyb
On 9/26/05, John Samson [EMAIL PROTECTED] wrote:
If CFCs are copied by reference [as the output at line 8 suggests] then how
come I can still reference an object [line 10] once it has been deleted
[line 9]? I would expect line 10 to throw an error but it doesn't, however,
an attempt to reference session.nameObj at the same place does.
Can anyone help me understand what I am seeing?
1. cfapplication sessionmanagement = true
2. cfset session.nameObj = createObject('component',
'nameComponent').init()
3. cfset session.nameObj.setName(Elaine)
4. cfoutput
5. cfset variables.namePointer = session.nameObj
6. #variables.namePointer.getName()#br
7. cfset session.nameObj.setName(Richard)
8. #variables.namePointer.getName()#br
9. #structDelete(session, nameObj)#
10. #variables.namePointer.getName()#br
11. /cfoutput
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC Assignment Query
Correct. That's what pass-by-reference means. There is only ever a single instance of the thing in question, and when you assign it to another variable, you're just making a new reference to the same object. Pass-by-value, on the other hand, creates a new copy of the thing across assignments, and the two instances are completely unrelated. Primitive types are almost always pass-by-value, while complex types are almost always pass-by-reference. The notable exception is CF arrays, which are pass-by-value (for some unknown reason). Note, however, that the pass-by-value is a shallow copy, not a deep copy, so if you have pass-by-reference types in an array, the array is duplicated but the objects inside are not. cfset a = arrayNew(1) / cfset s = structNew() / cfset s.name = barney / cfset arrayAppend(a, s) / cfset s.name = heather / cfset arrayAppend(a, s) / cfdump var=#a# / cfset a2 = a / cfset s = structNew() / cfset s.name = ryan / cfset arrayAppend(a, s) / cfdump var=#a# / cfdump var=#a2# / That code will illustrate all three concepts (array pass-by-value, struct pass-by-reference, and shallow copy of arrays). Make sure you manually figure out what you expect it to do before running it. cheers, barneyb On 9/26/05, Ryan Guill [EMAIL PROTECTED] wrote: Okay, so taking this a step further, If I take a component and create an object out of it, stored in varible x, set variable y equal to variable x, change a value in variable x, the value in y should have changed as well? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC Assignment Query
Yep, services should be singletons, should be mostly stateless, and since they're singletons almost have to be cached. I say mostly, because there is often some state that the object needs to maintain, but it's not really object state. Stuff like DSNs, or directory paths. Not really part of what it means to be a service, but still essential data that the service needs to operate. I'm not familar with the service locator pattern, but this page http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html seems to indicate it has nothing to do with the caching and such. All that stuff should happen in the service factory; the locator is just a means of finding the factory. The locater pattern seems to be for scenarios where you don't have an explicit reference to the factory available already (as is often the case in large J2EE apps that use JNDI), but doesn't really apply to CF, since you've got the application scope. cheers, barneyb On 9/26/05, Ryan Guill [EMAIL PROTECTED] wrote: Well the reason I am interested is because COAL was intended to be a good example of the service locator pattern. One of the parts (a big part) of the service locator pattern though is the caching of objects, so that if you request the same object (or service) over and over again that it would hold a copy and save you some cycles. and now that I am writing this its starting to make more sense that it is the service locator pattern, and a service is stateless, so it wouldnt matter if it was cached, it should be cached, its a singleton! damn. well, while the other part of the service locator pattern works very well for COAL, the caching part of it (it was designed to be cached before instantiation, so that you could pull a fresh copy out and isntantiate it again and go, it just would just save the createObject()...) is basically worthless in this situation. I had a sneaky suspicion of this for a while and just haven't found the time to test it out. Guess this answers it. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC Assignment Query
I meant a representation of the object's internal state that can't be viewed by anything except the object itself. In Java you'd use an inner class with private members, CF has no such facilities. If an object's functionality depends on it's ethereal state, then that state isn't really ethereal, is it? For example, if an object performs caching, that cache is ethereal state. You don't need it in the cloned object; the clone can just create an empty cache and start from there. The reason for not passing the whole variables struct is that that contains the 'this' scope and all the CFC methods as well as instance data. That's the reason for the careful partitioning of instance state into the 'my' or 'instance' subscope. If you're designed your internal state storage correctly, you should be able to create an exact duplicate (a clone) simply by initializing the new object and duplicating the source object's 'my' subscope into it. Note that that gets messier as you deal with composition; but most of the time, the composited objects are ignored and recreated in the new object based on the real state. cheers, barneyb On 9/26/05, Nando [EMAIL PROTECTED] wrote: i was wondering what you meant by an opaque representation of the object's internal state ;) great discussion! although i have to say that the example of the clone function wouldn't work in all cases. if an object's functionality depends on it's ethereal state, then you'd need more than variables.my or variables.instance. so maybe a getClone() and setClone() in the object you'd want to be able to clone would be needed that returns and accepts the whole variables struct within an object. ? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] CFC Assignment Query
The variables scope has a whole bunch of extra stuff in it (like all the methods, the 'this' scope), and it may contain state that you specifically don't want to include. By segregating the different types of state, you can easily pull out and deal with just the important stuff. Whether or not you need a deep copy or not kind of depends on both the object in questions, and your specific definition of deep. If you mean duplicating non-object complex data, then I'd say yes, but if you mean duplicating all complex data (including objects), then I'd say probably not. Most of your composited objects can be recreated based on the real instance data, and some of them would probably be very adverse to duplication (i.e. singletons). And of course, like everything else, there's not really a right or wrong answer without a complete context. cheers, barneyb On 9/26/05, Nando [EMAIL PROTECTED] wrote: Barney, What's the drawback to passing the whole variables struct? That's an open question. I'm ignorant here. In light of this discussion, *sounds* like we'd need a deep copy of the variables struct. But again, i'm just trying to get a clear understanding of the situation here. The reason for not passing the whole variables struct is that that contains the 'this' scope and all the CFC methods as well as instance data. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Ruby on Rails for CF
Ruby on Rails. ;) cheers, barneyb On 9/22/05, John Farrar [EMAIL PROTECTED] wrote: OK... what is RoR? I lost my online acronym dictionary! John -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Default for Dates in a Transfer object
If you don't require a date, then you can't qualify the argument as a date, because CF has no concept of NULL. The closest you can get is saying is equivalent to null, and then using the string type as you propose. You should do validation inside your method like this: cfif len(arguments.myDate) GT 0 AND NOT isDate(arguments.myDate) cfthrow type=IllegalArgumentException message=myDate is not a valid date / /cfif That way you preserve your argument type checking, even though CF is forcing you to do it manually. If you ask me, CF's lack of NULL is really quite a burden. CF is a loosely typed language, which is fine, but then they came and added in strong typing all over the place, but didn't provide the ability to use NULL, so the strong typing is often either cumbersome or simply unusable. This is a perfect example of that. cheers, barneyb On 9/20/05, Peter Hardy [EMAIL PROTECTED] wrote: Hi guys, I've seen this on the forum before but I'm can't remember the answer at all. I've created a transfer object that takes amongst others a couple of date parameters. Trouble is, they are optional parameters so sometimes they are a valid date and sometimes they are equal to . If my cfargument type to date cf just throws an exception. How do I handle this? Shoudl I just store it as a string? Cheers, Pete (aka lad4bear) -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Default for Dates in a Transfer object
The problem is that 'string' is way too lenient, because you want to allow dates, the empty string and that's it. A type of 'string' will also allow hulabaloo to be passed without error, which is undesirable. Of course, you HAVE to use type=string in order to circumvent CF's weird type system, but by doing so, you're basically removing the utility of having the typing system at all (and may as well just leave the attribute off). Not that I recommend that, but it's frustrating to have to jump through silly hoops like this in a language that primary design characteristic is ease of use. cheers, barneyb On 9/20/05, Patrick McElhaney [EMAIL PROTECTED] wrote: On 9/20/05, Peter Hardy [EMAIL PROTECTED] wrote: I've created a transfer object that takes amongst others a couple of date parameters. Trouble is, they are optional parameters so sometimes they are a valid date and sometimes they are equal to . If my cfargument type to date cf just throws an exception. Sometimes it's a valid date, but it's always a valid string, right? Wouldn't it be appropriate to make the argument type string? Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Default for Dates in a Transfer object
So make an error. Throw an exception if the string isn't empty and can't be converted to a date. Which is exactly what the code I proposed earlier does. (and may as well just leave the attribute off). Not that I recommend that I'm on the verge of recommending it. Strong typing is a great asset to programmers, as it helps catch a lot of bugs earlier than they might otherwise be caught. I happen to like it a lot, and am willing to deal with CF's buggy (as far as I'm concerned) implementation to get the benefits I can out of it. cheers, barneyb On 9/20/05, Patrick McElhaney [EMAIL PROTECTED] wrote: On 9/20/05, Barney Boisvert [EMAIL PROTECTED] wrote: The problem is that 'string' is way too lenient, because you want to allow dates, the empty string and that's it. A type of 'string' will also allow hulabaloo to be passed without error, which is undesirable. Another option is to roll your own date object and pass an instance of it into the function instead. Of course, you HAVE to use type=string in order to circumvent CF's weird type system, but by doing so, you're basically removing the utility of having the typing system at all (and may as well just leave the attribute off). Not that I recommend that I'm on the verge of recommending it. Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: Possible Spam:Possible Spam:Re: [CFCDev] Default for Dates in a Transfer object
yep, just the last couple of this thread though. On 9/20/05, Roland Collins [EMAIL PROTECTED] wrote: Anyone else receiving triple posts? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Table joins DAOs
I think Patrick got the jist of it. If you have a form that allows creating a user, a contact, and an employee, then it sounds like you've got three entities (a user, a contact, an employee), and you just happen to be using the same information for each one. So I'd expect the app to create a user object, persist it with a user DAO, then create a contact, persist it, and finally create an employee and persist it. Now, if you have entities that extend one another (for example GenericFile and FlashFile in a CMS), then it's very likely that your FlashFile DAO will deal with both the generic_file and the flash_file tables in your database, if you've set up your DB to have table-level inheritance. cheers, barneyb On 9/15/05, Nick Han [EMAIL PROTECTED] wrote: Barney, can you reduce the language down like a fraction so I can understand better on what you just said? Ok, for a DAO example, I have a form that will insert information about the user into users table, contacts table, and employment table? Will I have one DAO to do all this or 3 separate DAOs, one for each table? It sounds like what you said is that there should only be one DAO? Thanks in advance. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] OT: Inner Exceptions
Nope, sure isn't. CF does it internally, but there isn't a way to do it yourself. Definitely be nice to have though. You can synthesize it a little bit though. Put the CFCATCH structure in the request scope, and then throw your new exception. When you catch that new exception, check the reqeust scope for the cause, and if it's there, inject it into the new CFCATCH structure, and then you're back to what you want. Wrap both ends up in custom tags, and you should be set. I've never done it for this reason, but I've used that same basic design for throwing an exception object, rather than just an exception name. Works pretty well. cheers, barneyb On 9/15/05, Peter Hardy [EMAIL PROTECTED] wrote: Hi guys, In .net, when using try / catch statements you can wrap any exceptions that occur in your own custom exceptions and rethorw it. You can then access both the custom exception, i.e myException, and also the original exception i.e myException.innerException. Is it possible to do the same thing in CF? Cheers, Pete (aka lad4bear) -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] object compostion question
In this case, I think the 'it depends' hinges on what that ignored field is. In any case, A.x's elements are going to have field e in them. The question is whether both A and B are refering to the same P entities. If so, then you should use a single P object. If they're different entities, then you'd want P and P'. The way to handle P.e depends on what it is. When you say 'sometimes' P needs an 'e' property, what do you really mean? What I'm getting at is whether P needs an 'e' property, or if P needs a place for 'e' extensions to hang (composition), where e is actually another object that is composed into P. That make any sense? cheers, barneyb On 9/15/05, Douglas Knudsen [EMAIL PROTECTED] wrote: Say I have object A. A has a property x. x is an Array of object P. P has properties m,n. Now I create a new object B that has a property y where y is an Array of object P. But in B's case, P needs an extra property e. Is it common to create two differnt P objects in this case? Or just create one P with properties m,n, and o when A uses P it can just ignore o. I know, common response is 'It depends'. I'm just looking to see if there is a watch out this approach will muck things up usually or seems ok. In my case P is an object with Empoyee information. Sometimes it needs to have say 3 properties, other times 4. -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] object compostion question
A P is a P. If you don't use all the properties of a P, that doesn't change what it is. Don't use inheritance, don't use multiple versions, just use a single P class, and use what pieces you need from it for each task. cheers, barneyb On 9/15/05, Douglas Knudsen [EMAIL PROTECTED] wrote: say teh properties of P are m = username n = userid o = List of HR actions No, sometimes I I want to just build a report involving Ps and only need username and userid. Other times I may need one instance of P that has the list of HR actions. In short, I;m wondering if I can avoid having multiple objects thate are all just variations of P. I suupos I can use some inheritance with P. Have P be the parent with teh common properties, then extend P to P1, P2, or P3 as needed adding teh other properties. being a little new to the full blown OOP stuffs, just wondering about an approach. DK -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factories and mappings
Bill, that's what Nando is not describing. My interpretation was that every install had a complete copy of the code, not just the custom code and then access to shared-use components for the core functionality. I very much like how you've set up your app, and have done it exactly the same way myself. It's also the way Mach-II and FB4.1 are designed to function (single core install shared by multiple apps). cheers, barneyb On 9/11/05, Bill Rawlinson [EMAIL PROTECTED] wrote: Barney, To answer your question: I'm also kind of curious. How large of applications are being mass hosted like this, and need to have the ability to play nice with myriad other apps (both the same code and different)? the company I work for builds an app that, against our recommendation, is often installed many, many, many times (in one instance 300 times) on one server. It is a pretty complex app but we have architected it in such a way that the core files that are the same across all instances are installed in one location using using a standard named mapping. Then only the subsets of code that are unique for each instance are duplicated for each install. The app is kind of a CMS/Portal/Intranet/Knowledge Management/Document management hybrid that can be extended fairly easily to integrate with other applications. Written almost entirely for CFMX 6.1 with CFML though there are some small parts in Java when the functionality was needed. Sure, we would love it if every customer were willing to deploy on seperate servers (or at least with seperate CF instances) but that generally isn't the case even when dealing with our larger customers (those who deal in the billions of dollars). Since our app CAN work sharing resources across many intances, even if performance becomes degraded, the customer often will do that in order to save $$. Bill -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factories and mappings
You don't have to do it server-side. For example, all of my FB4 apps are 'built' as part of publishing. The code comes out of source control, is processed by `ant`, and then uploaded to the server. So the server has no knowledge that the code it gets isn't what's in the repository. For that matter, you could just as easly use a standard install program. Just ship the parameterized code in the installer and as part of the installation, the user specifies the criteria and the installer updates the code as part of 'unzipping' it for them to upload to the server. cheers, barneyb On 9/11/05, John Farrar [EMAIL PROTECTED] wrote: I see a big issue with rewriting files at install time. The issue isn't the mapping. (Although that does limit your sales to someone who has enough knowledge to understand what a mapping is and what you are telling them to do during install. Portability is more than how a piece of code runs... what you are saying is the code isn't portable.) Aside from that, there is also the issue that some hosting environments lock down directories so that the code cannot write files without you requesting them to manually add CF permissions to write, update files in those directories. (Sandbox security) This is just a fact (and I have debated the policy with some of those companies personally.) John Farrar -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Factories and mappings
You've got one thing backwards, subclasses would need to be at the
same level or HIGHER than the class they're extending. Other than
that, it sounds reasonable.
However, there's absolutely no reason that any hosting environment
(dedicated, shared, mass hosted, whatever) shouldn't give each
individual website at least one mapping, so I'd say you're better off
with a build process that'll do a substitution of that mapping at
install time. So you're code would be say
extends=${cfcRoot}package.cfc, or whatever, and then at install
time, you run the build script and it subs out ${cfcRoot} with the
appropriate value.
I'm also kind of curious. How large of applications are being mass
hosted like this, and need to have the ability to play nice with
myriad other apps (both the same code and different)? It seems to me
that the apps large and complex enough to really benefit from a
massively OO backend probably aren't the kinds of apps that get
deployed a bunch of times to shared servers.
cheers,
barneyb
On 9/10/05, Nando [EMAIL PROTECTED] wrote:
Kerry's post about using a GatewayFactory got me thinking about factories in
general, and i wanted to float an idea out here and see what some of you
smarter, more experienced OO'ers think.
One of the practical problems some of us run across in using CFC's rather
intensively in our distributed apps, one's we're building to sell multiple
times, is that mappings cannot be set on an individual application - they
are server wide. So to have more than one instance of an app on a server
puts you through some gymnastics. Either you have to search and replace the
mapping name in your CFC's and test each individual app carefully for any
errors (and carefully maintain all those variations!), or you need to put
them in separate server instances ... or you just can't use mappings, which
tends to tie you down.
Now let's say that we design our app as Kerry suggests, so that on
application start, a Factory is instantiated into application scope from
Application.cfc or Application.cfm. All object instances in the application
are created by Factory (or it's composed child Factory classes if you want
to break the responsibilities up, as you probably should).
Now, as long as your CFC's are in the same directory as Factory or lower,
the singleton instance of application.Factory should have no problem finding
them, instantiating them, and returning them without a mapping. Going down
the directory tree works, it's just going up where you run into problems.
The only limitation i can think of is that components that employ an
inheritance relationship would need to be in the same directory or the child
would need to be lower. Composition, no matter how the objects are in
relation to each other, could be handled by application.Factory (you'd pass
in a reference of application.Factory, actually you'd pass in this when
instantiating parent components and use Factory to instantiate the
children).
Anyone see any holes or limitations one would run across down the line with
this approach?
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component?
I guess my point was that I am explicitly disallow considering the datasource to be a property of the gateway object. It's an implementation detail that the gateway object doesn't claim to know anything about. If you wanted to use a setter (which is probably reasonable), you can do that and make it a private method so that people can't use it. You maintain the abstracted setting of the variable, but also retain the datasource's status as non-property, since no one except the CFC itself can do anything with it. However, if you do that, then you'll want to use getDatasource() in all your CFQUERY tags, rather than the raw variable, and to me, that's a foolish waste of resources, and the main reason I don't do it that way. cheers, barneyb On 9/9/05, Jason Davey [EMAIL PROTECTED] wrote: Barney: Thank you for confirming my thoughts. I prefer the getter / setter methods so that I can optionally and deliberately break OO patterns where I want to embed logic in the setter method that is more than just cfset variables.dsn = arguments.dsn. See my previous post for an example. In fact, as far as syntax goes, I like this in my init() method: cfscript setDataSource(); return THIS; /cfscript Jason D. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component?
Just for reference, I also use a factory to create all my gateways. The factory gets created with a reference to my app config object, and then it takes care of passing the dsn from that into the constructor of the gateways when it constructs them, and caches them for subsequent requests. It also handles special gateways like for uploaded files, where you need a directory reference as well as a dsn, so the application doesn't need to care what args the given gateway needs. If you ask me, this is really the utmost of laziness, because I can change the init params of all my normal gateways in a single line of code, and if I need to change some weird gateways as well, they're right there in the same file. Since everything goes through the factory, I'm guarenteed that my app won't break in any way, no matter how drastic the changes. cheers, barneyb On 9/9/05, Jason Davey [EMAIL PROTECTED] wrote: Barney: I'm now on the fence about these different approaches. Again I keep going back to the phrase, on balance to determine if a solution is right. Meaning that foolish waste of resources is relative tradeoff between coding practices and resource efficiency. I'm interested in code that minimizes complexity of interface calls because I'm lazy and I forget 3 months down the road how to get something from an object. This is why I liked your position of clean methods that don't pass parameters. The getEmployees() method was the starting point this morning. And then I wanted to stream-line it further by avoiding having the caller set datasource as a property of the object as in objGW.datasource=dsn;. The getDataSource() method embedded in the setter seemed like a reasonable approach. But the good feedback today has given us other options to think about. Along came Kerry with the factory approach which pulls in the raw variable from the application scope instance. I like this approach and want to play with it further because it seems to me to provide better resource efficiency lacking in the getDataSource() - invoke another CFC method - while allowing the raw variable to be planted in the setter function as per your suggestion. In short, I'm looking for the best way to call a gateway and not have to pass in a datasource parameter so I can continue to be lazy, forgetful and worry free. Jason D. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component?
It's nothing more than a single object that has a reference to EVERYTHING in the app. So you can ask it for static config options (getProperty(dsn)), or for a factory (getFactory(gateway)), or whatever else your app needs. Most importantly of all, since it's both an encapsulated object and a singleton, any updates to it magically propogate to everywhere it's used in the app. If you have smart users, it can also be used to reload pieces of the app but not others. Hypothetically, if you needed to change your DSN mid-flow, you could update the config object, and then all the dependant objects would notice, and take whatever actions. The gateway factory, for instance, would notice, and not return any cached instances any more, instead creating new ones that use the new DSN. This object status is very important, because during initialization, you end up with the scenario of having to pass the config to a CFC's constructor before the entire config is built (because that CFC instance has to be added to the config). Perfect example is a factory object. However, since the config is an object, properties that are added after it's passed to the constructor will still be available. I stole the idea from Mach-II, primarily, and tweaked things around to better suit a general app config, rather than the Mach-II framework specifically. cheers, barneyb On 9/9/05, Anthony Israel-Davis [EMAIL PROTECTED] wrote: I really like the idea of a config object, but I'm having trouble picturing it. Could you give me a simple idea of what it looks like? And how it is used in code - I don't need anything fancy, just a general idea of what kind of methods are contained in it (if anything beyond init?) It sounds like it just sets a bunch of variables, which makes sense to me - is there anything else to it? Thanks! Anthony -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Lines Between TO, Bean and BO?
Nope, sure aren't. Validation is really the fundemental entity-level business operation, in my view. If you are concerned, implementing a pooling mechanism (perhaps where pool management is handled asynchronously via the async event gateway), will alleviate the instantiation problem, because you'll just be pulling an unused instance and populating it. That'd be the first tact I'd consider if I found instantiation overhead to be a problem, but I haven't gotten to that point yet (I.e. hardware is still cheaper than optimizing). And really, I suspect that do something request are almost never the most heavily loaded parts of an application, so this bottleneck won't arise very often. You said if you want to validate your BO before, say, you send it to a DAO, as if implying that sometimes you don't do that, and therefore potentially allow persistance of invalid entities? My managers (which are also autogenerated) are the only objects that get to talk to the DAOs, and they never do insert or update without a valid BO. I will say that I've broken that rule once, for user accounts that were migrated and the old structure had different requirements than the new, and so it was possible for old accounts to be invalid. We had to deal with that, so I added a flag that allowed persistance of a invalid user object when explicitly requested, because we needed to do some operations that weren't user initiated (like updating expired passwords), and so couldn't force the user to fix the invalid info. cheers, barneyb On 9/1/05, Brian Kotek [EMAIL PROTECTED] wrote: Barney, a while back you wrote: Some of my BOs are nothing more than get/set/validate (where the validation is generated based on the DB schema), and some are masses of composition and business logic methods, including custom validation. I'm curious, if you want to validate your BO before, say, you send it to a DAO, are you concerned about instantiating a potentially heavy CFC just to set for valid data? I'm just curious. On advantage I can see to having a Bean that validates itself before you create a BO is that you avoid unnecessarily creating a complex BO if the data isn't valid. I know in general we shouldn't design around possible performance issues but rather actual performance issues, I just thought I'd get your take. Thanks. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Lines Between TO, Bean and BO?
I'd say no, but the CF world seems to have likened them to the same thing. I suspect that stems from Entity Bean being shortened to Bean, in which case it makes sense, but it's still confusing, since bean isn't really enough to determine what you're talking about (Enterprise Java Beans, Java Beans, Entity Beans, Session Beans, Message Driven Beans, etc.). cheers, barneyb On 9/1/05, wolf2k5 [EMAIL PROTECTED] wrote: Quick question: is a bean and a business object (BO) the same kind of object? It looks so according to the following blog post: http://www.barneyb.com/blog/archives/000310.jsp Thanks. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
Note that I said deprecate, not remove, so the interface is not really changing (in the sense that existing applications won't suddenly break), just some new methods are added to deal with an ambiguity that has cropped up since design time. So apps could continue to call getGasLeft(), but they should be changed to call getGasLeftGallons() (which is the same thing), to avoid the ambiguity. At some point, the getGasLeft() method might actually be removed (at which point non-updated apps would flat-out break), but that's often not the way deprecation works. So your example is correct, though I'd recommend not putting UI stuff (the I18N call) in your business logic; that's a UI concern, and should stay there. However, now that the application supports both english and metric, the UI's call to gas() is ambigious, so I'd hope that you'd change it to gasGallons() (which will return the identical result, since the gas() should simply be cfreturn getGallons() /). You don't HAVE to, but it'll ease maintenance down the road. cheers, barneyb On 8/30/05, Kerry [EMAIL PROTECTED] wrote: So you'd deprecate that method, and then add getGasLeftGallons() and getGasLeftLitres() or something I know its only an example off the top of your head, but this does change the interface! So I can see why John would question the benefit. Heres my take on the example - off the top of my head (feel free to pick holes in it...) car.gas returns a int, so then the presentation layer has to decide wether its litres or gallons. and its just a variable name, so all it can really ever do is return a variable. car.Gas() could at first only return a variable as well, but then when your app grows, you have the option make it call several other functions within itself. which makes the app more flexible. so in the future, car.gas() might actually do something like: var fuel = math.convert(liquid,metric,country.getLiquidMeasurement(),gasamount); return i18n.formatLiquid(fuel,country.getISOAlpha3()); all that, and your presentation layer is still only calling car.gas(), no need to change anything except the contents of the function. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component?
Yes, because that changes the interface, which will break existing code. You could make it an OPTIONAL parameter that defaults to 'gallons', and be safe, but I don't like the idea of passing in parameters that dictate behaviour to methods. I much prefer to have a distinct method for each distinct behaviour, if that makes sense. To take a different tact, the standard definition of a getter is a Zero argument method that returns the value of an object's property, not a one argument method that returns the value of an object's property, based on some dynamic calulation that relies on the passed argument. So, you no longer really have a vanilla getter. Note, however, that neither definition precludes you from doing some wholly internal computation to arive at the returned value; it's the external dependancy (the passed parameter) that differentiates them. Subtle points, but enough to make me take the add methods route. cheers, barneyb On 8/30/05, John Ottenbacher [EMAIL PROTECTED] wrote: Greetings, I am trying to transition from procedural development to OO development. I'm curious, in the example given is there anything 'wrong' with adding a parameter to GetGasLeft()? It would have to be optional and default to the original unit of measurement so as not to break existing code. getGasLeft(GALLONS) getGasLeft(METERS) Thanks, John -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
By and large, you don't need it. Putting variables in the 'this' scope breaks encapsulation, but there are two cases where you do need it: 1) cfreturn this / at the end of your init method, so the method returns a reference to the object as a constructor should. 2) for public constants. You can't actually enforce constants in CF, but it's still sometimes valuable to have keys that your object defines and which users of your component use as parameters, without ever knowing what the values of the keys are. This is a lot more common in fuller-featured languages like Java or C, because you can actually have constants (or final variables) that cannot be changed. cheers, barneyb On 8/29/05, wolf2k5 [EMAIL PROTECTED] wrote: Hi all, I am new to OOP, but I know CFML pretty well. I started playing with ColdFusion Components a couple of years ago and I never found a good reason to use the This scope. Am I missing anything? Thanks. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
That's half of it. The other half is the reverse: the environment shouldn't know anything about the object's internals. That way both environment and implementation can change, but as long as the interface doesn't there isn't a problem. Yes, attribute protection (as you call it) is missing from CFCs, but that doesn't really relate to 'this' at all, since you can overwrite a method with a variable (or another method) dynamically at any time. Which can lead to some subtle bugs, and also some very interesting capabilities, such as runtime injection of method wrappers for various things (logging, security, etc.). cheers, barneyb On 8/29/05, John Farrar [EMAIL PROTECTED] wrote: Barney, Wait, isn't encapsulation the concept that the bean doesn't know anything about the outside world? Could you give me your definition... it seems to me it would be breaking something else... or I was given the wrong definition on that one. (And the bigger issue with this is CFC's don't have protection of attributes, thus I suggest they are only dangerous if the attribute could have a method by the same name. Isn't this also correct?) Thanks, John Farrar -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
Interfaces dictate behaviour, and state is not a behaviour. The ability to change and/or recall state, however, is a behaviour. So that's the reason. But I think what you're getting at is something slightly different. What an object stores is part of it's implementation. You, as the user of an object, should have no idea (nor any reason to care) what information is intrinsic to an object. Age is a perfect example, because if you call user.getAge(), how often do you think you're going to get the value of an instance variable returned? Probably not very often, because the age will be computed from a dateOfBirth field. So you don't care about the internal data, you only care that you can retrieve the user's age. I.e. the object has a behaviour that will give you the info you want, not that you know what state the object has. cheers, barneyb On 8/29/05, John Farrar [EMAIL PROTECTED] wrote: OK... maybe this would help me. If you have protected attributes, then why is an attribute not an interface but a method is? (And if you could control the input type and output type of a getter/setter for an attribute, would it meet the standard of a correct interface then?) John -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
If I changed the DB from english to metric, there's no reason that my application should change, only the objects that actually deal with data from the DB need to care (because they can convert it back to metric and let the application run unmodified. The application very likely will care, but there is no need for it to care based on when the DB changes. Rather, the application should be isolated from the change, or at least given time to evolve, rather than forcing an absolute paradigm shift. That's why I suggested deprecating the method, and adding two methods, one for each side of the shift. That'd help the application switch to metric at it's leisure, though it will have to switch eventually. At the very least, the application will have to switch to an explicit gas left in gallons call, rather than the ambigious gas left call, which is enough, because it removes ambiguity, even though the app hasn't actually switched to metric. It's a convoluted example, and probably one that isn't particularly common (since any app written these days should be written in metric to being with, and let the UI/localization code with the conversion), but it does illustrate the point of how an entirely encapsulated interface can save you lots of hassles. It also illustrates how interfaces have to be allowed to evolve over time. The hope is that they don't, but that's about as realistic as expecting every person in a democracy to vote in every election. And yes, if I understand your post correct, there will only ever be one attribute, it's value will just shift by a factor of 3.8 or so at some point. The application shouldn't have to care about the shift, though it should evolve to avoid any ambiguity over the point. cheers, barneyb On 8/29/05, John Farrar [EMAIL PROTECTED] wrote: Well... I see the point (perspective at least). If but like the gas scenario in last post. The lines are never perfectly ignorant... or your code would have no idea what method to call and what it returns. So like when you change from English to Metric... there is an issue. (Or were you saying there should be two methods rather than two attributes?) -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Lines Between TO, Bean and BO?
It depends. (duck and cover ;) I almost never use TOs, prefering simple structs. You don't get the immutability of a TO with a struct, but since the data is a copy of the real data, anything that changes the data is only going to screw itself up. It's a lot easier (and somewhat more performant) than using a full-on object, and I've never run into a problem with it. Bean/BO is little less clear. I don't make a distinction. Some of my BOs are nothing more than get/set/validate (where the validation is generated based on the DB schema), and some are masses of composition and business logic methods, including custom validation. But the rest of the system doesn't care, a BO is a BO, and it has zero or more business methods. Having said that, I think your definition of Bean (at least from your email) is a little unclear. What do you use a bean for that you wouldn't use a TO or a BO for (assuming a given entity had all three). cheers, barneyb On 8/26/05, Brian Kotek [EMAIL PROTECTED] wrote: A question here for the list. I'd like to know at what points you decide to create a full business object vs. creating a Bean vs. creating a transfer object. And don't just say it depends! Just kidding...say it depends but try to explain what you think it depends on. For example, if an entity isn't that complex, I've found that what I call a Bean can handle all three chores. On one hand creating a TO for a fairly simple Bean seems like overkill, and creating a full business object behind a Bean can also seem like overkill if the BO isn't doing much that the Bean is already doing, such as validating itself and holding instance data. In fact, in most cases, unless the bean is really heavy (maybe compositing a complex Validation object within itself) I have little use for transfer objects. Of course if the entity requires complex business logic then a full-fledged business object is in order, there is no place for that kind of logic in a Bean. I suppose the real point is that a good manager or service object is necessary to hide these variations. As long as the UI is going through a manager, you can change how the underlying model is doing things fairly easily. What does everyone else think? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Lines Between TO, Bean and BO?
Ok, that makes sense. I don't use beans, by those definitions, just TOs (structs) and BOs. TOs go out of the application (to the UI and such), and can only be created by BOs. BOs are used within the application (for business logic, passing to DAOs, etc). I don't know that it's the best way, but it does seem to be a good way, and works well for me. cheers, barneyb On 8/26/05, Brian Kotek [EMAIL PROTECTED] wrote: You may well be right Barney. It is fully possible that my labels and/or concepts are out of whack. I'll take a crack at it: To me a TO is basically a simple struct, but possibly wrapped up as a CFC with public instance data. This would be just for moving data around with no other functionality. A Business Object represents a real-world entity in the model. This is where the real business logic happens, and may involve composition of other objects (maybe many), lots of coding by intention (meaning sergeant and private methods), and in general doing the work of the model. A Bean, as I see it, is a sort of intermediary. It is like a TO except that it has getters and setters, and very likely (but not always) the setters are private so the data can't be changed once the Bean is created. It keeps instance data, and it also validates itself (with potentially complex validation). But that is all. Any real business logic would be performed by a BO, and a Bean would be passed into the BO (or the DAO for example) to move the data around. So, assuming that made any sense, what do you think? And am I way off in my impression of what each of these are? Thanks for your time as always. Brian -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] Lines Between TO, Bean and BO?
The only beans I know of are JavaBean and Enterprise JavaBean. The former is a set of rules for objects; in particular a zero-argument constructor, and get/set/is methods for all properties. The later is obviously of no real use to this thread. ;) On 8/26/05, Brian Kotek [EMAIL PROTECTED] wrote: In fact, while I'm at it, does anyone know where a good definition of a Bean is located, so that I can make sure that my vocabulary is in line with the accepted standard? Thx. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] regEx help
You don't need a regex, just a pair of simple replaces will do it. And actually, htmlEditFormat() would do it just as easily, and catch , , and too, though I don't think it'll do the apostrophe. cheers, barneyb On 8/24/05, Ung, Seng [EMAIL PROTECTED] wrote: Help string=The Sound of A D's how does regex works to ReReplace the string to the following? string=The Sound of A amps; Dapos;s thanks Seng -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] regEx help
how about xmlFormat(string_1), then? Though really, who cares if it's one line or two? On 8/24/05, Ung, Seng [EMAIL PROTECTED] wrote: btw: the outcome is a XML format -Original Message- From: Ung, Seng Sent: Wednesday, August 24, 2005 10:02 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] regEx help Barney: here what I got cfset string_1=REReplace(The Sound. of A M's,,amps;,ALL) cfset string_2=REReplace(string_1,',apos;,ALL) What I am hoping for is a 1 liner will detected ' and translate it to amps; apos; Can it be done? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] regEx help
I wish. But sadly it's still only Wednesday. On 8/24/05, Nathan Strutz [EMAIL PROTECTED] wrote: haha, Nathan jinx wow is it friday or something in here? -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] DAO, Gateway, and Manager model for Fusebox and Mach-II
To pick a nit, I think a better definition comes from the other direction. DAO's implement persistence operations for single entities, while gateways provide access to recordsets. It's not uncommon at all to have a gateway method that is designed to return a single row (getUserById, for example), but the distinguishing factor is that you're getting a recordset, not a bean or TO. It's also not uncommon for a DAO to deal with multiple records in multiple tables; the distinguishing factor is that it's doing a single persistance operation for a single business entity. cheers, barneyb On 8/23/05, Nando [EMAIL PROTECTED] wrote: From the general tone of your question, it sounds like you have a bit of studying to do. Maybe a more specific question would also help those of us on the list that might be able to answer. Generally speaking, DAO stands for Data Access Object, and a DAO typically functions to store and retrieve single records from a database (or datastore). A Gateway usually works to fetch multiple records from a datastore. Suggestion Go to: http://clearsoftware.net/client/index.cfm open the search box and type in DAO. Scroll down to the bottom of the results and read Joe's articles on DAO's. Excellent. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] DAO, Gateway, and Manager model for Fusebox and Mach-II
At least in my architecture, gateways are accessible in a lot of places where DAOs aren't. Both types are singletons, but the gateways are retrieved from a globally accessible factory, while DAOs are instantiated and kept within the corresponding bean factory/manager. Gateways are needed by the service objects, at the very least, and I almost always allow gateways to be accessible from the UI as well, so they're part of the app's API, along with the service objects. It makes the API use more components, but it makes a nice separation between business actions and simple retrieval of recordsets, so I'd say the API ends up easier to use. So two very different types of objects that both happen to have the same purpose (encapsulating data access), with with very different reasons for doing so. And to answer your question, yes, it is worth it, because it keeps the architecture intact, no matter the size of the app. cheers, barneyb On 8/23/05, Peter Hardy [EMAIL PROTECTED] wrote: If you're Gateway only includes a GetById() and a GetAll() method is it really worth seperating this out into a seperate Gateway component? I generally just shove it in my Dao and forget about the distinction. I know it probably comes down to personal preference but do you think this is a bad habit to get into? Cheers, Pete (aka lad4bear) -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] DAO, Gateway, and Manager model for Fusebox and Mach-II
Gateway's should be stateless singletons, so you only ever need a single instance that everything uses concurrently. Just make sure you're var-scoping everything correctly or weird bugs will crop up under load. You could make application-scope instances, but I prefer a application-scope factory for getting gateway instances, and letting that factory deal with the caching. And by should, I mean there's rarely a reason not to do it that way, while there are some nice benefits, particularly eliminating the need to instantiate more than one instance. cheers, barneyb On 8/23/05, Nando [EMAIL PROTECTED] wrote: I've found it best to keep them separate. Functionally they tend to sit in different areas within a model. That allows me to cache my gateways in a manager for front end operations for instance, or keep them lightweight and nimble for rapid instantiation. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
Re: [CFCDev] DAO, Gateway, and Manager model for Fusebox and Mach-II
Beans (or Business Objects) are representations of real entities in your application's domain. In a shopping application, you'd have products, customers, orders, etc., each corresponding to a BO. bean can mean several other things as well, but in this context, this is the usual definition. Managers are typically objects whose sole purpose is to manage BOs (surprise!). So they are the object you ask for a new BO of whatever type, or ask to persist a BO to the backing data store. Managers are a specialization of Factories, which are just for creating instances of objects. cheers, barneyb On 8/23/05, wolf2k5 [EMAIL PROTECTED] wrote: On 8/23/05, Nando [EMAIL PROTECTED] wrote: From the general tone of your question, it sounds like you have a bit of studying to do. Yes, you are right, I am new to this OOP stuff and I have a lot to study and I am doing it right now. I am finding the OOP terminology a bit confusing for a newbie. I am still not sure if the DAO, Gateway, and Manager approach for an OOP application and the DAO, Bean and Gateway one are the same thing, that would mean that a Manager and a Bean are the same thing. If not, what is the difference? Thanks a lot. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. -- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
