xbl-developers : Messages : 9-38 of 38

Messages: Show Message Summaries (Group by Topic) Sort by Date

#38 From: "steltenpower" <yahoo@...>
Date: Thu Dec 27, 2007 10:20 am
Subject: Another XBL 'player' steltenpower
Offline
Send Email

X-Smiles does some XBL now too, see http://www.xsmiles.org/

Reply | Forward | Messages in this Topic (1)

#37 From: "steltenpower" <yahoo@...>
Date: Wed Aug 15, 2007 11:41 pm
Subject: current status of XBL flavours? steltenpower
Offline
Send Email

Please add/correct to give an idea of what actually works now.


XBL1, or XBL
============
http://developer.mozilla.org/en/docs/XBL:XBL_1.0_Reference is the
thing that comes closest to what is actually implemented in releases
of Mozilla browsers up to at least Firefox 3.
- http://mozilla.doslash.com/xblschema holds the RNG and generated XSD
- http://spket.com/xul.html shows an editor with XBL specific
functionality (code completion mainly(?)) and
http://addons.mozilla.org/en-US/firefox/addon/3953 is a reference tool
- google for XBL and you'll find working examples (Mozilla extensions,
HTML+XBL and a few SVG+XBL)

sXBL (s=SVG)
============
http://www.w3.org/TR/sXBL/ ('eternal draft, including Schema') is
partly implemented in Batik 1.7 versions, see
http://wiki.apache.org/xmlgraphics-batik/SupportedSVG12Features for
current status

XBL2
====
http://w3.org/TR/xbl (candidate recommendation since March 16) is
being implemented by Mozilla, to replace XBL1 at some point (after
Firefox3 for sure)

Reply | Forward | Messages in this Topic (1)

#36 From: "steltenpower" <yahoo@...>
Date: Sun Jul 22, 2007 3:08 pm
Subject: XBL 2.0 Primer: An Introduction for Developers steltenpower
Offline
Send Email

http://www.w3.org/News/2007#item160

Reply | Forward | Messages in this Topic (1)

#35 From: "Junk Mail" <bdginc@...>
Date: Wed Jan 24, 2007 1:50 pm
Subject: What's up with Safari? bgronek
Offline
Send Email

I'm dying over here....

Does anyone know if / when xbl will be available in safari for scripting behaviors? I'm looking to build cross-browser applications using this technology; however, I can't find any consistent information pointing to safari's support or some sort of roadmap leading up to safari support. I know that David Hyatt, the implementor of XBL for Mozilla, now works at apple on the Safari project and has been pushing for support; however, all threads seem to have dropped off.

Any information would be much appreciated.

Thanks!

Reply | Forward | Messages in this Topic (1)

#34 From: "steltenpower" <yahoo@...>
Date: Thu Nov 16, 2006 2:57 pm
Subject: "Verbosio: Basic XBL validation, anyone?" steltenpower
Offline
Send Email

http://weblogs.mozillazine.org/weirdal/archives/017208.html

Reply | Forward | Messages in this Topic (1)

#33 From: "steltenpower" <yahoo@...>
Date: Mon Aug 7, 2006 7:24 pm
Subject: DOM inspector features i requested that would be extra useful for XBL-developers steltenpower
Offline
Send Email

http://bugzilla.mozilla.org/show_bug.cgi?id=347723
     non-XBL variant of a document

http://bugzilla.mozilla.org/show_bug.cgi?id=347717
     allow namespace related background colors on elements and attributes

http://bugzilla.mozilla.org/show_bug.cgi?id=347718
     a table with DOM elements versus eventhandlers

Reply | Forward | Messages in this Topic (1)

#32 From: "steltenpower" <yahoo@...>
Date: Fri Aug 4, 2006 11:47 am
Subject: future version of DOM inspector will show namespace of attributes steltenpower
Offline
Send Email

