nk4um

Greetings Menzo,

I had not forgotten who first explained to me how to include a javascript library consisting of more than one file and which examples he used ;-). TIBCO GI was and is on the list.

Regards,
Tom

Hi Tom,

You might consider to also include TIBCO General Interface (http://developer.tibco.com/gi/default.jsp) in your comparison. GI is quite a bit older then most of the other frameworks, so in their case JSON is an afterthought instead of XML ;-) JSON support was, if I remember correctly, in version 3.6.

In the past I also used Backbase (http://www.backbase.com/), which is also one of the older frameworks and more XML oriented (JSON support was also added at some time). However, I lost track as they broke backwards compatibility with version 4. Their community edition also got more and more constrained on which type of server you''re allowed to use.

Menzo

Randy,

You lost me halfway through your explanation. Probably due to my limited Java knowledge (enough to do ''ugly hacks'', not enough to develop the ''better hacks'' ... I''m a DBA/System Administrator/DoItYourSelf man, Python is more my style :-). What I always feel when using a javascript layer to do my gui is that I''m betraying the NetKernel idea and that I should dig deeper into the ''native'' presentation layers. However, I never get the professional look that those libraries provide in minutes. I then soothe myself by thinking that I''m just adding polish on a roc(k) solid base.

Having confessed :-) ... of course I''ll share the results. Should be in by the end of next week.

Regards,
Tom

Tom,

It is great news that you are carefully experimenting with different JavaScript technologies for the front-end GUI for your application. The results of this work, if you are willing to share them, will benefit everyone.

It sounds like your design is similar to what I use with NetKernel. I use an "integration layer" that provides standardized information resources (independent of source); this returns HDS for representations (sometimes I use custom Java objects). The next layer provides "domain services" and operates on domain information (such as adding / modifying state or returning a representation of composed / aggregated / summarized / etc. information). I usually return HDS from this layer also. On top of this I have one or more peer layers that perform transport and presentation adaption. This layer consume HDS from the "domain" layer and delivers JSON, XML, XHTML, JMS message, SMTP email message, etc. (I use test-driven development, so each layer has its own set of XUnit tests.)

Once you finish your experimentation I''ll consider adding an Ajax front end to an application I am writing as a NetKernel 4 example - a NetKernel version of Delicious.

Looking forward to learning about your discoveries!

-- Randy

Hello Randy,

Thank you for your reaction. How I''m working at the moment is as follows :
- I have a "stock" application. Originally it was NetKernel native. But although I understand how to make them technically, I am lousy in making gui''s.
- I''ve created a raw (no formatting) equivalent for all my server requests, returning JSON / XML (I provide both).
- I''m testing one javascript framework after another, every time creating a new version of my stock application
- Points are given for speed of adaptation (mine), speed of the resulting code, ease of creating a ''profesionally looking''-application

I added qooxdoo on the list (after ExtJS, which should be finished by the end of this week - strange, ExtJS basically has the same license policy as NetKernel). My observation on JSON is based on what I find in all those frameworks. XML is always provided, but often as an ''afterthought'' and always with the remark that JSON is a lot more efficient. I can''t say myself if that is true or not, but originally I only intended a raw XML interface to the server ... so I''m slowly converting.

Regards,
Tom

Tom,

Very interesting post. Thank you.

There are several bits of information that we need to consider. First is your comment that JSON is gaining ground as the exchange format for Ajax applications. If this happens, then it will probably gain ground in other usage areas. Second, I agree with you that the form of the container should not change based on the content. There may be subtleties that I am unaware of, but I think we need to review how NetKernel 4 is handling JSON.

An aside - I''ve been tracking http://qooxdoo.org/ - have you looked at that library?

Thank you -- Randy
[/url]

Greetings all,

No question, just sharing some experience.

I am not a great designer of interfaces. Never was. So I use javascript libraries to do that job for me. That works fine (the integration with NetKernel that is). I''ve tried Dojo (too slow), Prototype (not enough eyecandy) and am exploring ExtJS (looks promising, but so did the others :-) at the moment.

All these libraries have ways to handle requests which I of course handle the NetKernel way. Usually XML response is allowed, but JSON is quickly gaining ground and - pretty important in open source efforts - is often the first / best supported / best documented option.

No problem however, JSONFromXML does the job.
But maybe a bit too well.
Conside the typical database response :

<RESULTS>   <ROW> ... first row data ... </ROW>   <ROW> ... second row data ... </ROW> </RESULTS>

Gets translated to

{"results": {     "row": [{       ... first row data ...     },{       ... second row data ...     }] }}

And, amazing coincidence, all these javascript libraries have a concept of a (data)store that can handle this. Database paging with lazy loading, scrolling grids, you name it, it can be done ...

Except when the resultset contains only one row :

<RESULTS>   <ROW> ... first row data ... </ROW> </RESULTS>

This gets translated (or should I say transrepted ;-) to
Gets translated to

{"results": {     "row": {      ... first row data ...     } }}

Do you spot the difference ? I didn''t, not at first. But why the hell did all those frameworks suddenly stop loading my data ? Before I give the solution, note that the above IS the correct - and most efficient - translation ...

The problem is that "row" is no longer a table. What is missing is []. And what do you know, all the frameworks expect a JSON table !

Ugly hack
I made a small change to the JSONObject.java source which solves the problem for me. It is ugly (meaning it is not dynamic), but if it does the trick for me, maybe it will for you.

public JSONObject accumulate(String key, Object value)             throws JSONException {         testValidity(value);         Object o = opt(key);         if (o == null) {             if (key.equals("row")) {                 put(key, new JSONArray().put(value));              }              else {                            put(key, value);             }                } else if (o instanceof JSONArray) {             ((JSONArray)o).put(value);         } else {             put(key, new JSONArray().put(o).put(value));         }         return this;     }

And now the translation is :

{"results": {     "row": [{      ... first row data ...     }] }}

Better Hack
I''m convinced that a good solution sits on the server (NetKernel) end, not on the javascript library side. A dynamic way to force the translator to handle certain xml tags slightly differently (but still within the JSON rules). Sort of like the array intervention in JSONToXML. Anyone up to the challenge ?

Enjoy,
Tom