Quoting Om <bigosma...@gmail.com>:
I am very interested in building the design view as an AIR app. Lets talk
design/architecture now.
Here is a brain-dead architecture design of the AIR app, that lets the user
interactively drag and drop components, apply layouts, change labels/titles
etc.
Conceptually, this is simple enough. This contains the following
components:
1. Components list: We read the list of available components from a
manifest file and populate a toolbox on the side.
This is where the new compiler from my perspective could be really
fun. During the build of the app when "packaging" I could write
something that actually created this XML. You could use custom doc
tags in the source code even to add functionality (like @designview),
the comments, values, etc of the components could be written to XML as
well so you could have a wealth of information in the core
application. Just dreaming here.
2. Design area: This would be a container where we will draw the objects
I actually wrote a RuledCanvas component 3 years ago that exactly
mimicked fireworks interface with the sliding rulers, drag and drop
components onto the "floating canvas". I spent about 2 years on it. It
has rulers, snap, resize, move, guides a grid etc. hehe Search google
for ResizeManagerFX That was a commercial component I mad for Flex 2.
3. Interactive layer: Any object or group of objects in the design area
can be selected, resized, rotated, constrained.
See above.
4. Properties area: Properties such as: styles, skins, layout of selected
components could be changed here.
This could all be created in the build using the compiler to create
the XML manifest (see above). It would actually use the same type of
logic I have currently in the documentor I'm working on with Flacon.
5. Skins could be created/edited in the same way. They could also be
applied onto their corresponding Host Components as well.
6. Generate MXML: This is the part that I am unclear. My first thought
is to walk through the flash player display hierarchy and create an XML
containing all the components in the screen along with their properties and
styles. Feed this primitive XML into Falcon (lots of hand-waving here)
which spits out MXML. This MXML can be edited in the IDE.
This I would be listening to others as to the best implementation but
I know we might be able to even target the compiler from inside the
app right?
Bonus features:
1. Hooking up to Data services
2. Round-tripping between Design View <=> IDE
3. Writing Eclipse/IDEA plugins as wrappers around this AIR app so that it
can be integrated into IDEs.
This would be very interesting, I never though about it this way if
it's possible.
I *know* I am missing something obvious above. Please provide your
feedback so that we can iteratively fill out the design.
Thanks,
Om
On Tue, Oct 2, 2012 at 12:20 PM, <teoti...@teotigraphix.com> wrote:
Quoting Alex Harui <aha...@adobe.com>:
You are welcome to open a JIRA ticket for Apache Flex and try to see if
you
can define requirements in priority order. Remember that this is a
volunteer organization so you can't just say "replicate DV". What are the
most important aspects of DV? Is one of them IDE integration? If so,
why?
An AIR DV could certainly launch an ant script to build your changes.
Just reiterating on something I said in a previous post to this; If a
project could start, start small with a prototype only doing the basic.
Then slowly add functionality. This would be very important for an endeavor
like a DesignView.
I have written Eclipse plugins before, I have no idea how to write an IDEA
plugin, I looked and saw I would have to learn a very different framework.
With the new compiler and it's AST and definitions, it would make
something like this a whole lot easier, and I'm speaking from 2 weeks
experience with the code.
I want to mention one more thing here. Acting as a developer of something
like a design view, there is a huge overwhelming fear that it could lose
interest and get abandoned purely out of volunteers moving, or working on
other things. Loosing traction on a project like this when you spent time
developing it and know you could have been doing something else is always
in developers minds.
So add the risk factor as well. For years I have heard Flex developers say
they use it all the time to others saying it was a waste of time and time
should have been spent on the more important features.
Mike
PS On the plus side with an AIR implementation, being written with Flex
would be a boost to the whole project because you would be using the
framework components and creating new ones purely out of the need for the
new functionality. It could almost act as a live garden of growth for the
framework.
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