That's a feature i guess XBL developers could really use.
I've got it working in Firefox 3, i was told it's not yet available in
Firefox 2 :-(
Though it will take a while before it's in a regular release, the
functionality could of course be added earlier through an extension.

Reply | Forward | Messages in this Topic (1)

#31 From: "steltenpower" <yahoo@...>
Date: Wed Jun 21, 2006 11:00 pm
Subject: W3C XBL2 draft version released steltenpower
Offline
Send Email

http://www.w3.org/TR/xbl/
last updated June 19th, 2006

Reply | Forward | Messages in this Topic (1)

#30 From: "chaosvoyager" <chaosvoyager@...>
Date: Mon Jun 5, 2006 12:00 am
Subject: What I wanted XBL for. chaosvoyager
Offline
Send Email

"What (do you think) is XBL for?"

A very good question.

The way I found XBL in the first place was by answering this question
in reverse. I knew exactly what I wanted to do, and knew that XSL,
XForms, and SVG/CSS/Javascript were not capable of addressing that need.

What I wanted to do was something like this:




<?xml version="1.0" ?>
<xhtml xmlns:my_widgets="http://xseed.us/xbl_lib/widgets_1_0.xbl">

<body>
    <my_widgets:menubar>
       <my_widgets:menu label="file">
          <my_widgets:menu label="open" onmousedown="open('file.xml')" />
          <my_widgets:menu label="save" onmousedown="save()" />
       </my_widgets:menu>
    </my_widgets:menubar>
</body>

</xhtml>




Notice there are no CSS or Script imports. I wanted to encapsulate the
default rendering style, event driven behaviors, and XML descriptions
in a single location, and use namespaces in the main document to avoid
name collisions (such as with the deprecated HTML menu tag). All the
necessary Javascript would be imported by the XBL file, and additional
CSS files could be added to the main document to style XBL defined
tags beyond their defaults.

I also wanted to be able to design an individual tag much like I would
a webpage, with all the imported CSS and Javascript behaving as expected.

And finally it had to be possible for the XML structure of a tag
definition to change without affecting the structure of the main
document. If it DID change the main document's structure, then any
scripts that depended on that structure would need to be changed as
well (This is what shadow nodes provide).

XBL is the technology that came closest to providing these capabilities.



BTW I know I'm using the XML namespace URL in a way it wasn't designed
for. This was the cleanest way I could think of to import a set of
tag definitions into a document, and associate them with a
namespace. If necessary the same could be done with a custom importing
tag like used with scripts.

Reply | Forward | Messages in this Topic (3)

#29 From: "westonmr" <westonruter@...>
Date: Thu May 25, 2006 7:17 pm
Subject: XBL encapsulation issue: private member properties? westonmr
Offline
Send Email

A binding that I am developing has various properties. Some of the properties have side effects when setting them like the disabled property for html:form elements. Because of this, setting the property must be done through a setter, and the property must not be accessible to the outside by any other means. The properties are not associated with any anonymous content nor with any CSS properties. They are just properties of the JS object and do not appear in the DOM.

I coded an example to illustrate the issue I am having. I try to define a property called visible and then I create getters and setters for that property. The constructor and getter/setter reference this.visible, but this causes the error: too much recursion. To get around this, I created an alternate "hacked" binding that uses this._visible to store the state when the visible property is get or set. However, doing this results in _visible being publicly accessible without having to go through the getter/setter. (Remember, this is just an illustration. Storing the visibility state in the style.visibility property is not the answer as the binding I am developing does not have such properties.)

Any input you have would be appreciated. The bindings are located in testcase.xml.

Here's the example's URL: http://www.linguiste.org/projects/xbl-encapsulation/testcase.html

Thanks!
Weston

Reply | Forward | Messages in this Topic (1)

#28 From: "steltenpower" <yahoo@...>
Date: Fri Apr 28, 2006 1:25 am
Subject: MozXBL1 snapshot functionality working steltenpower
Offline
Send Email

With great help from jwatt i fixed the final bit, see
http://www.steltenpower.com/xbl/

Improvements welcome.

Reply | Forward | Messages in this Topic (1)

#27 From: "steltenpower" <yahoo@...>
Date: Thu Apr 27, 2006 9:27 pm
Subject: Mozilla XBL2 developments steltenpower
Offline
Send Email

All i know is http://svg.org/story/2006/2/22/15939/0633

>>http://the-philosopher-stoned.blogspot.com/2006/04/why-i-gave-up-on-mozilla.ht\
ml
> > The article is on MozXBL(1)

> from article:
> "could have made XBL an amazing technology and changed the face of web
> development, but they stopped just shy of greatness."
>
> What is (informative:))happening at Mozilla with XBL(2)?

