Hi Chris,
FORMAT:
I set the 'simple mode' (arrays only when necessary) as default
because it suited my usage of the plugin. I completely see the
argument of always using arrays so the format of the output is always
known (ie.: in arrays), but I do have a reservation about that. I
think in most cases the user will know what the XML structure and
defaulting the plugin to 'simple mode' will result in a neater and
more intuitive interface: "response.result" instead of
"response[0].result[0].text".
As for nodes which are expected to be arrays, there's no reason why -
along with our .find utility method - we can't have an asArray()
method that will, if necesssary, convert the node into an array. This
saves having to parse a pre-defined format and also avoids any lazy
programming - ie.: only do something when you need it.
ATTRIBUTES:
At the moment, I purposely built the plugin to treat text nodes and
attributes exactly the same, meaning your example xml and my example
xml would end up as the same json. The idea of prefixing all
attributes @ is great, but @ is not a valid js variable character and
could only be accessed via person.hair['@colour'] instead of
person.hair.colour. So it might be worth considering an alternative
which does not involve any extra characters....
OVERALL:
My focus really has been on usability. I've gone out of my way to
'hide' the technicalities of the XML and keep the JSON as simple as
possible. I agree it will have to get a little more complex if we're
going to implement this additional functionality and support json to
xml conversion, but it would be great if we can find a way to do
both....
Cheers,
Diego A.
On Jul 16, 3:17 am, "chris thatcher" <[EMAIL PROTECTED]>
wrote:
> On Tue, Jul 15, 2008 at 4:01 PM, Diego A. <[EMAIL PROTECTED]> wrote:
> > 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
>
> +1
>
>
>
>
>
> > 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?
>
> I didnt realize there was that option. it is sufficient though I'd argue
> from the perspective of the user the latter is simple and the former not so
> much.. looking forward to you later comments I'm wondering if it wouldnt
> be a big win to make it all array all the time. it would definitely fit
> better in terms of making it jive with a jquery feel.
>
>
>
>
>
> > 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???
>
> This is pretty much what I'm thinking but I want to point out none of your
> examples use attributes and as a long time xml advocate if I wrote a similar
> example it would look like:
> <house>
> <kitchen diswasher="RED" fridge="WHITE" telly="24-INCH"/>
> <lounge sofa="brown" telly="50-INCH"/>
> </house>
>
> We can't advocate sensible xml but can you see how this saves big bandwidth
> and maps more cleanly to json? Again not really an implementation issue but
> might as make sure we know how to represent attribute. Though I'm also a
> big user of namespaces I'd say treat them like common attributes an let the
> developer cope with meaning.
>
> I think we could really get some high performance by building the Map you
> talk about and implement find as a pure RegExp. I like the way you are
> keeping it simple an jquery ish.
>
> > Cheers,
> > Diego A.
>
> Thatcher
>
>
>
> > 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
>
> ...
>
> read more »
