Oh and now that I'm reading my response I forgot to mention these characters
in xml names, '-' (minus) and '.' (dot). Obviously not legal tender in the
js arena. The only thing I can think of here is to not map to a legal js
name and force the associative array usage, eg via foo['bar-goop']
Ugh
Thatcher
On Wed, Jul 16, 2008 at 9:46 AM, chris thatcher <
[EMAIL PROTECTED]> wrote:
> 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
--
Christopher Thatcher
