Adaptors to different data formats in backend

[jnthnlstr]

Hello,

I'm thinking about how to add a step to the save/load process in the
WiringEditor to convert the WireIt JSON format into another format.
This is because I have a datastore that uses a different JSON format
than the one used for WireIt and I don't have the flexibility to
change that, however I would like to use WireIt as a client to view
and manipulate that data.

I have considered putting the conversion in as a first step in the
backend, but this seems like the wrong place - I'd like the backend to
be as simple as possible and just be responsible for reading and
writing the data.

My other thought is that I could put in some sort of hook for my
conversion function e.g by hijacking WiringEditor.prototype.onLoad.
That's what I'm going to try for now.

Anyone else have a similar use-case that might inform this choice?


J.

[Eric Abouaf]

Hi,
which format are you planning to use ? anything beside JSON or XML ?

Feel free to do the data conversion wherever you like (client or server)... both are possible.
I would say it is a bit easier on the server, since on the client, it would require hacking the WiringEditor.js

--
Eric Abouaf
eric....@gmail.com
Tél: 06 29 86 37 89

[jnthnlstr]

Hello,

I've just written up my experiences adapting WireIt to work with an
independent backend. It's part of a project the BBC have commissioned
from LShift, a consultancy in Shoreditch, London.

Hope it's of interest and shows more of my motives:
http://tinyurl.com/m3ukwm


J.

> eric.abo...@gmail.com

[neyric]

Hi,

Great post jay ! It's nice to share your experience... Hopefully it
will be re-used by many WireIt users.

Your post made me realize that the current WiringEditor's backend
adapter was pretty hard to grasp (SMD, Json-Schema, YUI-RPC, etc....)
This forum also received many questions about the way to transform the
data and where this code should be.
On this concern, your post is very clear and describes the best way to
do it.

However, this should be simpler, so I think it's time to refactor this
part of the library (the WiringEditor still is a very young
component....)

What I propose is to create "adapters" to connect to the storage of
your choice; example:

WireIt.WiringEditor.adapters.AjaxAdapter = {

saveWiring: function(callbacks) {
....
},

deleteWiring: function(callbacks) {
....
},

};

Of course, all methods of these adapters are asynchronous.

Then, you would just have to instantiate the WiringEditor with your
custom adapter:

new WiringEditor({
...,
adapter: WireIt.WiringEditor.adapters.AjaxAdapter,
...
});


What do you think ?

[Leif Warner]

You can override the WiringEditor to do different things, as Eric
showed me with code for http://feedscape.appspot.com, starting with
the part that says:
"YAHOO.lang.extend(XProcEditor, WireIt.WiringEditor, { ..."
I had been thinking of writing my own getValue() function, but I
suppose you could always just write some JS to mangle the existing
structure returned by getValue().

About the SMD / YUI-RPC business... I had been looking into attempting
to write some stuff to use that with a Java Servlet backend, but I
think I was little confused by how "magic" it seemed. Think I might
try some plain-old "REST"-y plan of just having GET /pipes return a
listing of pipe workflows to load in the wiring editor, GET /pipes/
{$pipename} to load the one named $pipename specifically, POST /pipes/
{$pipename} to save it, DELETE /pipes/{$pipename} to delete it,
etc... That isn't as general -- for instance I'm not sure how my
POSTing the workflow to /run to "Run" the thing fits into that
workflow, but... it works. Earlier I had been thinking about sticking
the functionality of that "Run" button into the SMD (right now it just
posts a simple form submit)... The internet is hard.

All the switching back and forth between JSON and XML in this thing
lead me to look at http://jsonml.org/ , and from there they had a link
to JSON-RPC (not sure if there's a relation to YUI-RPC).

-Leif

[Eric Abouaf]

Hi ,
same thing here again: I made things simpler by using adapter objects instead of complicated SMD/yui-rpc.

http://groups.google.com/group/wireit/browse_thread/thread/14f12c5ee14da872

I'll try to write a tutorial when this get released.

--
Eric Abouaf
eric....@gmail.com

[jnthnlstr]

Eric,

Brilliant. I'm glad you liked the post and I'm glad you've chosen what
looks like a much simpler method for working with the backend. It's a
lot more JavaScript-y to my mind. :)

Sorry for the lack of response last weeek, I was on holiday!

(Now, to rewrite my application...)


J.

On Jul 13, 11:26 am, Eric Abouaf <eric.abo...@gmail.com> wrote:
> Hi ,
> same thing here again: I made things simpler by using adapter objects
> instead of complicated SMD/yui-rpc.
>

> http://groups.google.com/group/wireit/browse_thread/thread/14f12c5ee1...

>
> I'll try to write a tutorial when this get released.
>
>
>
> On Mon, Jul 13, 2009 at 10:31 AM, Leif Warner <abimel...@gmail.com> wrote:
>
> > You can override the WiringEditor to do different things, as Eric

> > showed me with code forhttp://feedscape.appspot.com, starting with

> > the part that says:
> > "YAHOO.lang.extend(XProcEditor, WireIt.WiringEditor, { ..."
> > I had been thinking of writing my own getValue() function, but I
> > suppose you could always just write some JS to mangle the existing
> > structure returned by getValue().
>
> > About the SMD / YUI-RPC business... I had been looking into attempting
> > to write some stuff to use that with a Java Servlet backend, but I
> > think I was little confused by how "magic" it seemed.  Think I might
> > try some plain-old "REST"-y plan of just having GET /pipes return a
> > listing of pipe workflows to load in the wiring editor, GET /pipes/
> > {$pipename} to load the one named $pipename specifically, POST /pipes/
> > {$pipename} to save it, DELETE /pipes/{$pipename} to delete it,
> > etc...  That isn't as general -- for instance I'm not sure how my
> > POSTing the workflow to /run to "Run" the thing fits into that
> > workflow, but... it works.  Earlier I had been thinking about sticking
> > the functionality of that "Run" button into the SMD (right now it just
> > posts a simple form submit)...  The internet is hard.
>
> > All the switching back and forth between JSON and XML in this thing

> > lead me to look athttp://jsonml.org/, and from there they had a link