1

Running Dani's profile as an example I get the JSON back containing:

"education":[
 {
  "key":"education",
  "value":"B.S. Computer Science",
  "organization":"Hofstra University",
  "start":"September 2000",
  "end":"December 2005",
  "description":"I majored in Computer Science and minored in Business Computer Information Systems. I was in Upsilon Pi Epsilon, the Computer Science Honor Society run by the ACM and IEEE. I TA'ed multiple Computer Science courses and also worked as a private tutor. I almost double-minored in chemistry and subsequently won an award from the American Chemical Society. I founded DaniWeb my sophomore year of college after getting frustrated that I was one of the few department tutors and there was no where available for me to get help myself. Upon its success, I finished my last year and a half of school taking part-time night courses and focusing on DaniWeb fulltime, ultimately completing my 4-year degree in 5.5 years with a business to go into upon graduation.",
  "id":"3"
 },

Should it not be:

"education":[
 {
  "DEGREE":"education",
  "SCHOOL":"B.S. Computer Science",
  "organization":"Hofstra University",
  "start":"September 2000",
  "end":"December 2005",
  "description":"I majored in Computer Science and minored in Business Computer Information Systems. I was in Upsilon Pi Epsilon, the Computer Science Honor Society run by the ACM and IEEE. I TA'ed multiple Computer Science courses and also worked as a private tutor. I almost double-minored in chemistry and subsequently won an award from the American Chemical Society. I founded DaniWeb my sophomore year of college after getting frustrated that I was one of the few department tutors and there was no where available for me to get help myself. Upon its success, I finished my last year and a half of school taking part-time night courses and focusing on DaniWeb fulltime, ultimately completing my 4-year degree in 5.5 years with a business to go into upon graduation.",
  "id":"3"
 },

This also occurs with experience and portfolio, can't confirm for the other two.

5
Contributors
20
Replies
136
Views
3 Years
Discussion Span
Last Post by diafol
Featured Replies
  • 1
    diafol 3,669   3 Years Ago

    I can see the logic of it, but it does look a little clumsy. Is the "key" superfluous? It seems that the "keys" are just repeats of the parent object names. Or is there more to it? Read More

  • 2

    > thought that by leaving them the way we store them in our own back-end Your back-end implementation shouldn't be exposed. Let app developers make up their own mind. I always prefer strong names. If I want to generalize, it's up to me. Read More

  • 1
    diafol 3,669   3 Years Ago

    I think we saw the 'why', just by looking at the fieldnames, however, is there a good reason for keeping name duplication in the json structure? e.g. "education": [{"key": "education"...}... "portfolio": [{"key": "portfolio"...}... etc. Read More

  • 1

    I prefer clarity over ease of reuse. Read More

  • 1
    Dani 1,638   3 Years Ago

    In this case, you got two upvotes and Mike Askew rep commented that he agrees with you. So there's your posse for ya. That being said, I came up with a compromise that I'm happy with. http://www.daniweb.com/api/members/1 Read More

0

Dani's JSON makes more sense in my opinion. Not everyone who is qualified has a degree. However, based on that, it's the UI that's incorrect ;)

1

I can see the logic of it, but it does look a little clumsy. Is the "key" superfluous? It seems that the "keys" are just repeats of the parent object names. Or is there more to it?

0

Never noticed the education bit actually, good spot.

Either way the value is still not right

0

So basically what's going on is, behind the scenes, every item in a member's CV has the following fields: key, value, organization, start, end, description

The key is what the row represents: experience, education, portfolio, etc. The value represents the Position for experience, the Degree for education, the Project for portfolio, etc. The organization column represents the Company for experience, the School for education, etc.

I was going back and forth on whether I should rename the properties based on what our own UI names them, but I thought that by leaving them the way we store them in our own back-end, it would let an app developer do what we do, which is create one object with these 6 properties to handle any type of row, and then manipulate your own UI the same way we do. What do you think?

2

thought that by leaving them the way we store them in our own back-end

Your back-end implementation shouldn't be exposed. Let app developers make up their own mind. I always prefer strong names. If I want to generalize, it's up to me.

Votes + Comments
Agreed
1

I think we saw the 'why', just by looking at the fieldnames, however, is there a good reason for keeping name duplication in the json structure?

e.g.

"education":
    [{"key": "education"...}...
"portfolio":
    [{"key": "portfolio"...}...

etc.

Edited by diafol

0

I got rid of the key property. However, do you think I should be renaming the rest of the properties? It's my thoughts that it would actually make it harder for developers since they will no longer be able to use the same object to handle all row types. What do you guys think?

0

Hang on a minute! We're talking about these, right?

  "curriculum_vitae":{
    "summary_raw":"...",
    "summary_parsed":"...",

    "experience":[
     {
      "value":"...",
      "organization":"...",
      "start":"...",
      "description":"...",
      "id":"1"
     }
    ],
    "education":[
     {
      "value":"...",
      "organization":"...",
      "start":"...",
      "end":"...",
      "description":"...",
      "id":"3"
     },
    ],
    "portfolio":[
     {
      "value":"...",
      "organization":"...",
      "start":"...",
      "description":"...",
      "uri":"...",
      "id":"4"
     }
    ]
   },

We seem to have: value; organization; start; end; description; uri; id

I'm not so sure that these fields need to have separate names just because they describe separate items. The name "value" is a bit obscure, but the others seem to make sense.

If I was using the data in a reusable template, then I think having consistent naming would help. My 2p. However, I'm not one to argue with my betters. :)

0

If I was using the data in a reusable template, then I think having consistent naming would help.

That's what I've been saying all along!!!!

However, people in this thread seem to think that this is "opening up my backend" and that it is a very bad thing that it is not consistent with the UI.

0

people in this thread

That's only me. When I give an opinion you usually ask where my posse is before considering a change ;)

0

"opening up my backend"

Oooff. I'd also advise against that.

I was thinking "title" myself. Yep I'm happy with that.

Edited by diafol

0

I tried, but unfortunately doing so is simply beyond the limitations of the system as I am in New York.

0

As a UK resident, I find the 'ize' or 'ization' perfectly acceptable. I think the importance of their use lies with consistency. English is such a mongrel language that rules of spelling went out of the window long before the Dutch started mangling everything with their new fangled printing presses (sorry Prit). English no longer has a distinct way of alerting the reader to hard and soft 's' sounds, unlike Italian say, which has 's' and 'ss' for 'z' and 's', respectively.

Spellings I don't find so palatable are things like 'analyze' for 'analyse'. AFAIC the stem is analysis. Anyway my OCD is starting to rear its ugly head...

Edited by diafol

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.