Hi Chris,
AJAX:
> Yeah actually I think it's normally sufficient to let the user use jquery
> ajax as usual but just provide easy functions to unmarshal/marshal into the
> format they need where ever they need it. It reduces the size of the plugin
> and I've sort of found most ajax-convenience functions in plugins aren't
> exactly what I need so I end up not using them anyway. Not always true
> though and if you think there some benefit I really don't feel very strongly
> either way (just playing devils advocate.)
We need not re-invent the wheel. I think it would be fair to assume users of
this plugin will have a certain amount of experience and would be quite
capable (and would probably prefer) to write their own ajax calls, like
this...
$.get(url2xml, function(response){
var json = $.xml2json(response);
// do stuff
});
Having said that, it would be very easy to assume that an ajax call is
required when a function is sent in one of the parameters, for example:
$.xml2json(url2xml, function(json){
// do stuff
});
... which doesn't really save (or cost) much time (or code) but it provides
a simple little hook for Ajax calls. :-D
FORMAT:
> Where it really became an issue in a production environment was that I
> always had to test every 'element' to see if i needed to treat it as an
> array or object. And every time I started to rely on it being an {} or [],
> there was some corner case that came up gave me the other and the code
> broke. This is especially true in templates.
>
OK, my current implementation allows you to choose between 2 formats:
simple - arrays when necessary
extended - always use arrays
...isn't that enough to solve the problem of not knowing what to expect? In
your case for example, just use extended mode and you're good to go. I just
can't see a scenario where the user of this plubing would insist of choosing
specific formatting options for different 'branches'... Am I being
un-reasonble?
Serialization/De-serialization:
I see what you're saying and it seems great. I'd have to figure out how to
make this work, but I have had an idea which might just do the job. In the
documentation, I wrote a script that goes through the json object and
represents it in HTML. That same script could be used to create a 'map' of
the json structure. This map could be an array OR maybe even better, a
simple string with the path ("reference") to every node in the structure.
Something like this:
Consider this XML:
<house>
<kitchen>
<dishwasher>RED</dishwasher>
<fridge>WHITE</fridge>
<telly>24 INCH</telly>
</kitchen>
<lounge>
<sofa>BROWN</sofa>
<telly>50 INCH</telly>
</lounge>
</house>
Which would result in the following map...
JSON MAP: [
"kitchen", "kitchen.dishwasher", "kitchen.fridge", "kitchen.telly",
"lounge", "lounge.sofa", "lounge.telly"
]
That way we could come up with some xpath-like markup to search through
nodes just like you suggested...
json.find('dishwasher') // gives us array with nodes kitchen.dishwasher
json.find('dvd') // gives us an empty array
json.find('telly') // gives us array with nodes kitchen.telly and
lounge.telly.
$.each(json.find('telly'), function(i, node){
// 1st - kitchen.telly node
// 2nd - lounge.telly node
});
How does that sound???
Cheers,
Diego A.
2008/7/15 chris thatcher <[EMAIL PROTECTED]>:
>
>
> On Tue, Jul 15, 2008 at 10:18 AM, Diego <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi Chris,
>>
>> I'd be glad to work on this with you. Unfortunately, I'm completely
>> tied up with a couple of other projects for the next few days. I won't
>> have a chance to work on the next version, but I'll let I know as soon
>> as I make some changes.
>>
> Same boat here so we can organize a little then push forward.
>
>
>>
>>
>> AJAX:
>> Although I released this as a jQuery plugin, it doesn't actually make
>> any use of jQuery functionality, other than the $.each function. But
>> as you suggested, it does make sense to integrate it with jQuery a bit
>> further and to include ajax.
>>
> Yeah actually I think it's normally sufficient to let the user use jquery
> ajax as usual but just provide easy functions to unmarshal/marshal into the
> format they need where ever they need it. It reduces the size of the plugin
> and I've sort of found most ajax-convenience functions in plugins aren't
> exactly what I need so I end up not using them anyway. Not always true
> though and if you think there some benefit I really don't feel very strongly
> either way (just playing devils advocate.)
>
>
>> FORMAT:
>> As far as formatting is concerned, I understand that you'd like the
>> output to follow a certain format, but is this really something that
>> is worth working on? Isn't what I've got at the moment enough, ie.:
>> use arrays only when necessary OR always use arrays. Is there really a
>> need to specify which nodes should be arrays and which shouldn't?
>
> Where it really became an issue in a production environment was that I
> always had to test every 'element' to see if i needed to treat it as an
> array or object. And every time I started to rely on it being an {} or [],
> there was some corner case that came up gave me the other and the code
> broke. This is especially true in templates.
>
>>
>>
>> Serialization/De-serialization:
>> I like the idea (like the firefox about:config page), but what affect
>> would this have on memory? ie.: by doing this, wouldn't we essentially
>> double memory usage by storing every value in data['a.b.c'] as well as
>> data.a.b.c?
>>
> They are actually different objects so you'ld have myJsonObject.a.b.c and
> myRejosnObject['a.b.c']. Normally how I use it is I only use json form in
> code, but marshal to/from the rejson when serializing to/from sqlite, and
> marshal to/from the xml form when serializing to/from the server. But this
> was just my use case. In general the idea is that only one form is present
> in memory at a time, but it's easy to move between them when I need to. So
> if I wanted to provide a nice table to edit an object, I could retreive that
> object as rejson from the db and I'd just leave it in the same form or if it
> came as xml from the server I'd marshal directly to rejson, skip json, and
> delete the xml footprint. In the end I think the marshalling performance is
> what we focus on and let the user decide when they need delete objects.
>
> Just some thoughts. I'll try to clean up some older example code. I also
> think it might be worth thinking about how Ariels jquery.collections and
> something like jspath could be used to provide some more jquery-like,
> e4x-ish approach so we could have
>
> var data = jqE4X(xml);//basically marshals to json
> jqE4X('a..c', data).each(function(){
> //etc gives us an array of all decendants 'c' of data.a
> });
>
> Or is this not at all what you have in mind?
>
> Thatcher
>
>
>> Again, thank you for your interest in this project. I look forward to
>> your reply...
>>
>> Cheers,
>> Diego A.
>>
>> On Jul 8, 12:11 am, "chris thatcher" <[EMAIL PROTECTED]>
>> wrote:
>> > yeah it would be great to see it ported to a jQuery plugin in
>> combination
>> > with your work and then you could actually use jQuery ajax and it would
>> be
>> > cleaner. I've used it a lot and for me the big thing is the ability to
>> easy
>> > set what elements are treated as array's even if only one is present
>> > (because it keeps the code using it simpler, less cases), and specifying
>> the
>> > attribute prefix (I use '@') because I can basically use e4x like
>> syntax.
>> >
>> > I also made a modification to xotree locally to allow a flat
>> > serialization/deserialization so that the item becomes a list of
>> name/value
>> > objects, the name being the 'javascript path' eg '[EMAIL PROTECTED]' and
>> the
>> > value is the simple value. This was extremely useful for fast
>> development
>> > with GoogleGears because I could have a generic table for all objects
>> and
>> > use the powerful 'name LIKE' queries to find objects stored in the db.
>> >
>> > I'd love to help you develop this or give feedback because it would also
>> > help promote some mvc stuff I'm build for the jQ community.
>> >
>> > Thatcher
>> >
>> >
>> >
>> > On Mon, Jul 7, 2008 at 6:59 PM, Diego <[EMAIL PROTECTED]> wrote:
>> >
>> > > Hi Chris,
>> >
>> > > I hadn't seen xotree before, but I found it...
>> > >http://www.kawa.net/works/js/xml/objtree-e.html
>> > > ...and looking at the examples, it seems to behave exactly like my
>> > > plugin but it's more flexible with options and built-in ajax support.
>> >
>> > > It's definitelly a good base for future development of my plugin...
>> >
>> > > Cheers,
>> > > Diego A.
>> >
>> > > On Jul 7, 8:10 pm, "chris thatcher" <[EMAIL PROTECTED]>
>> > > wrote:
>> > > > Have you looked at xotree.js ? Nice work.
>> >
>> > > > On Mon, Jul 7, 2008 at 10:30 AM, Alexsandro_xpt <[EMAIL PROTECTED]
>> >
>> > > wrote:
>> >
>> > > > > Hi Diego,
>> >
>> > > > > I mean ( 1 )
>> >
>> > > > > I Know, but would be something like that
>> <xml><person><name>Diego</
>> > > > > name></person></xml> already great. :)
>> >
>> > > > > Nice plugin.!!
>> >
>> > > > > On 5 jul, 00:06, Diego <[EMAIL PROTECTED]> wrote:
>> > > > > > Hi Alexsandro,
>> >
>> > > > > > Do you mean....
>> > > > > > (1)"convert the generate JSON back to XML"?
>> > > > > > OR...
>> > > > > > (2)"define a javascript object and convert it to XML"?
>> >
>> > > > > > If (1):
>> > > > > > I initially built this plugin for my personal use (for my
>> > > > > > "convenience") so I could easily process XML data. Because of
>> that, I
>> > > > > > didn't bother to differentiate between attributes / nodes. ie.:
>> > > > > > <xml><person><name>Diego</name></person></xml>
>> > > > > > ...gives the same output as this...
>> > > > > > <xml><person name="Diego"></person></xml>
>> > > > > > ...so it would be impossible to "reverse the conversion".
>> >
>> > > > > > If (2):
>> > > > > > This is quite easy. And actually, it would be pretty similar to
>> the
>> > > > > > code I wrote to show the JSON structure in HTML (Under Examples
>> >
>> > > > > > Basic/Extended Structure)
>> >
>> > > > > > I will write this when I get a chance, but I'd rather wait for
>> the
>> > > > > > feedback on this plugin to work out the best way to do it...
>> >
>> > > > > > Cheers,
>> > > > > > Diego
>> >
>> > > > > > Alexsandro_xpt wrote:
>> > > > > > > Very good!!!
>> >
>> > > > > > > Are possible to do reverse?
>> >
>> > > > > > > --
>> > > > > > > Alexsandro
>> > > > > > >www.alexsandro.com.br
>> >
>> > > > > > > On 4 jul, 12:34, Diego <[EMAIL PROTECTED]> wrote:
>> > > > > > > > I wrote this a few months but didn't have the time to share
>> it.
>> > > Now
>> > > > > > > > that I've re-done the documentation for 2 of my plugins I
>> thought
>> > > I'd
>> > > > > > > > give it a few hours, knock some examples together and share
>> it
>> > > with
>> > > > > > > > the whole world (ok, maybe just a few people).
>> >
>> > > > > > > > Basic example:
>> > > > > > > > var xml = '<xml><message>Hello world</message></xml>';
>> > > > > > > > var json = $.xml2json(xml);
>> > > > > > > > alert(json.message); // shows "Hello world"
>> >
>> > > > > > > > Ajax example:
>> > > > > > > > var file = 'data/hello.xml'; //<xml><message>Hello
>> > > world</message></
>> > > > > > > > xml>
>> > > > > > > > $.get(file, function(xml){
>> > > > > > > > �var json = $.xml2json(xml);
>> > > > > > > > �alert(json.message);
>> >
>> > > > > > > > });
>> >
>> > > > > > > > See the documentation page for more examples and demos.
>> > > > > > > > XML to JSON Plugin -
>> http://fyneworks.com/jquery/xml-to-json/
>> >
>> > > > > > > > As always, feedback is welcome!
>> >
>> > > > > > > > Cheers,
>> > > > > > > > Diego
>> >
>> > > > --
>> > > > Christopher Thatcher
>> >
>> > --
>> > Christopher Thatcher
>>
>
>
>
> --
> Christopher Thatcher
--
Cheers,
Diego A.
