Good points. I have been thinking about how to address the problem
you mention(and it is a big problem): ' There's no way around a lot of
ugly and quite often pretty complicated ActionScript code square in the
middle of the Flash movie.' The only simple workaround I have thought for
this is to have XMLC create a "library" file that will contain all the
ActionScript necessary to access the xml. Then the designer could paste
this in...not too pretty, but at least it would free the designer from
having to write it, and ensure that the ActionScript conformed to the
xml. I would be interested in what you thought. I think there are
definitly advantages to both xmlc and generator approaches, and the answer
might not be whether to use one or the other, but instead to make them
easier for the designer/engineer and ensure some kind of separation...
talk to you soon,
On Wed, 14 Mar 2001, Richard Kunze wrote:
> On Wednesday 14 March 2001 21:00, you wrote:
> > I have seen items about JGenerator but the fact is
> > that XMLC beats JGenerator handsdown.
> Given that we're on an Enhydra mailing list, I don't think you need to
> convince *this* particular audience :-)
> > Why? Because XMLC already is a universal translator,
> > it works with any app server and outputs to any device
> > including Flash 5.0.
> > Why limit your application or design? With XMLC you
> > can Write the application ONCE and its instantly ready
> > for cell phones, Flash 5.0, palm pilots , ANY internet
> > device. XMLC is the universal translator, now.
> > And it's available both as Open Source only and a
> > supported version as well.
> Very true. But, one of the top philosophies in Enhydra and especially XMLC is
> "separate code and layout". And this goes completely haywire with Flash 5,
> especially if you want to use those nifty XML features. There's no way around
> a lot of ugly and quite often pretty complicated ActionScript code square in
> the middle of the Flash movie. From a code/layout separation perspective,
> that puts you right back to square one. True, you don't need to jump through
> hoops on the backend that feeds the Flash app, but that's not much comfort
> > Why would you limit your projects to JGenerator when
> > you can have the best NOW in XMLC? It's feature rich
> > and has been tried and true.
> No one told anything of limitating oneself to JGenerator, as far as I recall.
> JGenerator is a nice, working example of how to modify SWF from Java.
> On top of that, it's OpenSource, and that makes it a prime source of
> information for building a tool that enables XMLC to manipulate Flash on the
> server, with all the benefits attached. I can't speak for others, but that's
> my prime motivation to look at it ;-)
To unsubscribe from this mailing list, send email to email@example.com
with the text "unsubscribe designers" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at firstname.lastname@example.org.