Workaround, to get representational snapshot, within MozXBL1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks for that answer Doug.
Here's my strategy to get a snapshot anyway:

Within my bindings I add <stelt:insert/> right after <children/> ,
also i add stelt:path="something" to the first element within <content>.
"something" there actually being "root" for my top element being bound
and kids below that, being bound get "root_0", "root_1", etc.,
grandchildren get "root_0_0" etc.

Then i have the following code to generate a valid SVGDocument, that i
call with a bookmarklet: javascript:viewShadowSource();

WARNING: This code doesn't work yet (needs debug and cleanup),
but i think it's good enough to get the idea:


function process(shadowchunk){
path=shadowchunck.getAttribute("stelt:path");
clonechunk=shadowchunk.cloneNode(true);
clonechunk.removeAttribute("stelt:path");
if (path=="root") newdoc.addElement(clonechunk);
shortlist=clonechunk.getElementsByTagName("stelt:insert");
if (shortlist.length==1){
insertchunk=shortlist[0];
insertpoints[path]=clonechunk;
}//else insertchunk=null,
parentpath=path.substring(0,path.lastIndexOf("_")-1);
insertpoint=insertpoints[parentpath];
insertpoint.parentNode.insertBefore(clonechunk, insertpoint);
}
function addShadow(chunk){
try{
var anonylist=document.getAnonymousNodes(chunk);
var n=anonylist.length;
if (n>0){
for (var i=0; i<n; i++){
process(anonylist[i]);
}
}
}catch(e){}
var list=chunk.childNodes;
var n=list.length;
if (n>0){
for (var i=0; i<n; i++){
addShadow(list[i]);
}
}
}
function viewShadowSource(){
newwin=window.open();
newdoc=newwin.document;
addShadow(document.documentElement);
longlist=newdoc.getElementsByTagName("stelt:insert");
n=longlist.length;
for(var i=0;i<n;i++){
node=longlist[i];
node.parentNode.removeElement(node);
}
}

Ruud

--- In xbl-developers@yahoogroups.com, "Doug Schepers" <doug@...> wrote:
>
> Hi, Ruud-
>
> steltenpower wrote:
> |
> | Imagine you have built an application with XBL cause that is a great
> | clean way of working with you data. While using the application you at
> | some stage get such a nice picture on screen that you want to save it,
> | maybe edit it with Inkscape and then use it for a PDF business report.
> | Or less lucky; you get such a weird picture you expect something's
> | wrong and like to use SVG debugging tools to figure out if or what is
> | wrong in the SVG picture.
> |
> | To my surprise with MozXBL1 there is not a SVGDocument instance you
> | can somehow get to. Also the DOM inspector doesn't offer a way. I'm
> | now clumsily adding things in my bindings to still get to a
> | SVGDocument, or rather construct it from ShadowContent bits (i'll post
> | code when i'm done/stuck). Some helpful Mozilla people explained that
> | MozXBL isn't designed for such a use case, that the Gecko rendering
> | engine is not well fit for it and that it won't be possible at all in
> | MozXBL2 for security- and DOM-limitation reasons.
> |
> | Do you think XBL is the right principle/way to go to implement this
> | use case scenario, and if not please tell why and describe the mix of
> | specifications that you think would better fit ?
> |
> | Am i missing or mistaking something in this message?
>
>
> I think this is a perfectly valid use case, though I certainly can't
speak
> for the MozXBL guys, nor can I suggest a workaround (other than
building a
> "static" copy when you are constructing the elements via script). I will
> suggest to the sXBL TF that there is a way to serialize the shadow
content
> en masse, such that it would be easier to save the output. The
> presentational view of the data can be as important as the data itself.
>
> The rationale "for security reasons" doesn't ring well with me,
personally.
> It always sounds like the politicians who say, "Think of the
children." The
> fact is, there are secure implementations of DOM3 Load&Save, and
WebAPI is
> addressing the issue of sandboxed file access.
>
> Regards-
> Doug
>