Reply | Forward | Messages in this Topic (3)

#26 From: Michael Bolger <michael@...>
Date: Thu Apr 27, 2006 10:46 am
Subject: Re: blogpost stating why basic idea of XBL rocks, but implementation sucks svgfoundation
Offline
Send Email

steltenpower wrote:
>
http://the-philosopher-stoned.blogspot.com/2006/04/why-i-gave-up-on-mozilla.html
> The article is on MozXBL(1)
>
from article:
"could have made XBL an amazing technology and changed the face of web
development, but they stopped just shy of greatness."

What is (informative:))happening at Mozilla with XBL(2)?

cheers
michael
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

Reply | Forward | Messages in this Topic (3)

#25 From: "steltenpower" <yahoo@...>
Date: Tue Apr 25, 2006 8:44 pm
Subject: make XBL as easy as possible to try out: simple web-based tool steltenpower
Offline
Send Email

To bring in more use cases I'm thinking w3schools.com style:

MozXBL1:
Say you have 3 editable TEXTAREA's (data, CSS, XBL) plus the result.

feel welcome to implement :-)

Ruud



PS:
so far would be great, but dreaming on:
- view as 'plain' XML (gives free syntax coloring, Well-Formedness
check, collapsability) instead of editable (3 switches)
- validate with the unofficial XBL1 RNG Schema.
- DOM inspector area
- snapshot capability

Reply | Forward | Messages in this Topic (1)

#24 From: Michael Bolger <michael@...>
Date: Tue Apr 25, 2006 4:55 pm
Subject: What is the best way forward for the purist/clean sXBL/XBL svgfoundation
Offline
Send Email

What is the best way forward for the purist/clean sXBL/XBL?
regardless of any browser affiliation:)

Also the impact/best practices/thoughts on
  CSS3 and E4X respectively toward sXBL/XBL?


Introduction to CSS3
http://www.w3.org/TR/css3-roadmap/

Standard ECMA-357
ECMAScript for XML (E4X) Specification
2nd edition (December 2005)
http://www.ecma-international.org/publications/standards/Ecma-357.htm
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-357.pdf

thanks
michael

Reply | Forward | Messages in this Topic (1)

#23 From: Michael Bolger <michael@...>
Date: Tue Apr 25, 2006 4:39 pm
Subject: Comments on a quote from "An early look at sXBL" svgfoundation
Offline
Send Email

Hi, started a  page  at  http://www.svgx.org
with the following quote:
"sXBL works much like XSLT. More specifically, it works like a special
kind of XSLT stylesheet called literal result element used as stylesheet
-- that is, an sXBL stylesheet (the spec doesn't actually use the word
stylesheet, but that's how I think of it) is an SVG document. This
document can contain content from other namespaces. It also specifies
bindings between elements in those namespaces and particular SVG shapes.
When an SVG processor renders the complete document, it replaces the
content from other namespaces with their SVG bindings. Any elements from
other namespaces that are not bound to SVG elements are simply dropped
out."
-- Elliotte Rusty Harold

Any comments here or off-list would be appreciated as to proceeding
clearly (to me:)).
Kurt and others have written many fine things about sXBL/XBL.

thanks
Michael

Reply | Forward | Messages in this Topic (6)

#22 From: "steltenpower" <yahoo@...>
Date: Tue Apr 25, 2006 2:55 am
Subject: I put it on-line: coding MozXBL1 snapshot functionality steltenpower
Offline
Send Email

http://steltenpower.com/xbl/xbl1.xml
call "view source"
use the DOM inspector
then call javascript:viewShadowSource();
and in the new window call "view generated source" (webdeveloper
extension)
What needs to be done:
-remove all non-binding stuff out of the stylesheet, so both pictures
should turn out the same
-change the weird HTMLdocument into a real SVGDocument, including
namespace
-clean up the code. I copy-pasted a bit within the code. It could use
some jslint.com too

