[Dojo-interest] JSON for XSLT (was dojo.xml.XlsTransform feature request )

[D-Fens]

Tom,

I'm fine not to send it to the list - I also have no problem with my code
not being included in dojo -  believe me, I'm honest - I don't care. My code
won't be lost for me, since I keep a copy for myself. If my understanding of
your point of view is correct no other user will be anyway interested in it.
As soon as dojo offers this "code upload/download" facility, I will upload
my code to the community and we will see who's right or wrong - fair
competition, isn't it ? 

Still, the two people's comments is 100% of the feedback you got for now and
to be honest, if I would release a new package and the first and only
feedback I get from users is that something important is missing, I'd take
this into serious consideration. 


Tom Trenka wrote:
> 
> D-Fens,
> *Don't* send it to this list.  Post it to the Dojo Trac system.  If you
> post it here it will be lost in the noise and it's possible that it may
> end up being lost forever.  I can tell you for sure that even though you
> submit it as a patch, we're not going to be able to even consider it for
> inclusion for at least a couple of months (this is part of what I have
> been trying to say subtlely...there's a *lot* going on right now and
> because of that we're not really going to consider new code for a
> while--at least not that I know of.  Hell, I'm having a hard time even
> trying to get some bug fixes to the Charting  code into the next
> incremental release.)
> 
> Finally, with no offense to either you or Sacha, I would say that two
> people asking for it on a list does not make it a common request.  10 to
> 20 people asking for it, with the same situation, would make it a common
> request :)
> 
> trt
> 
> 
> D-Fens wrote:
>> 
>> Tom,
>> 
>> based on Roberts implementation I will write a enhanced version of
>> XslTransform that 
>>    a) maintains its own cache for previousely built processors, since
>> this is missing right now
>>    b) support PI's if no stylesheetURI has been explicitely set
>>    c) also works in firefox
>> I don't think this will take any longer then 2-3 days, but to be honest
>> I'm very busy this time and it could take me 1-2 weeks to complete this.
>> Once done, I will send this to Robert/you/this forum and would request
>> that you confirm that the enhanced version provides the exact same
>> functionality as Roberts initial version, if used in that manner/fashion.
>> This way, the framework does not dictate a specific design (as now) but
>> can be used for it's only purpose : transforming xml along with
>> stylesheets the best way possible and leave software design up to the
>> users.
>> 
>> Regarding you email, my personal experience differs a lot from yours and
>> I do not agree to most of what you said - but (to eliminate the pedantic
>> tone :-) I can perfectly live with your opinion and fully respect your
>> comment. I did not experience any of the scenarios/problems issues you
>> mentioned so far, hosting a REALLY big set of xml/xsl based applications.
>> 
>> Finally, I would like to raise one question : how many posts/replies
>> where sent to this forum in respect to the XslTransform package ? Not
>> many I'd assume - amongst those few posts you see two people (Sasha and
>> me) requesting support for PI's. That should clearly indicate, that you
>> missed a major use case with your implementation - one could say : 100%
>> of users comments related to this package requested support for PI's.
>> Think about it :-)
>> 
>> Have a nice weekend.
>> 
>> 
>> Tom Trenka wrote:
>>> 
>>> Sigh.
>>> 
>>> I never said you were stupid, and I never said that we didn't listen to
>>> what you said.  What I said was something to the effect of "that's not a
>>> standard part of most of the XML APIs out there, and because of that I
>>> doubt it's going to make it into the Dojo codebase".  Big difference.
>>> 
>>> Let's go back for a second to the rendered XML document/browser trigger. 
>>> I haven't worked seriously with any kind of XSL application (other than
>>> to write a few XSL stylesheets to support things like loading a specific
>>> rendering of an Atom or RSS feed into an existing HTML document, and to
>>> write an unreleased JS-based XPath parser) since 2003, and now that I'm
>>> thinking about it, that particular application--similar to the approach
>>> you've taken with the one exception that the *root* document was, in
>>> fact, an HTML document and *not* an XML document--tried the PI approach
>>> and realized (this was before I got to it) that using an HTML root, with
>>> a strong scripting factor to control transformation, was a more
>>> controllable/better way to go.  In fact, based on your description of
>>> what you've been doing, I'm surprised you're still using the PI route.
>>> 
>>> You're right in that it isn't the rendered document that you have access
>>> to, but the original XML doc.  What I was thinking about was trying to
>>> get a scripting hook into that document--and for straight XML documents,
>>> I don't recall that being possible (since a script tag is specific to
>>> certain XML flavors, not XML itself).  It'd be interesting to see if you
>>> could use something like GreaseMonkey and Opera User Scripts (I don't
>>> recall the name of that system) to manipulate a pure XML document that
>>> has been loaded, and consequently somehow re-transform the document
>>> based on the PI instruction, without causing lots of memory problems.
>>> 
>>> (One of the most direct experiences I had from working on the
>>> aforementioned application--aside from having to write a GZIP component
>>> *on the client* in order to be able to POST said document from the
>>> browser back to the server, yes, at least in IE there is a 4MB POST
>>> limit if you haven't tried to attach something in multipart format--was
>>> that the memory usage and performance of that approach was simply
>>> dismal--and I'm not exaggerating.  This particular app would cause IE's
>>> memory grab to go from 22MB to about 150MB, and that was just after app
>>> initialization.  I'm kind of surprised anyone's still using the
>>> approach, to be honest.) 
>>> 
>>> So here's the deal.  Open communication is definitely the basis of good
>>> open source kits; there's no doubt about it, and it's the main reason
>>> why I continue to respond to your messages in this thread, even though
>>> it seems like you are taking some things personally.  But not everything
>>> submitted to an open source kit needs to be accepted to the kit.  When
>>> you do that, you end up with what Sasha thinks--that a framework should
>>> try to solve *all* the patterns for a given problem.  We've been there,
>>> we've done that, have the t-shirt to prove it--and we have other
>>> requirements, like performance and learnability, both of which we have
>>> been bad about at times.
>>> 
>>> On top of that, we get a *sh*tton* of patch submissions, at least 2/3 of
>>> which seem to be edge cases.  In the beginning we would simply review
>>> and apply but we've learned the hard way that we need to start saying
>>> "no" a lot more often than we do.  It was in that spirit that I said I
>>> doubt we'll implement the searching for PI instructions as a source for
>>> XSL stylesheet URIs.  Especially since doing something like that should
>>> be simple enough for someone writing transformations to implement that
>>> themselves.  What would it take, 4 lines of code, starting with a decent
>>> XPath statement?  It seems to me that that kind of thing is really
>>> application-specific, and not something that would find a lot of utility
>>> in a library.  (Though I could be wrong about that, I have before; see
>>> discussions on iterators and implementing "map".)
>>> 
>>> I'm also saying these things with the knowledge that there are some very
>>> big changes coming in the near future to Dojo--knowledge which right now
>>> has been restricted to the core committer group.  It may very well be
>>> that Robert's XslTransform will end up being the basis for something a
>>> bit more extensive but we are right now in the middle of a major shift
>>> and it's not a topic (despite the number of emails on this thread) that
>>> we can spend a lot of bandwidth on *at this time*.
>>> 
>>> One of the things we are going to try to do is provide a place where
>>> people like you, who think something like this is a good idea and could
>>> be used by the community at large, can put code snippets up for others
>>> in the community to download and use.  If the idea takes off, we will
>>> probably then use statistics from that as a way of judging when
>>> something really should be a part of the actual distro, and when it's
>>> really just wasting space.
>>> 
>>> ---
>>> As for the FF bug, if you could do us a favor--do a grep, find the
>>> places where you think Dojo is using it, and actually *file a bug* in
>>> trac for us (http://trac.dojotoolkit.org, login guest/guest), that would
>>> be good.  Bugs reported to the interest list *will* get lost in the
>>> noise, and most frequently does.  If the bug ends up being invalid, it
>>> will be marked that way but at least we have a record of the report.
>>> 
>>> trt
>>> 
>>> 
>>> D-Fens wrote:
>>>> 
>>>> Tom, 
>>>> 
>>>> here is what you said that made me think we don't share the same
>>>> understanding :
>>>> 
>>>>>To begin with, using a processing instruction with an XML document is
>>>>>certainly an option, but it takes the creation and triggering of a
>>>>>transformation out of the hands of script and puts it into the hands of
the
>>>>>browser.  Usually, the browser implementation is to take the rendered
XML
>>>>>document and give you script access to the rendered result (though this
>>>>>varies).  I can tell you from experience that using this approach to
script
>>>>>a live XML document--particularly in Internet Explorer--is a major
PITA.
>>>> 
>>>> As I said many times now, loading an xml document with a stylesheet PI
>>>> via dojo/javascript does NOT return the rendered result therefore
>>>> creation/triggering a transformation is still fully in the hands of the
>>>> script and is not put into the hands of the browser. In no way the
>>>> browser (IE6, IE7 and firefox has been tested) implementation takes the
>>>> "rendered" xml and grant access to the rendered result to the script -
>>>> the browser grants access to the original/non-rendered xml if loaded by
>>>> dojo.io.bind means. I don't understand how you can have an experience
>>>> about a non existing functionality and therefore don't agree to your
>>>> PITA statement or subsequent conclusions.
>>>> 
>>>> May be I should step back and explain where I come from, so hopefully
>>>> someone understands that support for PI's is indeed a valid
>>>> requirement.
>>>> - we started developing our applications around 3-4 years ago. At this
>>>> time, dom implementations were not quite stable and especially exposing
>>>> the browser's xslt capabilities were very limited or not even existing
>>>> - this is still the case for some browser today.
>>>> - at this time we did decide to implement our (java) applications
>>>> following a MVC design pattern and strictly using xml and xslt to
>>>> render the gui. At this time, we rendered/transformed on the server,
>>>> due to limited support by the browsers. Even today we'd consider this
>>>> design superior to jsp's or similar technologies.
>>>> - some year later, when browsers finally supported a stable and
>>>> reliable xslt transformation (not yet exposed in the scripting
>>>> environment, but at least by browser implementation) it was a very easy
>>>> task for us to switch to client side rendering, namely by replacing the
>>>> server transformation with 3-5 lines of code that included a respective
>>>> stylesheet PI. And to be honest, we are very happy with this approach :
>>>> works like a charm :-)
>>>> - still our application followed the MVC design pattern, with having
>>>> the view implemented as xsl stylesheets, the model as java code
>>>> producing xml documents and the controller being "struts" that controls
>>>> the page flows and logic. 
>>>> - nowadays, since major browsers exposed its xslt capabilities to the
>>>> scripting environment we are looking into Ajax to also move the
>>>> "controller" / struts part of our MVC setup away from the server into
>>>> the browsers scripting environment. As per my understanding, that is
>>>> the major benefit of all the Ajax frameworks, namely that server
>>>> requests are made async and screen/controller logic is implemented in
>>>> javascript. Our application is in this respect not different then all
>>>> the other "web 1.0" applications.
>>>> - it would be (again) very easy for us, to use the XslTransform
>>>> package, if PI's would be supported - not as "the way how everyone has
>>>> to do it" but as a valid and standardized option to assign a stylesheet
>>>> to a xml document. If PI's are not supported, we'd need to implement
>>>> some kind of proprietary logic in our dojo scripts, that assigns a
>>>> stylesheet to a xml document - we see no sense in doing so, since this
>>>> information is already there in all of our xml's - by the way following
>>>> a w3c standard instead of proprietary logic. 
>>>> 
>>>> I also mentioned several times that support for PI's could/should be
>>>> implemented as an enhancement, not breaking or modifying the current
>>>> design approach in XslTransform. If a stylesheet is not explicitly set
>>>> by dojo / the script, why not look ionto the xml and see if the
>>>> information is there ? What's wrong with that ? You unnecessarily limit
>>>> the scope and usability of this package. Again, if a stylesheet URI is
>>>> explicitly set, then take it - but if not, instead of just throwing an
>>>> error you should accept that this kind of information might also be
>>>> included in the xml via PI (as per w3c standard). Not doing so I'd not
>>>> consider this a good "software design" but simply being ignorant.
>>>> 
>>>> In my opinion, many xml/xsl based applications followed the same
>>>> evolution as ours, namely starting with server side rendering, then
>>>> move to client side rendering using PI's and now using Ajax to also
>>>> move the controller logic into the browser. Therefore I'd guess that
>>>> many xml/xsl based applications ARE actually using PI's for the reasons
>>>> mentioned above. If not supporting PI's the usability and scope
>>>> therefore is unnecessarily limited in my opinion.
>>>> We are still able to use this package, namely by first extract the PI
>>>> ourself, setup the XslTransformer with the stylesheet URI and then do a
>>>> transformation - yes, this works - but we' d need to to this extra
>>>> steps for each and every time we'd use this XslTransformer. Let's be
>>>> serious : we are talking of 10-15 lines of code that probably need to
>>>> be changed in XslTransform to support xml PI's that would certainly
>>>> save us hundreds (if not thousands) lines of code to work around the
>>>> missing feature.
>>>> 
>>>> Anyhow, you are right that I could implement my own version or use any
>>>> of the other frameworks around (freja or sarissa for instance) to get
>>>> what I need - okay. But this is not my understanding of "open source".
>>>> Rather then selfimplementing I prefer to post comments about either
>>>> bugs or missing features, so the existing package gets enhanced and
>>>> stabilized and therefore "develops" into something better - this is how
>>>> open source usually works, isn't it ? I think what makes open source
>>>> really working is the very valuable user comments about bugs/features
>>>> that one gets for free and I'd expect that any comment is respected as
>>>> a valid user opinion. Having posted a serious bug and a feature request
>>>> all I got back today was good advices and questionable comments - what
>>>> I did not yet receive is :
>>>>    a) a software that works (see my firefox bug description)
>>>>    b) a software that fufills my requirements.
>>>> 
>>>> I fully appreciate Roberts work and indeed this is a good starting
>>>> point to actually support xml/xsl based applications like ours in dojo.
>>>> Indeed, I had a look at dojo 0.3.1 some months ago and decided not to
>>>> go for it just because such XSL support was missing - now I reconsider
>>>> dojo due to Robers package. Anyhow, I'm not willing to further discuss
>>>> any of the recommendations or good advices - we can do this until the
>>>> cows come home and I actually have bigger fish to fry then spending
>>>> hours in such discussions. 
>>>> 
>>>> Respect my user comments as being the heart of open source or leave it.
>>>> 
>>>> Finally, the fact that just by looking at the code (not even testing
>>>> it) I discovered a major bug in this package (see my firefox bug
>>>> description) that apparently has been overseen by Robert and you (as
>>>> the reviewer) should give some indication that I'm not as stupid as you
>>>> might think and you should better listen to what the "users" say.
>>>> 
>>>> Thanks.
>>>> 
>>>> 
>>>> Tom Trenka wrote:
>>>>> 
>>>>> Hrm.  I think you missed something...I never said that loading an xml
>>>>> document via dojo automatically triggered a transformation; in fact,
>>>>> what I said was that trying to load an xml document directly into a
>>>>> ContentPane would *not* trigger that transformation without some nasty
>>>>> hacks--because a document loaded via script is *not* automatically
>>>>> transformed.  Where did you see me say that, and where did I make that
>>>>> assumption?
>>>>> 
>>>>> I *did* say that loading an XML document directly into a browser would
>>>>> trigger a transformation (if the PI was included), and that is done at
>>>>> the browser level, not the scripting level.  Which is what the W3 said
>>>>> an agent should do.  Not following where you think I don't believe in
>>>>> the W3 specs...
>>>>> 
>>>>> (Though for the record I will say that I do think quite a few of the
>>>>> W3 specs are simply bass-ackward; but that's not something I have
>>>>> control over.)
>>>>> 
>>>>> Just to make myself clear--and to debunk the pedantic tone--here are
>>>>> the following points in a precis of the original email I sent:
>>>>> 
>>>>> 1. Using a PI to include a stylesheet takes the triggering of a
>>>>> transformation away from script and into the browser realm.  By this I
>>>>> am implying that loading an XML document by means other than directly
>>>>> will *not* trigger a transformation; but if you load the document
>>>>> directly into a browser, the browser will try to transform the
>>>>> document.
>>>>> 
>>>>> 2. Most of the XML APIs available in a browser--meaning MSXML and the
>>>>> W3--look and operate the way Robert's XslTransform object does, i.e.
>>>>> you load a stylesheet, you load a document, you use the API to apply
>>>>> the transformation to the document.  I have not seen (though
>>>>> admittedly I haven't looked closely in a while) any kind of direct API
>>>>> to grab a PI from a document, parse it as a link to a stylesheet, and
>>>>> load that stylesheet for later transformation.
>>>>> 
>>>>> 3.  Using a PI to point to a stylesheet within an XML document is a
>>>>> great way of creating a quick, static viewable form of an XML
>>>>> document--because it treats the XML as a *document*.  Dojo (and other
>>>>> JS toolkits) specializes in taking a document paradigm and turning it
>>>>> into an application paradigm, and not all of the specs from the W3
>>>>> lend itself to that.
>>>>> 
>>>>> 4.  The purpose of a framework is *not* to support as many design
>>>>> patterns as possible (though many many people continue to make that
>>>>> mistake); the purpose is to provide good solutions for a well-defined
>>>>> task, and in a preferably singular way.  Trying to provide solutions
>>>>> for as many design patterns as possible results in a codebase that is
>>>>> difficult to use, difficult to understand, and in the end providing
>>>>> the lowest common denominator solution--which means it does "ok" for
>>>>> most but not "well" for all.
>>>>> 
>>>>> 5.  Please see my comment about the ContentPane; if it's not clear to
>>>>> you that I understand fully that loading an XML document via
>>>>> javascript does not trigger a transformation, I don't know what to
>>>>> tell you.
>>>>> 
>>>>> 6.  WRT supporting JSON as a data source, my comment here is aimed at
>>>>> treating JSON as an XML data source.  I've been down the path of
>>>>> trying to write an XPath implementation in Javascript (the predicates
>>>>> is the hard part), and I've found that it becomes *huge* with very
>>>>> little performance gain.
>>>>> 
>>>>> There are other solutions out there that involve using template
>>>>> systems based on JSON that may be what Sasha is looking for (TrimPath,
>>>>> a couple of others) and AFAIK there shouldn't be any reason why that
>>>>> can't work with Dojo.
>>>>> 
>>>>> ---
>>>>> 
>>>>> And last but not least: just because a patch is submitted does NOT
>>>>> mean that it will be automatically included in the library.  Frankly,
>>>>> there's nothing wrong with anyone simply writing thier own code on top
>>>>> of Dojo and releasing it to the community on thier own--and why this
>>>>> really hasn't happened to date is partially our (Dojo's) fault, and we
>>>>> are taking steps to correct that.  If you (or anyone else) feels that
>>>>> you have something worth releasing, then by all means release it!
>>>>> 
>>>>> trt
>>>>> 
>>>>> 
>>>>> D-Fens wrote:
>>>>>> 
>>>>>> Tom,
>>>>>> 
>>>>>> to be honest, I nearly 100% disagree to everything you wrote - all
>>>>>> your findings (?) are based on the wrong assumption that if you load
>>>>>> a xml-document via dojo/javascript, a transformation automatically is
>>>>>> performed if a stylesheet PI is included.
>>>>>> 
>>>>>> Pls. note : this is simply not true. 
>>>>>> 
>>>>>> Even though I knew before, I even did test this again and you can be
>>>>>> 100% sure that neither IE6, IE7 or Firefox 2.0 will behave as per
>>>>>> your assumption/expectation. If you load an xml document that
>>>>>> includes a stylesheet PI the browser will exactly do this - load the
>>>>>> document - that's it - not more nor less. If you want to have it
>>>>>> transformed, you need to do that via javascript. The only way that a
>>>>>> browser will do a transformation automatically is when the browser
>>>>>> (not via javascript) is following a link to an xml with PI. If you
>>>>>> load documents from within dojo/javascript, no transformation takes
>>>>>> place. Understood ?
>>>>>> 
>>>>>> Pls. also note that stylesheet PI's are a W3C standard - may be we
>>>>>> should inform the W3C that Tom Trenka does not agree to their
>>>>>> standards/specifications and we can see what W3C says.
>>>>>> 
>>>>>> Pls read my further comments below.
>>>>>> 
>>>>>> 
>>>>>> Tom Trenka wrote:
>>>>>>> 
>>>>>>> I thought it best to respond to this particular message as opposed
>>>>>>> to the ones further down the thread, since it seems to me the most
>>>>>>> important points are demonstrated here.
>>>>>>> 
>>>>>>> To begin with, using a processing instruction with an XML document
>>>>>>> is certainly an option, but it takes the creation and triggering of
>>>>>>> a transformation out of the hands of script and puts it into the
>>>>>>> hands of the browser.  Usually, the browser implementation is to
>>>>>>> take the rendered XML document and give you script access to the
>>>>>>> rendered result (though this varies).  I can tell you from
>>>>>>> experience that using this approach to script a live XML
>>>>>>> document--particularly in Internet Explorer--is a major PITA.
>>>>>>> 
>>>>>>> Furthermore, the transform functions are tailor-made for the ability
>>>>>>> to either dynamically load a set of stylesheets and apply them to
>>>>>>> different nodes, or to load stylesheets dynamically and apply them
>>>>>>> to the same nodes (for different views, for instance).  To try to
>>>>>>> parse an XML document and remove/deal with processing instructions
>>>>>>> for stylesheet transformation is performance limited and frankly bad
>>>>>>> practice.
>>>>>>> 
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> Again, your assumption is wrong. Due to this, all points you
>>>>>>>> mention can naturally also be done, if xml documents contain a
>>>>>>>> stylesheet PI, since those documents are not treated different then
>>>>>>>> xml documents not containing a PI - in no respect, never and with
>>>>>>>> no browser. Making false assumptions, draw wrong conclusions and
>>>>>>>> declare yourself as the software architecture evangelist is frankly
>>>>>>>> speaking .....
>>>>>>>> 
>>>>>>> 
>>>>>>> To address the other major point here...
>>>>>>> 
>>>>>>> 
>>>>>>> Sasha Firsov wrote:
>>>>>>>> 
>>>>>>>> Robert, "good" or "bad" idea is up to user, is it?
>>>>>>>> I could confirm that for several another huge projects. All using
>>>>>>>> the
>>>>>>>> "bad" one :)
>>>>>>>> 
>>>>>>> 
>>>>>>> It really depends on the purpose, parameters and usage of your
>>>>>>> documents.  Using a PI is great for taking an XML document and
>>>>>>> treating it *as a document*.  It is not a great idea for live
>>>>>>> applications--even if we are basing the application on the
>>>>>>> transformation of a document.
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> Tom : pls. note that I'm having a more then 10 years web experience
>>>>>>>> gained in many serious commercial development projects. I currently
>>>>>>>> maintain 12 (big) applications that use approx. 200-300 xml
>>>>>>>> document types all with included stylesheet PI's and used by around
>>>>>>>> 500 users globally. Believe me, my users consider my applications
>>>>>>>> "live". Again, you basic assumptions are wrong and therefore all
>>>>>>>> conclusions !  
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sasha Firsov wrote:
>>>>>>>> 
>>>>>>>> The purpose of framework is to support as much design patterns as
>>>>>>>> possible. And many XML+XSLT ones use XSL link inside of XML.
>>>>>>>> 
>>>>>>> 
>>>>>>> And with this statement, I will not only completely disagree but
>>>>>>> also tell you that this is most certainly *not* the way Dojo is
>>>>>>> oriented.  Most "frameworks" seek to implement one pattern or one
>>>>>>> similar set of patterns--not *all* of them, nor as many of them as
>>>>>>> possible.  You do that, and you end up with a steaming bloated pile
>>>>>>> of crap that is very confusing to use, and in the end doesn't solve
>>>>>>> one problem well--because it is too busy trying to solve *all*
>>>>>>> problems.
>>>>>>> 
>>>>>>> In the past we at Dojo have been bad about this, but that is
>>>>>>> changing and changing hard.
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> may be the only point where i could agree.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sasha Firsov wrote:
>>>>>>>> 
>>>>>>>> Than, I see another way of use XML+XSLT in dojo. In a same way as
>>>>>>>> we
>>>>>>>> have reference to external HTML in widgets like ContentPane, it
>>>>>>>> would be
>>>>>>>> nice to have reference to XML with embedded link to XSLT (and/or
>>>>>>>> links
>>>>>>>> to both). I have been forced to use server-side transformation to
>>>>>>>> perform that. As AJAX developer, I see no reason not to implement
>>>>>>>> it
>>>>>>>> within dojo.
>>>>>>>> 
>>>>>>> 
>>>>>>> Unfortunately you are showing that you don't know how the
>>>>>>> ContentPane actually works (which is ok, it's confusing). 
>>>>>>> ContentPane loads a string and attempts to shove it, inline, into
>>>>>>> the current document.  What that means is that it does not go
>>>>>>> through the process of letting the browser try to interpret what
>>>>>>> type of document is being loaded--which means loading an XML
>>>>>>> document with a processing instruction will not load properly
>>>>>>> without a set of hacks (I don't know if someone implemented said
>>>>>>> hacks, probably would involve creating a hidden iframe, loading the
>>>>>>> XML doc there, and grabbing the rendered results as a string--but I
>>>>>>> wouldn't be surprised if someone like Alex did).
>>>>>>> 
>>>>>>> Because of that, this form of loading content is really not
>>>>>>> recommended--at least not without using the XslTransform code Robert
>>>>>>> originally wrote in the first place, to handle things like this.
>>>>>>> 
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> With your mail you unfortunately also showed your lack of knowledge
>>>>>>>> in terms of what actually happens if a xml documents with PI's is
>>>>>>>> loaded via javascript. Again, your basic assumption is wrong and
>>>>>>>> therefore all your conclusions.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sasha Firsov wrote:
>>>>>>>> 
>>>>>>>> Following recent development trend, I would recommend to use JSON
>>>>>>>> in
>>>>>>>> addition to XML as data source for transformation. Since JSON could
>>>>>>>> easily became a part of DOM, there is no difference from
>>>>>>>> transformation
>>>>>>>> point, does the source came from XML or JSON.
>>>>>>>> Special entry in JSON could simulate XSLT link for XML :) Actually,
>>>>>>>> that
>>>>>>>> is serious demand.
>>>>>>>> 
>>>>>>> 
>>>>>>> Um...tell you what.  Why don't you write that, and write a full
>>>>>>> implementation of XPath for searching over JavaScript objects, and
>>>>>>> then post the result here for the community to look at?
>>>>>>> 
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> Tom, by the way : a full implementation of XPath already exists in
>>>>>>>> javascript, see Googles AjaxXSLT.
>>>>>>>> 
>>>>>>> 
>>>>>>> ...I'll respond to the other emails in this thread as needed.  But I
>>>>>>> would say that I agree with Robert--trying to parse out processing
>>>>>>> instructions embedded in an XML file is not a good idea, and I don't
>>>>>>> think it will something we will implement--particularly when it's
>>>>>>> not something normally implemented with other common transformation
>>>>>>> implementations.
>>>>>>> 
>>>>>>> 
>>>>>>> Joerg Schneider wrote:
>>>>>>>> 
>>>>>>>> No thanks - no reply needed from my side - again, your basic
>>>>>>>> assumption is wrong and therefore all your conclusions.
>>>>>>>> Interestingly enough Robert had the same assumption, so I don't
>>>>>>>> wonder that you both agree.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> trt
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/dojo.xml.XlsTransform-feature-request-tf3097301.html#a8670341
Sent from the Dojo mailing list archive at Nabble.com.