incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Tue, 02 Oct 2012 20:13:02 GMT



On 10/2/12 12:56 PM, "Om" <bigosmallm@gmail.com> wrote:

> 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.
> 2.  Design area:  This would be a container where we will draw the objects
> 3.  Interactive layer:  Any object or group of objects in the design area
> can be selected, resized, rotated, constrained.
Some alternatives are that each component provides its own interaction and
tries to utilize a library of interaction widgets so there is common look
and feel.  Or that you don't actually host a component at all, you host
"something else" that proxies the component.  Flash Pro hosts "live-preview"
swfs, for example. There are trade-offs to all approaches.   FB uses your
proposal, but there are tons of edge cases and these things called
design-view extensions used to make it actually work.
> 4.  Properties area:  Properties such as: styles, skins, layout of selected
> components could be changed here.
> 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.
Given we are looking at targeting multiple stacks, I would recommend simply
tracking what has been added and removed and outputting an XML
representation of it.  The display list is likely to be polluted with
interaction widgets.  Then some other mapping can occur from the XML to MXML
or HTML5 or whatever.
> 
> 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.
> 
> 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, <teotigra@teotigraphix.com> wrote:
> 
>> Quoting Alex Harui <aharui@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.
>> 
>> 
>> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message