I hope you like it.
Ruud


> > 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.

Reply | Forward | Messages in this Topic (6)

#21 From: "steltenpower" <yahoo@...>
Date: Mon Apr 24, 2006 3:21 am
Subject: coding MozXBL1 snapshot functionality (Re: build a XBL (web)app, save a snapshot steltenpower
Offline
Send Email

> 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();
>

just a few bugs left (if only Venkman didn't crash Mozilla every few
moments):

function process(shadowchunk){
   var path=shadowchunk.getAttribute("stelt:path");
   var clonechunk=shadowchunk.cloneNode(true);
   clonechunk.removeAttribute("stelt:path");
   if (path==="root") {newdoc.documentElement.appendChild(clonechunk);}
   var insertshortlist;
   insertshortlist=clonechunk.getElementsByTagName("stelt:insert");
//insertshortlist=clonechunk.getElementsByTagName("http://some.temporary.com","i\
nsert");
would this be different ?
   alert("insertshortlist.length="+insertshortlist.length);//  0 which
is not expected
   var insertchunk;
   if (insertshortlist.length==1){
     insertchunk=insertshortlist[0];
     insertpoints[path]=insertchunk;
   }
   if (path!="root"){
     var parentpath=path.substring(0,path.lastIndexOf("_"));
     alert(insertpoints["root"]); //UNDEFINED
     var insertpoint=insertpoints[parentpath];
     insertpoint.parentNode.insertBefore(clonechunk, insertpoint);
   }
}
function addShadow(chunk){
   var anonylist=null;
   var i;
   try{
     anonylist=document.getAnonymousNodes(chunk);
   }catch(e){
	  //alert("caught error");
   }
   var n;
   if  (anonylist===null){n=0;}
   else {n=anonylist.length;}
   if (n>0){
     for (i=0; i<n; i++) {process(anonylist[i]);}
   }
   var list=chunk.childNodes;
   n=list.length;
   if (n>0){
     for (i=0; i<n; i++){ addShadow(list[i]);}
   }
}
function viewShadowSource(){
   var newwin=window.open(); //Exception
   newdoc=newwin.document;
   insertpoints={};
   var thisdoc=document.documentElement;
   addShadow(thisdoc);
   var longlist=newdoc.getElementsByTagName("stelt:insert");
   var n=longlist.length;
   var node;
   for(var i=0;i<n;i++){
     node=longlist[i];
     node.parentNode.removeElement(node);
   }
}

Reply | Forward | Messages in this Topic (6)

#20 From: "steltenpower" <yahoo@...>
Date: Mon Apr 24, 2006 12:48 am
Subject: blogpost stating why basic idea of XBL rocks, but implementation sucks steltenpower
Offline
Send Email

http://the-philosopher-stoned.blogspot.com/2006/04/why-i-gave-up-on-mozilla.html
The article is on MozXBL(1)

Reply | Forward | Messages in this Topic (3)

#19 From: "steltenpower" <yahoo@...>
Date: Sat Apr 22, 2006 4:46 am
Subject: Re: build a XBL (web)app, save a snapshot of the visualisation, no bitmap but SV steltenpower
Offline
Send Email

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
>

Reply | Forward | Messages in this Topic (6)

#18 From: Cameron McCormack <cam@...>
Date: Sat Apr 22, 2006 1:37 am
Subject: Re: Re: first post: What flavors of XBL are there? heycam_yg
Offline
Send Email

Jeremy Bowers:
> I added the xmlns declaration to your first svg tag, because I think you
>   need it and I need it for my point.
>
> This won't work. The 'abbreviation' of the namespace ("ex" and "ge"
> here) aren't supposed to have any real meaning. In:
>
> <somenode xmlns:a="http://a.uri.com/x" xmlns:b="http://a.uri.com/x">
>    <a:x />
>    <b:x />
> </somenode>
>
> there's no difference between the two "x" tags (other than order, of
> course); the tags aren't in "two namespaces", they both go to the same
> namespace.
>
> Distinguishing between the two prefixes would be a misfeature. An XML
> parser really shouldn't give you enough information to tell the two
> apart; if it does, you *certainly* shouldn't use it.

