JSONP

[Adam Howard <ho...@gmail.com>]

I tried making an ajax call using JSONP to the json-viewer yesterday
and I got an exception in DomainResourceHelper.readQueryStringAsMap.
It seems that all requests try to read the full query string into a
JsonRepresentation. I know this is used when needing to pass a json
argument to a GET request like
http://localhost:8180/objects/OID:D/actions/projectsFor?{"rel":"...",
...}. When a JSONP call is made the query string contains some extra
information for the ajax handler like
?callback=jQuery188497262985&_=817483. This blows up the json parsing.

Any ideas on how we might want to solve this?

Two other questions:
1. Should these kinds of things be cross posted in both users and dev
mailing lists. It's an issue I can found while using the system that
will probably require development.

2. What can I do to help get the json-viewer up to RO 1.0.0 spec? I
didn't have any luck with getting iconName added because I don't
understand how image urls are resolved well enough but I'm willing to
work on any other low-hanging fruit. I saw that Dan added a ticket[1]
for 1.0.0 support but no details (which I'm sure are all in his head.)

Thanks.
--
Adam Howard

[1] https://issues.apache.org/jira/browse/ISIS-233

Re: JSONP

[Dan Haywood <da...@haywood-associates.co.uk>]

On 28 June 2012 16:31, Adam Howard <ho...@gmail.com> wrote:

> I tried making an ajax call using JSONP to the json-viewer yesterday
> and I got an exception in DomainResourceHelper.readQueryStringAsMap.
> It seems that all requests try to read the full query string into a
> JsonRepresentation. I know this is used when needing to pass a json
> argument to a GET request like
> http://localhost:8180/objects/OID:D/actions/projectsFor?{"rel":"...",
> ...}. When a JSONP call is made the query string contains some extra
> information for the ajax handler like
> ?callback=jQuery188497262985&_=817483. This blows up the json parsing.
>
> Any ideas on how we might want to solve this?
>

Erm... I guess that the json viewer needs to recognize "callback" as a
custom string.

Sad to say that I'm still a bit fuzzy on how JSONP works (that is, I think
I looked into it and decided I understood it, but have now forgotten what I
read...)




>
> Two other questions:
> 1. Should these kinds of things be cross posted in both users and dev
> mailing lists. It's an issue I can found while using the system that
> will probably require development.
>

We did vote to splits up isis-users and isis-dev a while ago.  My own
personal opinion was that there wasn't much need since mailing list volumes
are still relatively low, but the community voted and that's how it works.

I think the best thing I can say is to use your judgement.  I must admit I
often cross-post to both mailing lists.  This particular posting of yours
is indeed edging more into dev territory, but I think that users would be
interested in knowing that there's this interest in the json viewer.
 Basically: most users of Isis are still likely to be early adopters, and
so there's good crossover potential into dev/contributor land (as you're
demonstrating yourself ;-).



