Hi All,
So as Paul has indicated, I'm the developer of a elasticsearch-head, which is
an admin interface built on top of a RESTful api serving json. In the past I
have worked with an xml -> xslt -> website build.
Sorry for top posting, but I wanted to give an overview opinion rather than
address individual points.
For something like the pmapi, really a RESTful interface is the way to go. If
you accept this, you really don't want a RESTful api serving xslt (or even
serving something that looks good in a browser), it conflates a pure data
interface with presentational features that most consumers of your api are not
interested in.
Now whether you serve XML or JSON is largely a decision based on who your
likely consumers are. There does seem to be a swing away from xml to json, but
I'm a ui engineer - so I might be biased. Certainly languages like java and
python have json support that is as good as xml. JSON - which is a subset of a
programming language - is more suitable for use IN programming languages
(explicit support for boolean/numbers/arrays/maps) - where as xml is really a
generalised document markup langauge. However if your primary goal is a static
website, and you have xslt skills it might be a good choice!
Luckily this is not a choice you must make, as there are frameworks that help
you write RESTful interfaces which will allow the consumer to choose XML or
JSON (literally by appending ?format=xml or ?format=json ).
If you are worried about serving a basic website out of the box, you might
consider starting two services
eg http://localhost:9100 is the website
http://localhost:9101 is the rest api ?
Regarding js development: most front end engineer are going to be looking for a
json api, since json can be directly pushed into rich interface frameworks.
Most api consumers are likely to be java/phython/etc apps who can generally use
xml or json interchangably, or web apps which have javascript available.
----
For an example of the kind of code I'm writing to display tablular data (the
actual table templates are in a kind of third party library)
onDataReady: function(metadata) {
this.metadata = metadata;
this.dataSource = new es.QueryDataSourceInterface( { metadata: metadata,
query: this.query } );
this.resultTable = new es.ui.Table( {
onHeaderClick: this._changeSort_handler,
store: this.dataSource
} );
this.resultTable.appendTo( this.el.find("> .browser-table") );
this.updateResults();
}
not sure if this is illustrative though. As far as xslt vs javascript being
easier to program - it's really not a fair comparison because all you can do
with xslt is produce html, where as for the same effort javascript gives you an
interactive web app. (actually I found xslt always gave me headaches... )
Cheers,
-Ben
----- Original Message -----
From: "Paul Smith" <psmith@xxxxxxxxxx>
To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Cc: pcp@xxxxxxxxxxx, systemtap@xxxxxxxxxxxxxx, "Ben Birch" <bbirch@xxxxxxxxxx>
Sent: Thursday, 24 March, 2011 1:23:29 PM
Subject: Re: [pcp] sketch of possible web pmapi
> On 24/03/2011, at 1:08 PM, Frank Ch. Eigler wrote:
>
>> Hi, Paul -
>>
>>> I'm not sure of the use case of viewing HTML these days with a
>>> browser that doesn't have javascript accessible though.. ?
>>
>> It's not just the browser, but other basic html consumers like web
>> spiders. Plus on browsers too, security worries often mean lockdown
>> of javascript. Plus it's a possible milestone for development: to get
>> something browseable & barely usable, before having to hack on
>> javascript.
>>
>
> Not 100% sure what the web-spider use case is about..? Could you describe
> that more? With regards to disabling javascript on browsers > > in security
> concious environments would render many useful tools for production-like
> activities that would be rendered difficult there.
>
> A very basic javascript pattern to click->drill into is exceedingly simple
> though?
>
>>> yes, different formatters could be selected, although that adds
>>> complexity. XSLT is just.. well... a fairly 'dead' platform these
>>> days. Sure, still used, just if something is being done new here, I
>>> would think worth considering what the state of play of the browsers
>>> support for things?
>>
>> Yeah.
>>
>>> Rendering a HTML table for example when the JSON is actually pretty
>>> readable by a human already (certainly compared with XML).
>>
>> Yes, but a human-readable piece of text isn't clickable in the way
>> an html table with <A>'s in
>
> can be done with css/javascript in the same time or less than XSLT I think.
>
>>
>>> One thing I don't like about embedding XSLT details in the XML
>>> output is that it is still coupling the presentation layer to the
>>> data delivery layer here.
>>
>> I see what you mean, but if we are to generate something
>> html-renderable at some point, we'd have to provide a default
>> presentation layer somehow.
>>
>
> I agree they can't be done in isolation, I just do think they should be
> separated concerns. Ben how much effort was the ES clickable JSON stuff? Is
> there a basic example you can show us from elasticsearch-head?
>
>>> I would have thought much better to design the REST or whatever
>>> mechanism so that it is purely a cross platform data delivery
>>> platform that both simple browsers and other application clients can
>>> interact with.
>>
>> I figured that a more sophisticated use than the dumb html browser
>> would be able to suck out the exact raw xml data by simply skipping
>> the xslt transform. It's this dual-use aspect that seems to make xml
>> attractive here. With JSON, we get reasonably easy human eyeballing,
>> and machine parsing, but not the simple html case. (And with the html
>> rendering, human eyeballing of the raw message may not be that
>> important anyway.) I don't know what the best answer is though.
>>
>
> But you still have to develop the XSLT transform. That's not difficult sure,
> but then it's probably the same as the css/javascript
> 'viewer'. I'm totally happy to volunteer my time on that, actually I'm more
> likely to volunteer Ben's time on that.. :)
>
> At the end of the day though this is driven by the community and what people
> want. I'm just proposing JSON as a nice lightweight simple > output that
> humans and code both like, together with choosing something that has good
> mainstream support now compared with something that is rapidly withering away
> as a common technology of use.
>
> There's a lot more power and potential in the JSON/JavaScript for a 'client'
> application of this REST/whatever API. Charts, drill throughs, tabular views
> with frameworks like jQuery/ExtJS etc.
> Paul
|