Yeah, it seems a bit dodgy somehow to rely on the prefix that was used
(especially since the element may have been created in a namespace but
without a prefix using createElementNS).  (A namespace mapping, as can
be done in XSLT, would be possible, but this doesn't seem much nicer.)

Putting the shadow tree inside the element is cleaner than having it
beside the element, though.

> XBLinJS actually does require that every widget have one and only one
> top-level node, which works in HTML because we can almost always use
> span and div. I don't know if SVG has a similarly "neutral" collection
> tag. (It should, though; anything implementing DOM events should have
> such a node so you can put the event handlers in the right place, once.)
> Everything under that widget node is assumed to belong to that widget,
> although there may of course be other widgets below that.

Yes, SVG has the 'g' element, which is a group.  Some bindings care
about the children of bound elements, so this problem of shadow trees
being visible in the real DOM still exists.  The bindings would have to
know to ignore the shadow tree container.

Anyway, I think the summary is that it's impossible to have a complete
implementation of any of the XBLs in script, but you can do a reasonable
job if you are careful.

--
  Cameron McCormack 	 ICQ: 26955922
  cam (at) mcc.id.au 	 MSN: cam (at) mcc.id.au
  http://mcc.id.au/ 	 JBR: heycam (at) jabber.org

Reply | Forward | Messages in this Topic (13)

#17 From: Jeremy Bowers <jerf@...>
Date: Fri Apr 21, 2006 4:53 pm
Subject: Re: Re: first post: What flavors of XBL are there? jerfb
Offline
Send Email

Kurt Cagle wrote:
> What if there was a central requirement that the shadow tree
> 1) had to be contained within the element,
> 2) had to be in a namespace with a different prefix than the dominant
> namespace - i.e.,
> 3) you worked with wrapper methods that were sensitive to that prefix.
>
>   <svg xmlns="http://www.w3.org/2000/svg" ...>
>     <g id="stuff">
>       <ex:star cx="100" cy="100" numpoints="5" r="100" r2="50">
>         <!-- This is the shadow tree for the ex:star element -->
>          <ge:g xmlns:ge="http://www.w3.org/2000/svg">
>             <ge:path d="..."/>
>          </ge:g>
>       </ex:star>
>     </g>
>     <script>
>          // my script
>     </script>
>   </svg>

I added the xmlns declaration to your first svg tag, because I think you
   need it and I need it for my point.

This won't work. The 'abbreviation' of the namespace ("ex" and "ge"
here) aren't supposed to have any real meaning. In:

<somenode xmlns:a="http://a.uri.com/x" xmlns:b="http://a.uri.com/x">
    <a:x />
    <b:x />
</somenode>

there's no difference between the two "x" tags (other than order, of
course); the tags aren't in "two namespaces", they both go to the same
namespace.

Distinguishing between the two prefixes would be a misfeature. An XML
parser really shouldn't give you enough information to tell the two
apart; if it does, you *certainly* shouldn't use it.

XBLinJS actually does require that every widget have one and only one
top-level node, which works in HTML because we can almost always use
span and div. I don't know if SVG has a similarly "neutral" collection
tag. (It should, though; anything implementing DOM events should have
such a node so you can put the event handlers in the right place, once.)
Everything under that widget node is assumed to belong to that widget,
although there may of course be other widgets below that.

Reply | Forward | Messages in this Topic (13)

#16 From: "Kurt Cagle" <kurt.cagle@...>
Date: Fri Apr 21, 2006 6:56 am
Subject: Re: Re: first post: What flavors of XBL are there? kurt_cagle
Offline
Send Email

What if there was a central requirement that the shadow tree
1) had to be contained within the element,
2) had to be in a namespace with a different prefix than the dominant namespace - i.e.,
3) you worked with wrapper methods that were sensitive to that prefix.

<svg ...>
    <g id="stuff">
      <ex:star cx="100" cy="100" numpoints="5" r="100" r2="50">
        
         <ge:g xmlns:ge="http://www.w3.org/2000/svg">
            <ge:path d="..."/>
         </ge:g>
      </ex:star>
    </g>
    <script>
         // my script
    </script>
