Don and Alastair, Okay, I'm uber-busy right now, but I wanted to put in my two cents worth here.
XUL is a fixed vocabulary of widgets. However, XUL also contains the XBL language, which makes it possible to bind additional components based upon either XUL, XHTML or SVG (if you're using Firefox 1.1). Such bindings create the same kind of "code-behind" paradigm that XAML uses. Realistically, such components that are created through XBL are not "ostensibly" XUL objects - they would reside within their own particular namespaces - which again echoes what happens with XAML. XBL objects utilize ECMAScript binding currently because that's what Mozilla supports, but this isn't a strict requirement - bindings in Python and Ruby are both underway, and there's nothing to say that a MONO based C# binding implementation wouldn't be possible. Additionally, you also have the XML Tag Framework (XTF) which provides high performance, large-scale development of custom tag namespaces, something that is utilized in the Firefox 1.1 XForms implementation currently in late alpha. As a framework, SPARK is interesting, but I ultimately expect it to be superceded by some XBL variant relatively soon as Mozilla development shifts into high gear (such as the W3C's sXBL implementation, currently making its way down the pipes and that will likely end up merging with Mozilla XBL at some point). I'm not saying that XBLs are expressive as .NET code-behinds, but conceptually they aren't far apart, and there's a strong guarantee that XBLs will work across multiple operating systems. -- Kurt Cagle Alastair Fettes wrote > Hey Don, > > >IMHO, that is one of the major drawbacks > > of SPARK and XUL. > But that's not SPARK at all. That is one of the benefits I see of > SPARK over XUL or similar type languages. If you need a control, you > can add it fairly easily. There are predefined controls in the sense > that if someone hasn't created them before (or you haven't), then you > can't use it. But you can make it if you so desire and use it very > easily. I tried to show the endless possibilities (as opposed to the > finite in XUL) when I created a graph node widget last summer. > > http://spark.sourceforge.net/resources/samples/faq/createcontainer/graphnode2.svg > > > XAML does not have a schema, since it is open ended. Any .Net object > > can be expressed using XAML. > > So if XAML doesn't have a schema, what happens if you put in tags that > aren't part of the specification? It's still an XML vocabulary. The > meaning of the tags has to be predefined somewhere. I couldn't just > add an <alastair/> node if i wanted could i? > > >Alastair, if you could implement SPARK using Java, that would rock! > > Find me a spare week and I'll do it! heh. Well, better busy than bored. > > Cheers, > Alastair > > --- In [email protected], Don Demsak <[EMAIL PROTECTED]> wrote: > > > That is exactly what I was trying to get at. I understand that XAML > > > provides UI controls in a similar fashion to SPARK. This just gets > > > straight back to what my original statement was (though it was > > > originally done only have seriously): > > > > > XAML does not provide UI Controls. Avalon (the new GUI API) provides > > the UI Controls, and XAML can be used to express them XML form, rather > > then procedural code (via constructos and set properties). > > > > XAML does not have a schema, since it is open ended. Any .Net object > > can be expressed using XAML. IMHO, that is one of the major drawbacks > > of SPARK and XUL. They only understand a predefined set of controls, > > and provide the very limited ability to create custom controls. The > > old SVG-RSS part of the SVG 1.2 spec was a step in the right direction > > to give SVG the ability to create custom controls, but I've been out > > of the loop, and don't know what happened with that in the SVG 1.2 > > spec. > > > > XAML is the natural evolution of the Microsoft Element and Binary > > behaviors, and anyone who was around this board back in the 2000/2001 > > time frame knows how much I loved using element/binary behaviors with > > SVG. Element/Binary behaviors had a lot of flaws, but was a good > > proof of concept (definately not really ready for prime time though). > > A lot of the XAML team at MSFT were part of the team that created > > element behaviors. > > > > Alastair, if you could implement SPARK using Java, that would rock! > > > > Don > > > > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] > -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" > ---- > > > ------------------------------------------------------------------------ > *Yahoo! Groups Links* > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/svg-developers/ > > * To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/>. > > ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
