Data structure choice

[Adrien Lapointe]

I am building a simple jsp page where I have list of items that have a title, a description and an image. I am trying to make it easy for non-programmer to edit the list (and make it generally more readable). My thoughts are that I could write a JSON or YAML file that is then used by the jsp file to display the list.

Are either formats a good idea, or would there be something better? (Note: it is such a small application that I think a database might be too cumbersome).

[Marco Ehrentreich]

Hi Adrien,

in my opinion it's a matter of taste and the tooling you have available. Obviously data formats like JSON or YAML are less verbose than XML and should be easier to understand and read by non-technical folks. Despite that fact I personally still often prefer XML over the others because with the right tooling (for example IntelliJ IDEA) it gives me excellent tool support like auto-completion and data validation (structure and content).

But if other people will have to read or edit the said files you probably should simply ask for their opinions ;-)


Marco

[Adrien Lapointe]

Marco Ehrentreich wrote:
But if other people will have to read or edit the said files you probably should simply ask for their opinions ;-)

hehe, it is not always going to be the same people over time. The main characteristic is: non-technical/might be afraid of code looking stuff (xml would fit in that category)

I like how YAML is really easy to figure out. So I think I'll go with it. Any recommendations for a good parser?

[Bear Bibeault]

Why not just go with a simple properties file that Java already knows and loves?

[Adrien Lapointe]

simply because I did not know about them... (I know enough Java to get in trouble I think)

I like that I would not have to find a third party library.

[Bear Bibeault]

[Adrien Lapointe]

hmmm, looking at the properties files format, I cannot seem to find a way to express different instances of an item. For instance, in YAML I would write


title: Permaculture Playing Cards image: images/Group-of-cards.jpg link: http://www.amazon.com/exec/obidos/ASIN/B00GOIXT3M/rs12-20 --- title: World Domination DVD image: images/wdg.jpg link: http://richsoil.com/wd-gardening.jsp

Where the --- indicates a different item.

[William Brogden]

hmmm, looking at the properties files format, I cannot seem to find a way to express different instances of an item.

In properties files that is usually handled with more elaborate names -easy to understand and fairly simple to parsel

Say:

book.1.title = ......
book.1.image = ........
book.1.link = ........
book.2.title = ........

etc

You can see some more examples of properties files with this kind of naming in typical Tomcat conf files

Don't let users edit properties files with MS Word due to the "smart" punctuation

Bill

[Bear Bibeault]

Yes, with properties files, it is a simple key-to-text equivalence. This is perfect for things like translations (or, ahem, properties). You can impose an artificial hierarchy with dots (e.g. name.bill=Bill, name.bear =Bear) but you'd have to do the parsing yourself.

[Edit: I see William beat me to the punch]

If you need complex objects with grouping, you might want to go with something more complex such as yaml or json.

If you just need text substitution, and want to handle it on the client, you might want to think about using JSON with jQuery Ajax and a JavaScript templating engine such as Handlebars.

[Adrien Lapointe]

Bear Bibeault wrote:
If you need complex objects with grouping, you might want to go with something more complex such as yaml or json.

it looks like either would be the way to go. It would be error prone to have the editors manually serialize each item.

Bear Bibeault wrote:
If you just need text substitution, and want to handle it on the client, you might want to think about using JSON with jQuery Ajax and a JavaScript templating engine such as Handlebars.

All I would do is generate an html unordered list from the items in the yaml/json. I am thinking it would be better on the server side, but I am not totally up to date with the current best practices.

<ul> <li class="text-center forumtitle"> <a href="http://www.amazon.com/exec/obidos/ASIN/B00GOIXT3M/rs12-20" rel="nofollow"> <div class="row"> <div class="large-12 columns"> <img ></div> </div> <div class="row"> <div class="large-12 columns"> Permaculture Playing Cards </div> </div> </a> </li> <li class="text-center forumtitle"> <a href="http://richsoil.com/wd-gardening.jsp" rel="nofollow"> <div class="row"> <div class="large-12 columns"> <img ></div> </div> <div class="row"> <div class="large-12 columns"> World Domination DVD </div> </div> </a> </li> </ul>

[Bear Bibeault]

Could easily also be done on the server. There are JSON and yaml parsers available. You could digest the file into a data construct to send to a JSP to use as the template with JSTL and EL.

[Adrien Lapointe]

From a design point of view, would it be more appropriate on the server or client side?

[William Brogden]

Adrien Lapointe wrote:From a design point of view, would it be more appropriate on the server or client side?

I would certainly do all selection on the server for the following reasons:

1. minimum amount of text sent to client
2. flexibility if you need to grow the properties with more data types, for example cds or tapes
3. less dependence on client capabilities

Bill

[Bear Bibeault]

For simplicity, I'd probably go server-side unless there's a good reason not to. But I disagree with William's points (1) and (3). The difference in response size would be marginal at best, and anyone using a browser that can't handle basic JavaScript at this point doesn't deserve to be on the web.

[Adrien Lapointe]

Thanks everybody for your inputs!

Server side it is for this app then.