</svg>

It'd not be perfect, and we're beginning to stray away from either the Mozilla or W3C XBL implementations, but I think you could do something if you were consistent.

It's late, and i'm not thinking clearly, so let me noodle more on this, but I think there may be a way to provide even better encapsulation.

-- Kurt

On 4/20/06, Cameron McCormack <cam@...> wrote:

Kurt Cagle:

> Not completely sure about that. I do agree that it would probably be
> fairly inefficient, but I'm not sure that a Javascript shadow tree
> arrangement would be out of the realm of possibility. Been thinking
> about implementing something like that for IE anyway, so I can start
> developing cross platform bindings without getting locked in JS
> spaghetti code.

I don't think it would be that inefficient, but there'd be the issue of
having things like:

<svg ...>
    <g id="stuff">
      <ex:star cx="100" cy="100" numpoints="5" r="100" r2="50"/>
      <g>
        
        <path d="..."/>
      </g>
    </g>
    <script>
      for (var n = document.getElementById("stuff"); n;
           n = n.nextSibling) {
        if (n.nodeType == Node.ELEMENT_NODE) {
          // do something with every element child of "stuff"
        }
      }
    </script>
</svg>

where you might trip over the 'g' element that is effectively the shadow
tree of the ex:star element.

--
Cameron McCormack                  ICQ: 26955922
cam (at) mcc.id.au                  MSN: cam (at) mcc.id.au
http://mcc.id.au/                  JBR: heycam (at) jabber.org

YAHOO! GROUPS LINKS

Visit your group "xbl-developers" on the web.

To unsubscribe from this group, send an email to: xbl-developers-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

--
Kurt Cagle
http://www.understandingxml.com

Reply | Forward | Messages in this Topic (13)

#15 From: Cameron McCormack <cam@...>
Date: Fri Apr 21, 2006 6:04 am
Subject: Re: Re: first post: What flavors of XBL are there? heycam_yg
Offline
Send Email

Kurt Cagle:
> Not completely sure about that. I do agree that it would probably be
> fairly inefficient, but I'm not sure that a Javascript shadow tree
> arrangement would be out of the realm of possibility. Been thinking
> about implementing something like that for IE anyway, so I can start
> developing cross platform bindings without getting locked in JS
> spaghetti code.

I don't think it would be that inefficient, but there'd be the issue of
having things like:

   <svg ...>
     <g id="stuff">
       <ex:star cx="100" cy="100" numpoints="5" r="100" r2="50"/>
       <g>
         <!-- This is the shadow tree for the previous ex:star element -->
         <path d="..."/>
       </g>
     </g>
     <script>
       for (var n = document.getElementById("stuff"); n;
            n = n.nextSibling) {
         if (n.nodeType == Node.ELEMENT_NODE) {
           // do something with every element child of "stuff"
         }
       }
     </script>
   </svg>

where you might trip over the 'g' element that is effectively the shadow
tree of the ex:star element.

--
  Cameron McCormack 	 ICQ: 26955922
  cam (at) mcc.id.au 	 MSN: cam (at) mcc.id.au
  http://mcc.id.au/ 	 JBR: heycam (at) jabber.org

Reply | Forward | Messages in this Topic (13)

#14 From: "Kurt Cagle" <kurt.cagle@...>
Date: Fri Apr 21, 2006 5:55 am
Subject: Shadow Nodes kurt_cagle
Offline
Send Email

Re: shadow nodes and event binding

I think that the only things that you wouldn't be able to do with a
Javascript implementation of an XBL would be obscuring the shadow
trees, especially if you implement your own AnonymousElement methods
(easy enough to do with XPath), and then deal with the problem of id
collision by using an anonid type attribute. It's not perfect (in
fact, its more than a bit of a kludge, even in Mozilla) but this
should also make it possible to create the requisite change events,
unless I'm missing something really profound here.

I'd also recommend taking a look at the extant XForms implementations,
especially something like Orbeon. The XForms eventing model is not
that different, and I could see adapting the code they've developed to
handle a more generalized XBL.

