Paul,
You touch on an excellent point about using objects. At the heart of it is
your naming convention. We haven't had to worry about naming too much in
the past. Variable names aren't case sensitive and you could always use the
COMPILER_ methods to document the IP and process variables. And the same is
true for the object variables themselves.
When it comes to the properties (or keys as in key:value) it's a different
story. Starting with them being case sensitive. I find a difference in how
I handle this between being able to handle native dot notation and not. The
difference being in v15 I used constants for (not IP vars) key names. You
can still do this in v17 but it's less useful. Looking through some
projects here are the main schemes I use for documenting how an object is
structured.
1) a disk file
Add a folder to Resources and keep templates for various objects there. Or
a single file with templates listed as objects. I do this for large
templates, for objects with lots of default data, for objects I want to be
able to configure for specific instances and for objects defined by some
other service I communicate with. Reading them is fast. Fast enough to use
when loading a form, for example, though obviously I wouldn't do this
inside a loop.
Working with large objects benefits by being able to open them in my text
editor. A line like:
$account_id:=$obj.source.data[2].customer.preferences.account.number
is easier for me when I can be looking at the object. Especially if it's
from some other source (like a API call).
2) in the method header
Perfect for defining keys as parameters.
// MyMethod (object)
// $1: { date: , person_id: , query_str: }
Handy because it pops up in the method editor to remind me what the keys
are.
I also do this to document moderate sized objects returned by a method.
3) initialization or getter methods
$obj:=Address_get_object
where the method initializes the object. This could include reading a disk
file or simply defining the object in code. Frequently I write these to
include an optional param for the key value of a record so it either
returns an empty object or a specific record. With a complementary SAVE
method it's a good way to manage record data.
4) readMe files for each module
Module? Addresses for example. I'd make a folder in Home named ADDRESS and
a method named Address_readMe. This method is where I make notes about
what's important and explain what is supposed to be going on. Like naming
conventions for addresses and the structure of objects.
Like I said at the start a good naming convention is your friend.
Especially in v17. Decide for yourself how you are going to manage key
names. Basically this comes down to camelCase or snake_case. The first
character of the name must be a letter, underscore or $. Decide what $ and
_ mean and be consistent. Avoid "stringly_typing" : using the key to imply
metadata like type, usage etc. These things are totally mutable in an
object. It can seem like a good idea in the short term but will bite you
eventually.
And don't forget you have JSON Validate. Validation schemas can be quite
complex but they don't have to be. Again, you can include a validation
document(s) in the Resources folder to check critical objects against
before using.
I encourage you to just begin working with them. When you find yourself
getting bogged down take a step back because you are likely trying to use
these new tools incorrectly. This is the hardest thing for long time 4D
devs - things we've done a certain way for years can be done with the new
tools a different, easier way.
Objects and collections are the gateway drug to ORDA and your programming
life will never be the same again.
Hope this helps.
On Wed, Oct 3, 2018 at 6:02 AM Paul Dennis via 4D_Tech <[email protected]>
wrote:
> We have not started using objects in our application but I can see how they
> could be useful. However where I am struggling is how we are supposed to
> keep documentation as to the object definition. With database structure you
> can clearly see the definition of the table and fields and these are
> available in the method editor for lookup.
>
> Am I missing something as it seems to me that it would be very easy to get
> in a mess as to definition and contents of an object. Would appreciate
> feedback as to have everyone is managing this. We are using V16 R6.
> Thanks
> Paul
>
>
>
> --
> Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
--
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:[email protected]
**********************************************************************
