Miyako wrote this in another post recently: "Form" based design is a total rethink of how to use variables in forms. Form is an object, and an object is a reference, which drastically reduces the need for pointers.
historically a pointer can only point to tables, fields, variables and arrays. it could have been extended to support object properties and collection members but that would send the wrong message. if you use Form and This, you should never want to use pointers. you should think of using object notation consistently in code and form. this is not to say that "generic" code is discouraged in ORDA. you just think of how to be generic in a different way. it feels counter intuitive coming from classic 4D code, but hard-coding object property paths everywhere is the key to writing generic and reusable code. I think this outlines where we, experienced 4D developers, find ourselves with respect to how, why, and if we want to incorporate ORDA and the whole object-oreiented (or psuedo OO, as some hold) into our work. I hear folks bemoan how hard it is to make ORDA do what they want within the context of a 20 year old app. And why it's not faster than native 4D. And how it's not compatible with SQL. True to all that. And if those elements are crucial to a project it's not a good candidate for ORDA. ORDA is good if you have the time and inclination to learn a new language. Deciding to learn a new language is not a trivial thing. You have to learn the rules, the syntax, the grammar, the ways of doing things specific to that language. This is what ORDA presents. It's even more challenging for experienced devs, I think, because it's right there next to the things we are so familiar with. I'm a big fan of ORDA. And I'm still learning. I've put hours into making something work using Form, collections and references only to come back to it after figuring out something else to discover say 600 lines of code can actually be reduced to 200 because I wasn't fully appreciating how to use references. Learning to use ORDA requires being willing to be a beginner again. The payoff for me is programming with ORDA is faster. It's more dynamic. With respect to a question Miyako was responding to about creating generic code the approach I'm working with is to create objects with common properties that are passed to methods expecting those property names. This doesn't mean you have to re-name your table fields but that you simply construct an object with references to your fields or form vars to properties named as expected. Doing this sort of thing in ORDA is very easy. Doing it in classic 4D isn't. For instance, think about an Invoice. Aside for demos an Invoice will likely involve a number of other tables: Customer, Vendor, items, payments and and so on. In classic 4D we deal with each of those discretely. With ORDA I can build a single object for Invoice which includes references to all of those elements. That can be done on the server and passed to the client - a big efficiency improvement over a network. A single form is therefore able to idsplay all aspects of Invoice from that one object. This is a time sensitive object, of course. But so is loading all that related data into listboxes and form fields. There's also the benefit of being able to write a single calculation method to function on the object whether it's displayed in a form or not. I encourage you to approach ORDA as a new language. There's a lot familiar in it but it really is a different way of thinking about how we do things in 4D. -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
