incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sumit arora <er.sumitar...@gmail.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Tue, 02 Oct 2012 22:12:50 GMT
Hi,

I have worked on designing tools using flex and have fairly good
understanding of architecture reqd.
Please tell me if can help.

Regards,
Sumit Arora

On Tue, Oct 2, 2012 at 3: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.
> 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.
>
> 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.
> >
> >
> >
>



-- 
Sumit Arora
(Nothing is impossible it is only impossible untill you or someone else
finds the appropriate solution to it.
The only way to discover the limits of possible is to go beyond them into
the impossible.)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message