Derrell and others,
I knew this would be a popular posting on the ML when I first saw it and
responded, but the ideas that have been coming out since Wednesday's
original posting are holding my rapt interest to see what other ideas
will come out on the topic.
I believe this might be one of the (if not THE) most popular discussion
since I started following each and every posting on the ML way back in
March. Why would this be the case? I think the answer lies in a couple
of important issues with Qooxdoo...
First, there are so many different ways to wire up a Qooxdoo project,
with some choosing the regular Application method, others choosing to
use it with supporting materials like qx or rails, while some implement
Qooxdoo into existing sites using the Inline method (as I first tried to
do). In addition, there are ways to launch an application in parts by
modifying the configuration file, and theming is so flexible that
develors need to figure out how the theming system works. All of these
alternatives are powerful features of Qooxdoo, but it also makes it much
more difficult to sort through the techniques that everyone uses in
their various projects to find the one that works best for a given
project and development style. Having a visual tool to guide a
developer through that minefield of options would be very powerful
indeed for experienced and new Qooxdoo'er alike.
Secondly, the Qooxdoo framework has so many wonderfully useful classes
that wading through the API (while helpful and complete) to figure out
how to use all these classes is a challenge for new developers. Again,
an IDE that helps to identify an appropriate object class to use in any
particular situation would be quite helpful, in addition to clarifying
what other object classes should be considered for enhancing the
function of each object class. It's difficult to figure out when and
how to implement a custom cell renderer in a table object can be
challenging.
Of course, having all of these features implemented in an IDE is going
to be a great challenge in itself.
I have to add that since trying out Qooxdoo, I was convinced that it
would enable me to create applications that provide specific
functionality that clients are requesting that I can't easily implement
otherwise, and I started to implement a rather complicated application
for one of my clients. In the end, I stumbled on a number of important
issues and ended up not getting all the way through that development
project before other priorities stole away my attention. One of the
biggest negatives that I observed was the initial load time of my
partially-developed application, and I realized that the answer lies in
the options for loading only classes needed at any given time, but I
couldn't find the time to learn how to implement the delayed-loading
that others have mentioned here. I also needed to develop a set of
windows in the application that would load when needed, but I struggled
with the management of child object handles in my application code,
whether it was in the main application class or a subclass within the
application. In the end, I just couldn't get off the ground and feel
like I knew what I was doing with the tool set.
I also read very closely the discussions on generating form structures
on the fly rather than hard-coding them into fixed windows, and that
feels like an appropriate direction for much of what I need to develop.
Again, applying these techniques involved learning time that I didn't
have available, so I read the postings and filed them away for future
reference.
It's been very frustrating to know that Qooxdoo can provide all the
features I need but to not have the time to focus on learning how to use
them appropriately. So, having a tool that would help me implement all
the important Qooxdoo options would have enabled me to become more
productive right from the start and get my project out the door,
resulting in another happy customer. I can't be alone in my struggles.
So, I'm watching and waiting for some clear agreement on where this idea
is going - ultimately, Qooxdoo is the right answer to many of my
problems, if I can figure out how to use it appropriately.
Thanks,
Gene
On Sun, 2009-10-11 at 11:33 -0700, tsmiller wrote:
> Derrell,
>
> I programmed commercially from 1983 until 1991. I found the net in about
> 1992 and fell in love with the idea. I learned about it a little and tried
> programming a few things, but I was entirely dissatisfied with html, css and
> the browser incompatiblilities. I basically became a user of the net
> because writing software for the net was ugly, kludgy, and not fullfilling.
> The net has not changed much. Most sites are doing things the same way that
> they were being done 15 years ago with a little bit of HttpRequest thrown
> in. The net brings in billions of dollars to people and those people
> publish their content using html (or xml), but after 15 years there is still
> no good wysiwyg html editors that let you easily create your page content.
> The creation of professional web content still takes a highly trained
> person.
>
> The web has been in what I call LAMP stack mode for a long time now.
> Websites look alike, act alike, and have the same limitations. There are not
> alot of options to make your page look and act differently from the next
> page.
>
> Then in 2006 I did a serious investigation of the tools that were available,
> looking at Dojo, Scriptaculus, Prototype and Mochokit among others. I
> decided on Qooxdoo. I decided on qooxdoo because it allowed me to abstract
> away the ugly web development process. I can start with an idea, develop it
> and implement it using qooxdoo without even being aware that the internet
> exists. And then run it in a web browser. It is a clean, self contained,
> and powerful process.
>
> To me, Integrated Development Environments tend to stifle creativity because
> programmers make their design and coding fit what is availabe in the ide.
> And then over time, the results grow into the next 'LAMP stack mode' or
> whatever the next name will be ( the 'QOOXDOO' mode!).
>
> It seems to me that ide's make it viable to write software in masse for a
> commercial market. I do not like this, but I suppose that is what makes the
> world go around.
>
> Please note that these are solely my opinions (right or wrong) and they are
> my two cents worth about how I perceive an ide.
>
> Qooxdoo has alot going for it. You guys have done a hell of a job. I do
> not use an ide because I want complete control over my design and the
> creation and the implementation of my code. That being quite verbosely
> said, here are some brief answers to your questions.
>
>
>
> 1 ) What do you find to be your most time-consuming or tedious tasks while
> developing qooxdoo applications?
>
> First, tracking down bugs (or behavior that is not expected). Such as why a
> widget is not placed properly in a container. Or why a decorator is not
> applied properly. Or why a call to the server just seems to hang. Second,
> trying to learn how to use a widget or a function of the widget. Such as
> how to make a widget scroll into view under certain conditions, or how to
> make the last table column take up the remaining space in a table.
>
>
> 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?
>
> I am not a sophisticated debugger. My debugging consists of alerts and
> messages sprinkled throughout my code. I would like to have some kind of
> integrated debugging tool that shows relevant information about where and
> when my code breaks at runtime.
>
>
> 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?
>
> I keep open a terminal window, a text editor, and three browsers. I compile
> and invoke my server from the terminal, edit syntax highlighted source code
> in the editor. The first browser window has tabs open for the qooxdoo API,
> the demobrowser, inspector, and the qooxdoo nabble page. The second browser
> has tabs for my application( local, online development, and production), and
> the third is a general purpose browser for googling the internet. I compile
> and invoke my server from the terminal. Partly because I am the only
> developer and the project is not huge, my compile to run cycle is
> negligable( a few seconds).
>
>
> 4) Please add any additional comments or suggestions
>
> I know that there are ways to break up a program into parts and libraries,
> and even load them on demand as they are needed. I know that I am going to
> catch flak for this, but the build process along with all of it's options
> and configuration possibilities is not easy to understand. It seems to me
> that it is going to be necessary to break up applications into on demand
> loadable parts in the future as the applications become bigger and more
> sophisticated. So it would be nice to at least think about some kind of
> graphical utility integrated into the ide that would let you specify how to
> build your application.
>
> Good luck. This is a very ambitious and interesting project that you are
> comtemplating.
>
> tom
>
>
>
> 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
> >
> > These questions are fairly broad and general, but whatever topic(s) you
> > choose to answer them with, please try to answer as concisely as possible,
> > and to each individual question. Respond on this mailing list so
> > discussion
> > of features can ensue. Please keep the message subject intact: *qooxdoo
> > "IDE" -- Request for Comments*, which will make it much easier to track
> > the
> > discussion.
> >
> > Thanks!
> >
> > Derrell
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> >
>
------------------------------------------------------------------------------
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
