incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Tue, 02 Oct 2012 20:59:02 GMT
On Tue, Oct 2, 2012 at 1:13 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> 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.
>


I can see where design-view extensions would come into play.  Do you have
any details on how they were implemented?  Is there a design-view
specialization of every component:  For example: Panel is extended by
DesignViewPanel?

In the end, I guess it really does not matter, because the model for the
view is stored as XML, right?


> > 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.


Makes sense.  We can update the XML while updating the component live.


> Then some other mapping can occur from the XML to MXML
> or HTML5 or whatever.
>

It would be awesome if we can target HTML5 using this as the entry point.
At least this would be a toss-it-over-the-wall solution which would work in
the first pass.



> >
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message