Re: [Adobe-source-devel] visual eve editor

[Ralph T. <ra...@gm...>]

Goodness! For the record, I agree that it would be nice to be able to
apply an XSLT (or similar) to an Eve definition.

I have a similar requirement, but was planning on using Lua to write
the view definitions in (and then write custom functions for the
things that can vary between platforms -- and just for complex
constructs that I want to reuse). I don't think it's possible to
round-trip Lua in an editor though (but it's probably not possible to
round-trip XML that has to be processed with XSLT either).

I imagine that it would be easier to write stylesheets for XML that
has no sub-syntaxes (I've only ever written very simple XSLTs to do
"join" type operations on webservices, though).

Ralph

On 12/15/06, Sean Parent <sp...@ad...> wrote:
>
> On Dec 15, 2006, at 9:11 PM, Ralph Thomas wrote:
>
> >  slider( value: 50, name: "a slider" );
> >
> > Whereas with XML, all attributes look like strings:
> >
> >  <slider value="50" name="a slider"/>
> >
> > Unless you make the syntax more verbose:
> >
> >  <slider>
> >    <attribute type="int" name="value">50</attribute>
> >    <attribute type="string" name="name">a slider</attribute>
> >  </slider>
>
> There are a couple of options here and nearly any choice has an
> example in common use - one is to have a two level parser - this is
> the approach of the XPath syntax when used in XSL. Here you would
> have something like:
>
> <slider value='50' name='(a slider)'/>
>
> Here we borrow the PDF syntax (xpath doesn't have a very rich type
> system) as a sub-syntax. The problem with this is if you allow
> complex expressions then you need a fairly complete sub-parser:
>
> button(items: ["OK", "Cancel"]); // simplified properties
>
> <button name='[(OK) (Cancel)]'>
>
> Getting to full expressions gets even more complicated - the approach
> used by XFA is to imbed full expression in the sub-syntax:
>
> <Calc>Quantity * UnitPrice</Calc>
>
> Borrowing from XFA (which is in some respects similar to Adam) may
> not be a bad idea.
>
> If we avoid the sub-syntax then following the lead of MXML is likely
> a way to go:
>
> <mx:Array>
>    <mx:String >OK</mx:String>
>    <mx:String>Cancel</mx:String>
> </mx:Array>
>
> A common request is for the embedding of Eve descriptions in MXML
> (has a lot to do with where I work :-) ). Larry sent me a paper at
> one point on extending MXML which is related.
>
> There is also the option of simply imbedding CEL in XML - this would
> allow for structural manipulation using XSL (a big advantage of an
> XML syntax) and we'd get away with our existing CEL parser. This
> would require escaping which is also done with XPath in XSL.
>
> Here we might have something like:
>
> <slider value='50' name='&quot;a slider&quot;'/>
>
> This would likely be the approach for xstrs - so we could have the
> very verbose:
>
> slider(value: 50, name: "<xstr id='slider'>a slider</xstr>"); // CEL
> syntax
>
> <slider value='50' name='&quot;&lt;xstr id=&apos;slider&apos;&gt;a
> slider&lt;/xstr&gt;'>
>
> Oh what fun!
>
> I think what is needed more than an XML expert is a customer - so
> far, anytime someone has asked for an XML syntax (and this happens
> often) there isn't any use case that warrants it. The question comes
> up enough though that I get tired of answering it and one solution
> might be to just pick _any_ XML syntax. The one major exception being
> the answer "I want to use Adam/Eve with Flex" but that requires more
> than just a move to an XML syntax - but I am interested in this
> project if I can find the bandwidth (or volunteers).
>
> At some point, I want to tackle style sheets for Eve - For example,
> be able to have styles for the OK-Cancel cluster being on the top-
> right (Photoshop style) - bottom-right (Mac style) or bottom
> distributed (Windows style) - this kind of structural manipulation is
> a natural use case for XSL but I haven't had time to explore. Oddly
> though, I don't have others asking for this capability.
>
> Sean