On Tue, Oct 2, 2012 at 1:44 PM, Michael Schmalle <apa...@teotigraphix.com>wrote:
> 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. > > Dream on! We can always try things out and see if they work or not :-) > > 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. > > That is fantastic! I have written something similar, but that is proprietary code. I was planning to write everything from scratch. Any chance you could contribute your component to Apache Flex? > > 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. > > I am not clear on this. Can you please elaborate? Are you talking about re-opening a project in the design view? Or writing the properties to the XML? > > 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? We could invoke an ant script or a batch file from within the AIR app that triggers the compiler. Or even invoke the compiler directly as a NativeProcess. > > > > 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. > The current design view in Flash Builder is implemented as an AIR app. Look inside: \Adobe\Adobe Flash Builder 4.6\eclipse\plugins\com.adobe.flexbuilder.designview_4.6.0.328916 I have no idea how it is integrated into Eclipse as a view though. My best bet is that the AIR runtime is invoked inside an Eclipse plugin. The AIR runtime in turn invokes the design view air app. Sounds like fun :-) > > 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 > >
