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