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.
-----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/
