Pictures Outside Datafile - Calculate Path

[Justin Will via 4D_Tech]

I have a picture field where I have the property checked that tells 4D to store 
the pictures outside the datafile.  The folder/file structure of these pictures 
is not apparent.  Is there a way to calculate where a picture for a particular 
table and field is within that structure?

Thanks
Justin Will
**
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
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

If anyone is a little intimidated about writing JSON validation schema from
scratch (I am) there are some online resources to assist. One that's
particularly easy to use is

https://www.jsonschema.net/

On this site you can paste in a properly formatted JSON and the site will
infer the schema. The result may not be perfect but gives you framework and
an example to work with.

On Thu, Oct 4, 2018 at 7:50 AM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> the recommended way to so this in 4D is to use JSON Validate.
> http://doc.4d.com/4Dv17/4D/17/JSON-Validate.301-3730393.en.html
>

-- 
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
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

as a general rule,
if objects are meant to share a common structure,
the choice should be to use a record, not a single object field.

the closest thing we have to a "class" in 4D is a table, not an object.
http://doc.4d.com/4Dv17/4D/17/Dataclasses.300-3777698.en.html

2018/10/04 23:24、Chip Scheide via 4D_Tech 
<4d_tech@lists.4d.com>のメール:

3 -  You could run a method at shutdown (during development) which
would document/comment every object field. This information
(object.content) could be put into the table's object field(s)
comment(s), and/or into a separate comment only method outlining the
structure of every object field.


**
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
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

the recommended way to so this in 4D is to use JSON Validate.
http://doc.4d.com/4Dv17/4D/17/JSON-Validate.301-3730393.en.html

the structure of an object can be defined using a JSON schema,
a blueprint of a class of object, itself written in JSON.

kind of like what XSD or DTD are to XML.

https://en.wikipedia.org/wiki/XML_Schema_(W3C)
http://doc.4d.com/4Dv15/4D/15.6/DOM-Parse-XML-source.301-3817445.en.html

the type of value is far granular than native JSON,
you can have integer, date, etc.

you can specify value limitations (max, min, between),
use regex or simple wildcards.

it can even have internal cross references (a.k.a. JSON pointers).

essential reading:

https://blog.4d.com/validate-your-json-object/
https://blog.4d.com/a-new-tool-json-validator/
https://blog.4d.com/working-with-json-pointers/

2018/10/04 23:24、Chip Scheide via 4D_Tech 
<4d_tech@lists.4d.com>のメール:

2 - For Objects, I would think that extending this idea to the object
itself would be useful, and valuable.
-- I would think that installing as the first property/value of the
object a definition of the contents of that object would allow for each
object to be 'self documenting' and might even lead to very generic
code. In this way you could blindly access the values in an object. Any
value in the object which is not 'documented' as part of Object.content
effectively would not exist.



**
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
**

Re: Defining and documenting Objects

[Chip Scheide via 4D_Tech]

I do not use objects - not up to a version of 4D that supports them, 
yet.

My thought on handling documentation of an object's contents... this is 
probably worth what you are paying for it...  :)
1 - In every system, or component install a comment only method 
outlining your conventions. This contains all of your system's naming 
conventions, standards etc. This puts the needed information easily 
available to the programmer(s).
I use a method called "__Conventions" as this tends to be the first 
method in the method list.

2 - For Objects, I would think that extending this idea to the object 
itself would be useful, and valuable.
 -- I would think that installing as the first property/value of the 
object a definition of the contents of that object would allow for each 
object to be 'self documenting' and might even lead to very generic 
code. In this way you could blindly access the values in an object. Any 
value in the object which is not 'documented' as part of Object.content 
effectively would not exist.

i.e.
My_Object.Content --> a text(? or whatever floats your boat) value 
containing all of the expected/allowed values in the object.

3 -  You could run a method at shutdown (during development) which 
would document/comment every object field. This information 
(object.content) could be put into the table's object field(s) 
comment(s), and/or into a separate comment only method outlining the 
structure of every object field.

3a - you could wrap the commands to create a new object (not a field) 
that would grab or take as a parameter the object's content) 
Object.content and place it into 1 comment only method for all dynamic 
objects, or into a 'module' specific comment only method (again only 
during development).

Thoughts?

Chip

On Thu, 4 Oct 2018 02:45:36 -0700 (MST), Paul Dennis via 4D_Tech wrote:
> Thanks Kirk, I was afraid you were going to say that. Ive got multiple
> developers on our app all with different habits plus me and I am the worst.
> I have to give this some thought.
> 
> 
> 
> --
> 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:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
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
**

Re: Defining and documenting Objects

[Paul Dennis via 4D_Tech]

Thanks Kirk, I was afraid you were going to say that. Ive got multiple
developers on our app all with different habits plus me and I am the worst.
I have to give this some thought.



--
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:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting

[Douglas Cryer via 4D_Tech]

Paul,

I think I get where you are coming from.  With a defined structure, table and 
field names it is fairly easy to see what the model is.  What you see is pretty 
much what you get.

Introduce objects and you suddenly have hidden data structures.  Indeed those 
data structures can vary by record which makes them even more mysterious.  Not 
dissimilar to the content of BLObs or for that matter large text fields. When I 
first started using object fields I largely confined them to holding program 
managed properties which I documented in the code.  This still accounts for 
more than 80% of our object field use.

Of course with the power and flexibility of object fields and ORDA it would be 
a crying shame to relegate objects to being an entirely developer toy.  They 
can deliver such power and joy to the users.  Managing properties naming and 
existence then becomes the challenge...  Some ideas I have had is:

External manual documentation - Takes a lot of commitment and keeping on top of 
especially with a development team.  A new field slipped in is immediately 
visible and can be questioned and QC'd.  A new property is invisible except in 
data and so bad naming choices may not be caught till testing generates that 
element.

The only way to know all the properties and values in an object is to parse all 
records with the object field.  This could be a costly process, I have not 
tried it on millions of records.  The alternative is what?  Have a common set 
of properties even if empty/null for every record?  I feel that kind of defeats 
the object __

I am still feeling my way with this and recognise it as a potential to be a 
gotcha.  I have found implementing a REST interface to get at data very useful 
for seeing what is in my records.  Objects of course just naturally show their 
entire structure within the returned JSON.  In some systems I have reference 
records that I can just filter for to give me the entire user data structure 
with data examples.

Regards,  Dougie


telekinetix Limited- J. Douglas Cryer
Phone : 01234 761759  Mobile : 07973 675 218
2nd Floor Broadway House, 4-6 The Broadway, Bedford MK40 2TE
Email : jdcr...@telekinetix.com  Web : http://www.telekinetix.com 


 




**
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
**