On Tue, Oct 2, 2012 at 1:13 PM, Alex Harui <aha...@adobe.com> wrote: > > > > On 10/2/12 12:56 PM, "Om" <bigosma...@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, <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. > >> > >> > >> > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
