"but it certainly seems to have you pointing fingers and yelling at anything you can to apportion blame."
>From my experience, people who do this usually do it to justify themselves to their employer, or who ever it is that they are complaining to try and big note them selves as to say "this is crap. my system is soo much better so I am going to use mine" rather then working with what's there, developing a solution to the problem at hand and getting on with the job. Personally I have seen allot of problems being posted in cfaussie, and most of them are problems that don't need to be problems cause people try to be tricky make problems more involved than they need to be. As they say, the most effective solutions are usually the simplest. So, here is my take on OOP Although Coldfusion is on a JAVA base, it is JAVA that is an OOP language, where as Coldfusion is not. Macromedia developed Coldfusion as a <TAG> based language so that from a development perspective, all the grunt happened behind the scenes, and we, as developers didn't have to worry about that side of things as could concentrate on doing what we do, which is develop. I still don't know why this OOP thread keeps coming up when ColdFusion is NOT an OOP language. Although you may implement some OOP style of developing your applications, why do people still harp about Coldfusion not doing things that OOP languages can do. Well here is your answer. Coldfusion doesn't do allot of things accustom to OOP development cause it isn't an OOP language! Simple I know, but that's the truth of it. As many of the JAVA guy on here have said, if your gonna try develop in OOP, go learn OOP, but in the end you wont be able to develop Coldfusion applications in OOP, but you will be able to use the fundamentals of OOP and its structure to help better define your application frameworks and help you more understand application workflows. If you want to develop in OOP, then develop in JAVA or something. Anyway Time to get back to work -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Spike Sent: Thursday, July 29, 2004 10:28 AM To: CFAussie Mailing List Subject: [cfaussie] Re: the big oo train, on the right track? One of the main difficulties in what you're asking for is that it's trying to be all things to all people. If that's the required end result then there's going to have to be a massive amount of R&D done to get it to the point where it does even half of what is being asked. No doubt you're aware of <cfform> and the related family of tags, but I bet you don't use them. Why not? Well almost certainly because they aren't flexible enough for the specific requirements of your application. As evidenced by reading Tim Buntel's blog, Macromedia have done a lot of work with the forms, but I bet there will be situations where you still won't want to use them. If the solution was as simple as you are proclaiming, it would already have been done. That hasn't happened, so the solution must be a bit harder than that. Macromedia has produced a solution to part of the problem with Flex and guess what their market research tells them... It is worth a hell of a lot more than CFMX to anyone who really wants it. Anyone who doesn't want to pay up is welcome to build equivalent functionality themselves. The fact that you are working on a project that is a mess doesn't change any of the above, but it certainly seems to have you pointing fingers and yelling at anything you can to apportion blame. The bottom line is that no matter how much you dislike it, the project will not get better by complaining about what Macromedia should or shouldn't be doing. It may get better if you try to come up with a salvage plan that is actually workable. my 2 cents Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Scott Barnes >Sent: Wednesday, July 28, 2004 4:14 PM >To: CFAussie Mailing List >Subject: [cfaussie] Re: the big oo train, on the right track? > >> you have it your way, i'll have it my way... >> >> Maybe fun was not the right word to use, but I'm sure you >understood the underlying meaning of it. >> > >So if a UI framework were to be given as a default, with skinning >capabilities? you'd not use it? instead roll your own. If so Why? > >Scott > > >> -----Original Message----- >> From: Scott Barnes [mailto:[EMAIL PROTECTED] >> Sent: Thursday, 29 July 2004 10:03 AM >> To: CFAussie Mailing List >> Subject: [cfaussie] Re: the big oo train, on the right track? >> >> >> >> Taco Fleur wrote: >> >> >> >>>Scott, how would we make any money if we have an application >that does all this for us already? Where would the fun be, >trying to discover a new process of doing things better? >> >> >> Heh. Where would be the fun? how about i explain that to >management why >> >> a project is taking so long, because "I wanted to have fun". >> >> Get a UI up in front of a client/management and you can have >all the fun >> >> you want in the world. Besides, products like FLEX are >actually fun to >> >> use, you can do exactly more so in FLEX then you can in HTML. >> >> >> Its like saying: >> >> "i'd rather not use windows xp user interface as its not as fun as >> >> typing long winded commands in a unix blackscreen" >> >> Enter LongHorn - XAML is the answer to the same question >above, we need >> >> a XML approach to Client-Development. >> >> >> You just dont want the framework built in because you never >wrote it :) >> >> .. i too dislike off the shelf frameworks, but hey at this >point, i'll >> >> give my left nut for one. Not only that, its typically redundent >> >> process, you only need dynamic UI for "websites" for >applications, its >> >> more on the principal logic behind the scenes and less on >the UI (UI is >> >> more just Win Forms etc). >> >> Don't get me started man ;D >> >> Scott >> >> >> >> >> >> >>>I hope Flex or any other framework is never included with CF server. >>> >> >> >>>mi 2 pesetas >>> >> >> >>>-----Original Message----- >>>From: Scott Barnes [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, 29 July 2004 9:16 AM >>>To: CFAussie Mailing List >>>Subject: [cfaussie] Re: the big oo train, on the right track? >>> >> >> >> >>>XML is ok. >>> >> >> >>>Half the time i feel like we as CFMX developers are making up our own >>> >> >> >>>language? doesn't that strike anyone else as an odd thing to >do? In that >>> >> >> >>> it seems to be a common ask: >>> >> >> >>>"Use XML to build UI" >>> >> >> >>>Whether it be using Custom tags with your own namespace, pure XML or >>> >> >> >>>products like FLEX (which isn't exactly an easy thing to get in the >>> >> >> >>>door, price wise). >>> >> >> >>>BlackStone is supposed to solve some problems by giving you a reduced >>> >> >> >>>version of blackstone and achieve the above request in a hybrid way. >>> >> >> >>>More to the point, its a big ask, and its really not that hard to >>> >> >> >>>accomplish (we have done so much in so little time using >CFIMPORT, CFC >>> >> >> >>>and DHTML). Granted its DHTML, but the UI is going to be >done a lot faster. >>> >> >> >>>Point is, surely we aren't the only ones to do this and why the hell >>> >> >> >>>doesn't someone at MM get off their ass and put that feature >into CFMX, >>> >> >> >>>and watch the sales go higher. >>> >> >> >>>Or why not combine FLEX & CFMX. FFS tired of this bullshit, >where most >>> >> >> >>>of our OOP is done UI side rather then CFMX Model end. >>> >> >> >>>Scott >>>P.S >>>Sorry for hijacking the thread. >>> >> >> >> >> >>>Taco Fleur wrote: >>> >> >> >> >>>>This is how I currently do it in several places. >>>> >>> >> >> >>>>have one XML file containing general objects like; >>>>- firstName >>>>- lastName >>>>- dateOfBirth >>>> >>> >> >> >>>>and define the set properties for these objects, i.e. >maximumLength, minimumLength, range etc. and then use these >for all applications. >>>> >>> >> >> >>>>Then I have a XML file in each application that references >to those objects and puts them in a form, example; >>>> >>> >> >> >>>><form name="frmSignUp"> >>>> <object name="firstName"><required>true</required></object> >>>> <object name="dateOfBirth"><required>true</required></object> >>>></form> >>>> >> >>>><form name="frmEmployee"> >>>> <object name="dateOfBirth"><required>true</required></object> >>>></form> >>>> >> >>>>with this info you can create client side validation and >server side, there is bit more to it then what I mentioned >above, but thats the basic idea behind it. >>>> >>> >> >> >> >>>>>Is it o.k to make a cfc create the form element for you? >>>> >> >> >>>>I can't see a reason why not? Thats a little experiment I >worked on a couple of weeks ago, I used the >getMetaData(object) function to see what the cfc expects and >then create the form and data validation, which is another >cool way of doing it, but Sean Corfield suggested that its >better to stick with the XML files, haven't decided yet >myself, maybe a combination of both, for example, let the CFCs >dictate stuff like; required (true/false) extra error checking etc. >>>> >>> >> >> >> >>>>-----Original Message----- >>>>From: Gareth Edwards [mailto:[EMAIL PROTECTED] >>>>Sent: Thursday, 29 July 2004 8:16 AM >>>>To: CFAussie Mailing List >>>>Subject: [cfaussie] RE: the big oo train, on the right track? >>>> >>> >> >> >> >>>>We are currently going down the track of building custom >tag library's >>>> >>> >> >> >>>>Is it o.k to make a cfc create the form element for you? >>>> >>> >> >> >>>>Would the xml file contain data such as status bar >information and clientside validation? >>>> >>> >> >> >>>>Gareth. >>>> >>> >> >> >>>>-----Original Message----- >>>>From: Jamie Lawrence Jenner [mailto:[EMAIL PROTECTED] >>>>Sent: Wednesday, 28 July 2004 10:26 PM >>>>To: CFAussie Mailing List >>>>Subject: [cfaussie] RE: the big oo train, on the right track? >>>> >>> >> >> >> >>>>taco said >>>> >>> >> >> >>>>>Centralized data validation is certainly a good idea, but >I would store the >>>>>meta data for the fields in a XML file instead of defining >it by a prefix. >>>> >> >> >>>>the validation obj will be accessible by all forms across >many sites. >>>> >>> >> >> >> >>>>So do you mean that each form from each site should also pass an xml >>>>string detailing which field needs what validation? If not, >what do you >>>>mean exactly? >>>> >>> >> >> >>>>if i can do without the prefix it will make my life easier >>>> >>> >> >> >> >>>>>I don't think all your objects should go into one CFC, the >error.cfc >>>> >> >>>>should >>>> >>> >> >> >>>>>handle all errors and not just those for your form, so >that should be a >>>> >> >>>>CFC >>>> >>> >> >> >>>>>on its own IMHO >>>> >> >> >>>>It will, but ive only just started out! I am hoping to have >a global error >>>>object, form object, validation object, and ive also >thought about doing a >>>>global DAO. any others i could implement? your views >>>> >>> >> >> >>>>greg said >>>> >>> >> >> >>>>>My understanding is that there is still some way to go >>>>>before you could even start considering cfml an OO language >>>> >> >> >> >>>>oh yes, i agree, but i thought that there may have been >more emphasis on >>>>teaching the benefits of oop and what can be done in cf so >far (thus i >>>>could have concentrated on these methods from the start). joined the >>>>various lists you suggested, tuned brain to sponge mode and >off i go! >>>> >>> >> >> >>>>cheers for the info guys >>>> >>> >> >> >>>>jamo >>>> >>> >> >> >>>>--- >>>>You are currently subscribed to cfaussie as: [EMAIL PROTECTED] >>>>To unsubscribe send a blank email to >[EMAIL PROTECTED] >>>>Aussie Macromedia Developers: http://lists.daemon.com.au/ >>>> >>> >> >> >>>>--- >>>>You are currently subscribed to cfaussie as: [EMAIL PROTECTED] >>>>To unsubscribe send a blank email to >[EMAIL PROTECTED] >>>>Aussie Macromedia Developers: http://lists.daemon.com.au/ >>>> >>> >> >> >>>>Register now for the 3rd National Conference on Tourism >Futures, being held in Townsville, North Queensland 4-7 August >- www.tq.com.au/tfconf >>>> >>> >> >> >> >> >>>--- >>>You are currently subscribed to cfaussie as: [EMAIL PROTECTED] >>>To unsubscribe send a blank email to >[EMAIL PROTECTED] >>>Aussie Macromedia Developers: http://lists.daemon.com.au/ >>> >> >> >>>Register now for the 3rd National Conference on Tourism >Futures, being held in Townsville, North Queensland 4-7 August >- www.tq.com.au/tfconf >>> >> >> >> >> >> --- >> You are currently subscribed to cfaussie as: [EMAIL PROTECTED] >> To unsubscribe send a blank email to >[EMAIL PROTECTED] >> Aussie Macromedia Developers: http://lists.daemon.com.au/ >> >> Register now for the 3rd National Conference on Tourism >Futures, being held in Townsville, North Queensland 4-7 August >- www.tq.com.au/tfconf >> >> > >--- >You are currently subscribed to cfaussie as: [EMAIL PROTECTED] >To unsubscribe send a blank email to >[EMAIL PROTECTED] >Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
