Enterprise Project
About Enhydra Enterprise
Project Mail Lists
Working Groups
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

Flash is a strange tool in how it relates to traditional development. Flash
started out as strictly a graphics tool, which implicitly made it only
attractive to designers. The fact that it was a motion graphics tool and not
a static graphics tool like Photoshop or illustrator further narrowed down
its appeal to designers that felt comfortable with animation (I know plenty
designers who would slit there wrists before going into animation). The slow
and somewhat clumsy addition of a back-end set of functionality has created
an interesting development problem within design teams. Often I have found
that the graphic designers became designers b/c they didn't like
programming, and programmers became programmers because they liked coding or
lacked the natural artistic talent to be designers. With Flash's ever
expanding library of actionscript commands, traditional designers are
getting scared off but programmers are getting more intrigued. What I am
driving at here is that Flash is neither an attractive programming tool nor
a simple graphic development tool. The skills needed to create an
application interface that is both comprehensive and efficient with regards
to maintainability, scalability, and usability spans two skill sets that are
usually mutually exclusive. Designers don't want to be (or can't be)
programmers and programmers don't want to be (or can't be) designers. This
being the case, the task of developing a comprehensive solution falls onto
the project manager and or application architect - each of which who
probably have less understanding of Flash than the designer and the
programmer. We have seen efforts on the part of Macromedia to resolve the
separation of roles issue to some degree with the introduction of Smart
Clips and two modes of the code editor, but both in my mind fail to solve
the larger problem. The larger problem, in my opinion, is a lack of a high
level standard integration model. There is no standard method of
communication between Flash and the application it is serving. If Enydra is
looking to developed a solution that makes servlet and/or presentation
object functionality easier to integrate into Flash, then it seems that just
as much attention should be given to how Flash can be developed to integrate
closer with Enhydra. New to Flash 5 is the ability to include an external
actionscript file when exporting a movie. If a library of Flash functions
could be written to conform with a standard communication model that was
also support on the Enhydra side by its own class then a abstract method of
communication could be established. What I am envisioning here is some sort
of system similar to JSP's "usebean" or custom tag definition ability. This
would allow for a cleaner separation between Flash designer and application
developer. My XML-RPC suggestion was my first thought, but Flash should not
be written off in regards to its processing ability. Some
discussion/thought/experimentation should be put into determining where the
communication/processing tasks should be split between Enhydra and the
standard Flash include library that could be distributed with it.

Welcome any thoughts.


-----Original Message-----
From: owner-Designers@enhydra.org [mailto:owner-Designers@enhydra.org]On
Behalf Of Russ Duckworth
Sent: Monday, March 05, 2001 2:20 PM
To: Designers@enhydra.org
Subject: Re: Designers: Hello


> This cramped space becomes apparent
> when trying to work with even moderately sized XML documents.

Jordan,

I just thought I'd chime in here to talk about Flash 5, XML and Enhydra. So
far, in the 3 demo applications I've been working on (Airsent, Chess, and an
adventure-style multiplayer game) I haven't run into any serious performance
problems using XML data transfers. Of course, the nature of these apps is
such that they don't require incredible amounts of data to run. Airsent data
is pretty thin and the chess game need only transfer simple moving
instructions.... The adventure game was a different story. One of the ways
in which the game operates is by constant client updates every time another
player enters the game, moves, or performs any type of action. I decided to
format the XML so that it would as easy as possible to parse in Flash.
Here's an example of the transfer from client to server when a new player
enters the game:

<player name="Player1" type="elf" x="100" y="100 z="0" mhp="45" hp="39" />

Formatting our data transfers like this, as opposed to using nested tags,
greatly improved performance on the client side.

> The result of the
> external scan could then be passed back in via another lightweight XML
> document.

We agree then that this, and other kinds of compact formatting approaches
could be used to translate larger XML documents into the lightweight data
transfers you were talking about... It would be interesting to see if
Enhydra had some kind of built in mechanism for dealing with said files...

I'm curious to hear ideas about a Flash 5 demo app that would be required to
crunch large XML files. A purely informational site perhaps? A word
processor?

--
Russ Duckworth
design.lutris.com
831.460.7379
831.239.4204

----------------------------------------------------------------------------
-
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
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 owner-designers@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
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 owner-designers@enhydra.org.