FORMAT:
Yeah I agree the {}/[] issue complex and after going another round with
xotree I have to say I really like the 'force_array' map it optionally
allows. That said the asArray() solution works and I might like it even
better once I'm using it becuase I'm totlly Lazy ;)
ATTRIBUTES:
if you want to encourage dot notation for attributes, the best thing to do
is look at what is legal for js names but not for xml names and basically
your left with '$'. The bigger issue occurs with the use of ':' in xml
names is legal but obviously not for js and in fact an xml name can even
start with ':' or '_' as well. The underscore isn't an issue but if you
want a quick replace method to go from attribute xml to js name and back the
easiest way may be
xml attribute name to js name
1 prefix by '$' to denote an attribute
2 replace all ':' with '$'
js name to xml attribute name
1 remove prefix '$'.
2 replace all '$' with ':'
This keeps it clean for the simple no-namespaced xml, but still lets us
namespace dorks keep using namespaces and still access our attributes.
eg no namespace
foo.bar.$goop
eg namespaced
foo.bar.$svg$goop
What do you think?
OVERALL:
I agree with your approach and coming from a heavy xml background and still
using stuff like this for wierd/ugly/legacy xml means I need to not loose
info. I say make the simplest cases very elegant like you've already
described and I'll help make sure that the critical xml info is still
identifiable so we can round-trip non-lossy.
MIXED CONTENT
I generally don't think tools like this are very useful for mixed content
like <foo> bar <goop blah="ugh"/> pooh </foo> but I was curious if you
wanted to try to address this or just note it as unsupported.
Thatcher
On Wed, Jul 16, 2008 at 5:27 AM, Diego <[EMAIL PROTECTED]> wrote:
>
> 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 ยป
>
--
Christopher Thatcher