-- Kurt

--- In xbl-developers@yahoogroups.com, Cameron McCormack <cam@...> wrote:
>
> Jeremy Bowers:
> > Interesting. If I'm reading the definition of "shadow tree" correctly,
> > I consider it one of the *advantages* of XBLinJS that it uses *real*
> > nodes and not half-implemented "shadow" nodes.
> >
> > My experience was with Mozilla around 1.7, and the shadow node
> > implementation was disasterously buggy, compared to real nodes.
> >
> > Can you tell me why you *need* "shadow trees", rather than real DOM
> > nodes created via createElement?
>
> In a word, encapsulation.  Having the shadow nodes inside a shadow tree
> that is connected to the element, and not in the real DOM, affords some
> level of encapsulation.  True, it's not that well encapsulated because
> you can always get to the shadow content through an attribute on the
> bound element, but it does keep the implementation elements separate
> from the main DOM.
>
> > (My goal with XBLinJS is to have a *real* feature match with XBL, not
> > to match implementation-detail for implementation-detail. If "shadow
> > nodes" are just "how it's done" and not an actual feature of some kind
> > providing direct benefit to the end programmer, I don't consider "it's
> > missing shadow nodes" to be a valid criticism.)
>
> Sure, I don't think shadow trees are really necessary for
> form/presentation separation.  It's just a bit cleaner, IMO.  Especially
> when you have nested bound elements.
>
> --
>  Cameron McCormack 	 ICQ: 26955922
>  cam (at) mcc.id.au 	 MSN: cam (at) mcc.id.au
>  http://mcc.id.au/ 	 JBR: heycam (at) jabber.org
>

Reply | Forward | Messages in this Topic (13)

#13 From: "Kurt Cagle" <kurt.cagle@...>
Date: Fri Apr 21, 2006 5:36 am
Subject: Re: first post: What flavors of XBL are there? kurt_cagle
Offline
Send Email

> I've wondered before whether an implementation of sXBL in script would
> be viable (to get more people to try using it in UAs other than Batik),
> but of course it's not possible to implement completely correctly, since
> there's no way to have real shadow trees.

Cameron,

Not completely sure about that. I do agree that it would probably be
fairly inefficient, but I'm not sure that a Javascript shadow tree
arrangement would be out of the realm of possibility. Been thinking
about implementing something like that for IE anyway, so I can start
developing cross platform bindings without getting locked in JS
spaghetti code.

-- Kurt

Reply | Forward | Messages in this Topic (13)

#12 From: Michael Bolger <michael@...>
Date: Thu Apr 20, 2006 12:08 pm
Subject: Re: What (do you think) is XBL for? svgfoundation
Offline
Send Email

>Your reactions please.
  >Ruud

Very thankful you started this discussion,
shall have plenty of questions:)

cheers
Michael

Reply | Forward | Messages in this Topic (3)

#11 From: Cameron McCormack <cam@...>
Date: Wed Apr 19, 2006 11:01 pm
Subject: Re: Re: first post: What flavors of XBL are there? heycam_yg
Offline
Send Email

Jeremy Bowers:
> Interesting. If I'm reading the definition of "shadow tree" correctly,
> I consider it one of the *advantages* of XBLinJS that it uses *real*
> nodes and not half-implemented "shadow" nodes.
>
> My experience was with Mozilla around 1.7, and the shadow node
> implementation was disasterously buggy, compared to real nodes.
>
> Can you tell me why you *need* "shadow trees", rather than real DOM
> nodes created via createElement?

In a word, encapsulation.  Having the shadow nodes inside a shadow tree
that is connected to the element, and not in the real DOM, affords some
level of encapsulation.  True, it's not that well encapsulated because
you can always get to the shadow content through an attribute on the
bound element, but it does keep the implementation elements separate
from the main DOM.