>
> 2. What can I do to help get the json-viewer up to RO 1.0.0 spec? I
> didn't have any luck with getting iconName added because I don't
> understand how image urls are resolved well enough but I'm willing to
> work on any other low-hanging fruit. I saw that Dan added a ticket[1]
> for 1.0.0 support but no details (which I'm sure are all in his head.)
>

Huzzah!  I would very welcome having your help here.

What I was intending to do was start working my way through the spec,
writing new tests as need be, and zapping defunct stuff.  Stef Cascarini
was able to implement the .NET impl pretty much from what's in the spec;
your problem will mostly come from getting familiarity from the internal
APIs.  But the json-viewer itself isn't that large a codebase.  And it
already makes most, if not all, of the actual calls into the runtime
portion of the framework.

The place to write end-to-end tests is in the json-tck project; this
bootstraps the viewer.  More generally, the tck (technology compatibility
kit) project is where I'm hoping that to build a standard set of DOM
objects that allow the different components to check various behaviour.
 Right now, I've got as far as moving those DOM objects out of the
component-specific projects and into the tck-dom so that they can be shared
(though in one or two cases for some of the object stores) they are now
being shared.

At any rate, what I'm trying to say is that when you run the tests in the
json-tck project, then you'll be able to serve up TCK dom objects. If you
find you need more objects or to change them, then make the change.  Do run
a full "mvn clean install" over all of Isis to make sure you've haven't
broken any other tests, though (that's the downside to this approach).

In terms of logistics, now that we have a github clone, seems to me you
could tap away making enhancements as you see.  Then you can either get an
ICLA on file which will allow me to do "git pull" from your clone, or you
can do it the traditional way, ie adding patches as attachments to that
JIRA ISIS-233 and I can apply them.

So; would be great if you had the time.

One last thing: I'm currently just renaming json-viewer to
restfulobjects-viewer.  I'll have that done today.  So don't start this
very second!

Thx
Dan



>
> Thanks.
> --
> Adam Howard
>
> [1] https://issues.apache.org/jira/browse/ISIS-233
>

Re: JSONP

[Dan Haywood <da...@haywood-associates.co.uk>]

On 28 June 2012 16:31, Adam Howard <ho...@gmail.com> wrote:

> I tried making an ajax call using JSONP to the json-viewer yesterday
> and I got an exception in DomainResourceHelper.readQueryStringAsMap.
> It seems that all requests try to read the full query string into a
> JsonRepresentation. I know this is used when needing to pass a json
> argument to a GET request like
> http://localhost:8180/objects/OID:D/actions/projectsFor?{"rel":"...",
> ...}. When a JSONP call is made the query string contains some extra
> information for the ajax handler like
> ?callback=jQuery188497262985&_=817483. This blows up the json parsing.
>
> Any ideas on how we might want to solve this?
>

Erm... I guess that the json viewer needs to recognize "callback" as a
custom string.

Sad to say that I'm still a bit fuzzy on how JSONP works (that is, I think
I looked into it and decided I understood it, but have now forgotten what I
read...)




>
> Two other questions:
> 1. Should these kinds of things be cross posted in both users and dev
> mailing lists. It's an issue I can found while using the system that
> will probably require development.
>

We did vote to splits up isis-users and isis-dev a while ago.  My own
personal opinion was that there wasn't much need since mailing list volumes
are still relatively low, but the community voted and that's how it works.

I think the best thing I can say is to use your judgement.  I must admit I
often cross-post to both mailing lists.  This particular posting of yours
is indeed edging more into dev territory, but I think that users would be
interested in knowing that there's this interest in the json viewer.
 Basically: most users of Isis are still likely to be early adopters, and
so there's good crossover potential into dev/contributor land (as you're
demonstrating yourself ;-).



>
> 2. What can I do to help get the json-viewer up to RO 1.0.0 spec? I
> didn't have any luck with getting iconName added because I don't
> understand how image urls are resolved well enough but I'm willing to
> work on any other low-hanging fruit. I saw that Dan added a ticket[1]
> for 1.0.0 support but no details (which I'm sure are all in his head.)
>

Huzzah!  I would very welcome having your help here.

What I was intending to do was start working my way through the spec,
writing new tests as need be, and zapping defunct stuff.  Stef Cascarini
was able to implement the .NET impl pretty much from what's in the spec;
your problem will mostly come from getting familiarity from the internal
APIs.  But the json-viewer itself isn't that large a codebase.  And it
already makes most, if not all, of the actual calls into the runtime
portion of the framework.

The place to write end-to-end tests is in the json-tck project; this
bootstraps the viewer.  More generally, the tck (technology compatibility
kit) project is where I'm hoping that to build a standard set of DOM
objects that allow the different components to check various behaviour.
 Right now, I've got as far as moving those DOM objects out of the
component-specific projects and into the tck-dom so that they can be shared
(though in one or two cases for some of the object stores) they are now
being shared.

At any rate, what I'm trying to say is that when you run the tests in the
json-tck project, then you'll be able to serve up TCK dom objects. If you
find you need more objects or to change them, then make the change.  Do run
a full "mvn clean install" over all of Isis to make sure you've haven't
broken any other tests, though (that's the downside to this approach).

In terms of logistics, now that we have a github clone, seems to me you
could tap away making enhancements as you see.  Then you can either get an
ICLA on file which will allow me to do "git pull" from your clone, or you
can do it the traditional way, ie adding patches as attachments to that
JIRA ISIS-233 and I can apply them.

So; would be great if you had the time.

One last thing: I'm currently just renaming json-viewer to
restfulobjects-viewer.  I'll have that done today.  So don't start this
very second!

Thx
Dan



>
> Thanks.
> --
> Adam Howard
>
> [1] https://issues.apache.org/jira/browse/ISIS-233
>