On Saturday, Mar 1, 2003, at 20:29 US/Pacific, S. Isaac Dealey wrote:
> Granted, part of the reason I have a tough time adjusting to the Flash
> MX UI
> may be largely because I've not read much of the documentation on how
> to
> accomplish these sorts of things with ActionScript. But I suspect also
> that
> if a focus were given to developing that sort of tool (emphasis on
> text vs.
> the visual stage) that the documentation would also follow that
> approach and
> focus on doing things with code, the way we're used to.
Well, as I say, we mostly have just a line of code in our .fla that
says:
#include "Stuff.as"
and then use DWMX to write Stuff.as and all the other .as files that it
includes. Everything can be done in pure text mode. Then you just
"publish" to .swf using the Flash MX tool.
Admittedly, some component and layout issues are much easier to achieve
in the authoring tool than in pure ActionScript but the work you do in
the authoring environment can be minimal.
> documentation for Flash MX as difficult to use as the interface itself
> (and
> it's easily broken by changes to the JVM on the host machine), so I
> don't
I don't follow you - what has Flash MX got to do with the JVM?
> I suppose for starters, this url needs to not produce a 404 error:
>
> http://livedocs.macromedia.com/flashmxdocs/dochome.jsp
Well, we don't have livedocs for every product yet, see:
http://livedocs.macromedia.com/
for what is available today. We're looking at putting other
documentation online (although the LiveDocs system really needs a bit
of an overhaul before we can do that!).
> I think there's a lot of merit in the previous suggestion of a
> Flash authoring tool (or mode in the existing tool) that relegates the
> stage
> off to a pull-down menu somewhere or a separate window all-together as
> a
My default Flash environment layout has the Actions panel as its focus
(when I write "little" movies I still do all the scripting direct
inside Flash. I only switch to the stage if I want to lay some things
out visually.
> default authoring environment, if for no other reason than that it
> forces
> the documentation to be changed to cater to us cf developers who are
> used to
Of course, you also need to consider that there are about three times
as many Flash users as there are ColdFusion users but your point is
well taken - "Flash developer" documentation will likely be structured
very differently from "Flash designer" documentation.
> Again, playing devil's advocate, I think the problem that some CF
> developers
> have had with Contribute (myself not included, so I'm sure I'm not
> really
> speaking for anyone in particular), is that it's seen as a waste of
> resources which might have otherwise been spent on more ColdFusion
> Server
> development.
Well, the Contribute team is a totally separate group of people to the
CF server team, with a different skill set. If we hadn't had those
people build Contribute, they certainly wouldn't have worked on CF. And
there's only a certain number of people you can reasonably have all
working on the same code base at any one time if you want to stay
efficient. The argument that Contribute took resources away from CF
server is, frankly, a very silly one indeed!
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Get the mailserver that powers this list at http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
