Cool idea, Derrell. See my comments at the bottom...
On Wed, 2009-10-07 at 12:24 -0400, Derrell Lipman wrote:
> For a many months, I've considered what an advanced, easy-to-use
> development environment for qooxdoo applications would look like. A
> few weeks ago, just before he published it as a contrib, Dan Hummon
> demonstrated to me his Tartan Blueprint Designer, and he and I
> discussed some of the ideas I've been considering. Although there is
> overlap, I think his project and what I have in mind are towards
> somewhat different purposes. Dan stated, "I do want to stress that,
> I'm envisioning the designer as a form designer; not as a full
> application designer." What I have in mind, on the other hand, is an
> application designer that also handles communication with a server. I
> suspect that at some point, the two may merge, but having two parallel
> development paths right now also allows experimenting with different
> implementations.
>
> Until recently, I've had no time to even begin a project of this
> scope. To get it to the point I dream of will be a huge project. Since
> I'm back in grad school now, though, I have decided to do a Phase I of
> this as my term project for my Human Computer Interaction course.
>
> I'm thinking of a (partial) feature list akin to this, implemented in
> in various phases:
> * View "running" qooxdoo application as it's being built,
> allowing for incremental development
> * Show dynamically-generated qooxdoo source code (nicely color
> coded and formatted, of course)
> * Save work in progress, and come back later to edit further
> * Edit properties and events, with API documentation available
> upon request or via pop-ups similar to what's done in NetBeans
> * Allow for addition of code to provide event handlers and
> special processing... with the ability for the additional code
> to be "attached" to an object placed during the design,
> allowing for moving objects around and retaining their
> associated added code
> * Easy use of remote procedure calls. Possibly, even the backend
> stubs could be automatically created
> * Form processing
> * Subclass creation and easy re-use
> * Pluggable architecture, allowing for contribs or user-provided
> classes to be easily added and used just like native classes
> * Maybe, just maybe, I could even do on-the-fly parsing and flag
> errors in the user-provided code, as is done in formal IDEs
> * ...
> Clearly, this is no small project. :-) My plan is to make a start on
> this for my term project, and before doing so, I'd like to solicit
> comments and suggestions from my target audience: all of you qooxdoo
> application developers!
>
> 1. What do you find to be your most time-consuming or tedious
> tasks while developing qooxdoo applications?
> 2. If you could have a tool to handle various aspects of your
> qooxdoo application development, what aspects would those be,
> and what would you hope the tool would do for you?
> 3. What is your current qooxdoo application development
> environment, and in it, what features do you find lacking and
> what features are critical to you?
> 4. Please add any additional comments or suggestions
1. Most tedious aspect of Qooxdoo is jumping between the script source
file and the API screen to find a parameter or method, not knowing
exactly which class to examine for it, discovering that Inherited class
elements are turned off, waiting for the list to update, scrolling up
and down between Properties and methods, then jumping back to my source
file and trying to remember where I was at the time and what I was
looking to find, then sometimes having to jump back to the API once I
remembered the goal. In a few instances, I also jump to the demo
browser to see how the feature might have been implemented there, ending
up searching around for a proper demo because they're organized
differently than the class structure. Some of this is likely my age and
some of it is my relative newness to Qooxdoo, but I find it severely
limiting my ability to create the Qooxdoo application in a timely
fashion.
2. There are two really helpful aspects to any IDE for me. First,
being able to move smoothly between an object layout environment and the
code environment, ideally in a side-by-side arrangement, helps with
working on these two aspects of a project because they're always
intertwined to a large degree. Secondly, the Visual Basic Introspector
(I think that's what they call it) is really useful in that once you
start typing a particular class or class instance, it recognizes the
object you're focusing on and shows all the properties, methods, and
available child objects in that context through a popup selector (which
you can ignore and keep typing or select from to shortcut your typing) -
this context-sensitive help really minimizes the time required to get
familiar with all the related pieces of the framework and the
application environment.
3. For lack of any obvious choices for me, I have resorted to
creating/editing Qooxdoo source files in a plain vanilla text editor.
Anything IDE-like that comes with the framework and doesn't involve
patching it together in the develoment environment would be better, but
a newbie is already challenged enough just learning the framework to
also figure out how to patch an IDE into the Qooxdoo framework.
4. Additionally, due to the size of such an undertaking, I'm betting
additional hands-on help is going to be necessary. I think an
integrated IDE tool that works within the Qooxdoo framework is an
excellent, deserving enhancement to the current Qooxdoo framework, and I
am willing to find an appropriate way to help it along for my own
benefit and the benefit of improved adoption rates by new Qooxdoo
converts. The more of us using it, the more of us that can help enhance
it and move it forward. Additional features that might be really
helpful include integrating Dan's form designer contribution as a
component of a Qooxdoo IDE rather than recreating it or leaving it out
of the IDE. Also, being able to "wire" the IDE to a web server
instance, select an RPC type, and get assistance setting up an
appropriate RPC server configuration would really ease people's use of
the remote database methods and avoid a lot of false starts with RPC
implementation. It might also help quite a bit to generate appropriate
RPC server source stubs with appropriate headers that just *work* with
the client calls. Then the developer can finish writing the required
RPC methods outside of the Qooxdoo IDE and load them to the server as
instructed by the IDE - or the Qooxdoo IDE could include that source in
a separate development section to insure the server methods are
consistent with the client RPC code and loaded to the right place. An
FTP component would be required in this case, but that would be the
ultimate situation. Since there are so many ways to deploy an RPC
backend, this could easily become a monstrous part of the work that
requires input from Qooxdoo'ers within each backend discipline. In some
future version of the IDE, it might even be able to allow selection of
component loading options so that the developer can delay initial script
loading of some portions of the app and improve the response time for
app users without having to learn these methods manually.
I hope that's what you are seeking in your RFC - this is one of the most
exciting discussions to come from the email list for me personally.
Thanks,
Gene
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