> (My goal with XBLinJS is to have a *real* feature match with XBL, not
> to match implementation-detail for implementation-detail. If "shadow
> nodes" are just "how it's done" and not an actual feature of some kind
> providing direct benefit to the end programmer, I don't consider "it's
> missing shadow nodes" to be a valid criticism.)

Sure, I don't think shadow trees are really necessary for
form/presentation separation.  It's just a bit cleaner, IMO.  Especially
when you have nested bound elements.

--
  Cameron McCormack 	 ICQ: 26955922
  cam (at) mcc.id.au 	 MSN: cam (at) mcc.id.au
  http://mcc.id.au/ 	 JBR: heycam (at) jabber.org

Reply | Forward | Messages in this Topic (13)

#10 From: Jeremy Bowers <jerf@...>
Date: Wed Apr 19, 2006 9:33 pm
Subject: Re: Re: first post: What flavors of XBL are there? jerfb
Offline
Send Email

Doug Schepers wrote:
> Hi, Jeremy-
>
> As I understand it, the advantage of shadow-trees is in their direct
> connection with the source elements, in terms of structure, semantics, and
> liveness.

Ah, yes, that makes sense.

One of my basic objections about the way this stuff is being engineered
is that everything you mentioned is dependent upon being able to
subscribe to changes. There's no reason to lock up this ability in XBL
alone; even within an XBL-implementation proper it would be very useful
to be able to explicitly say "call this code when this changes"; you
might want to make decisions about which callback gets registered, for
instance, or you might want to be able to respond to events not directly
connected to the nodes of this particular XBL object. (This came up for
me a couple of times when I wanted something like an overarching
"table"-type manager, with specialized and sometimes heterogenous table
"rows" and "cells", or when there was something that's a sibling in the
DOM tree that I wanted to attach to some other element's input.)

You are correct that at this time, I can't replicate that feature in
scripting. However, this is not a fundamental advantage of XBL and a
fundamental failure of scripting; this is a failure to expose the
relevant change events to scripting control.

I have also yet to encounter a need for any of that in practice, as a
web developer. Out of curiousity, have you *used* this feature in any
significant way? I'm certainly expecting the answer could be "yes", I'm
genuinely curious.

> I read your XBLinJS page, and the erm... "strongly worded warning"... You
> made some interesting points, but you were mostly attacking a particular
> implementation of XBL, and the very idea of using XML at all. I guess that
> I'm not sure how your library is like XBL. Without condemning your approach
> of converting data via JS (which I use myself), you are eschewing XML,
> removing the bindings, and creating a library (rather than a language). So,
> there isn't an X, B, or L. ;)

My library is like XBL because, excepting the shadow node feature you
mention above, it works just like XBL if you describe what you're doing
with XBL without explicit references to XML. You "create widgets" that
can "bind to nodes" and "respond to events", carry their own specialized
methods, can include each other, can do inheritance (although XBLinJS
gets JS's inheritance model which is unbelievably easier to work with
than the one in Mozilla's XBL), etc.. The design process is the same;
you don't slap down HTML and start hacking together Javascript and
hard-coded event handlers (the old way of doing such things), you create
"widgets" that are much better encapsulated and use those to create the
discrete behaviors you want.

That is, it does the same sorts of things with the same organizational
principles coming into play. Hence, XBLinJS. It is true that it has
neither X nor L (there is some "B", actually, but as there is no direct
browser support it's somewhat more manual, although easily automated;
and that's another thing the broser could support directly, instead of
locking the capability into XBL), but I consider that incidental to the
entire "widgets-in-DOM" that XBL defines.

For what it's worth, I have very little hope or intention of converting
anybody. Mostly I'd be happy if someday XBLinJS makes someone take a
fresh look at XBL and ask why certain things are so darned hard when
they don't have to be, and question whether the putative benefits of the
X outweight the costs.

Reply | Forward | Messages in this Topic (13)

#9 From: "Doug Schepers" <doug@...>
Date: Wed Apr 19, 2006 9:07 pm
Subject: RE: build a XBL (web)app, save a snapshot of the visualisation, no bitmap but SVG d_a_schepers
Offline
Send Email

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

Reply | Forward | Messages in this Topic (6)

Yahoo! Groups Tips

Did you know...

Messages

Yahoo! My Yahoo! Mail
	Sign In New User? Sign Up
		Tech - Groups - Help

Yahoo! Groups Tips

Did you know...

Best of Y! Groups

Messages