qooxdoo "IDE" -- Request for Comments

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

qooxdoo "IDE" -- Request for Comments

Derrell Lipman
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Jean-Baptiste BRIAUD -- Novlog

On Oct 7, 2009, at 18:24 , 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?
Without hesitation run my code : running compile qooxdoo using qooxdoo build, and deloy that plus the backend take too long.
I'm not a big fan of designer. I come from Java Swing world and after years of experiences the conclusion is that all developpers stop using the designer after few weeks or months.
It is just quicker (really quicker) to modify code.
Basically, that kind of designer helps efficiently but only beginers.
  1. 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?
Help me see my last code edition running quickly. Going from code modification to code running is too long but it has to include several languages (to include backend) because I would never use a separate tool just for qooxdoo.
Better javascript handling, refactoring, ...
  1. What is your current qooxdoo application development environment, and in it, what features do you find lacking and what features are critical to you?
IntelliJ. IntelliJ the most powerful IDE for Java and probably for javascript. 
Rather than starting a new IDE from scratch, I would recommend to think of a qooxdoo plugin for IntelliJ or Eclipse.
  1. Please add any additional comments or suggestions
better 2D and diagram in qooxdoo but some new contrib might fill the gap
better form and serialization handling but databinding will fit the gap

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Gene Amtower
In reply to this post by Derrell Lipman
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Bruce Bockius
In reply to this post by Derrell Lipman

see below...  For reference I've been developing in Qooxdoo since 0.6, and use it for several projects for the US Dept of Defense.

 


From: Derrell Lipman [mailto:[hidden email]]

  1. What do you find to be your most time-consuming or tedious tasks while developing qooxdoo applications?

Manual form design is very error prone and tedious.  Like Gene mentioned, going back and forth to the documentation frequently does slow things down a lot.

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

Code completion, auto-validation of code (i.e. background LINT sort of stuff), a form development GUI.  I'm not sure that the backend-generation stuff would be that useful to me.

  1. What is your current qooxdoo application development environment, and in it, what features do you find lacking and what features are critical to you?

Eclipse w/JSEclipse.  Works good for me since I am able to develop the backend (Java, JSP and Oracle's XSQL servlet for me) at the same time in the same IDE.  I find the auto-completion feature of JSEclipse rather lacking (no Qooxdoo specifics, no pop-up docs).

  -Bruce


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

dmbaggett-2
In reply to this post by Derrell Lipman

This sounds very cool, but I expect this will take a very, very long time to
write. I agree with others that it might be best to start from Eclipse and
build a QooxDoo RAD system on top of it. I also concur with those who've
said that the most time-consuming thing in QooxDoo right now is forms. A
tool that would let you drag and drop UI widgets onto a canvas and generate
the corresponding QooxDoo code would be hugely beneficial. Even this would
be a very substantial project -- certainly beyond what I would expect for a
grad school term project.

And I think it will be difficult to capture all the requirements for
arbitrary web applications in your tool. The only RAD tool I ever liked was
C++ Builder (part of the Delphi lineage). And here you'd be adding even more
complexity, because you're addressing both client and server sides.

Also, there are lots of other hard problems that need working on, IMO,
before such a RAD system would be compelling. In general, performance is a
real problem with JavaScript frameworks, and QooxDoo is no exception. You
constantly struggle with things being sluggish because the browser
JavaScript engine is just so slow -- especially IE. So I might suggest
picking a relatively complex aspect of QooxDoo, heavily benchmarking it, and
rewriting code where necessary to optimize. QooxDoo already has more such
things that other JS frameworks, so it is well positioned in this regard.

There also many cool widgets and widget extensions that would be nice to
have. Closing the "widget gap" between QooxDoo and other systems like ExtJS
would benefit everyone.

Dave


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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

--
View this message in context: http://www.nabble.com/qooxdoo-%22IDE%22----Request-for-Comments-tp25789918p25792604.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Skar-3
In reply to this post by Derrell Lipman
Derrell Lipman wrote:

>    - 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
>  
http://280atlas.com/ seems like a nice idea. Adobe Flex builder also is
good, though I'm not using flex anymore, just trialled it for some time.

I'd think the most important features are:

* an easy form creator/editor
* a plugin into eclipse/netbeans that supports auto-complete of
keywords/function names/parameters as a tool tip, like eclipse/netbeans
do for java. Like
* a faster way to sample the app while developing. This could be
improved by faster JS performance from the browsers, and opera 10,
chrome, safari, FF 3.5 are all faster than IE6/7, FF 3 etc. But any
optimization on qooxdoo's part should be done too :)
* and maybe generate scaffold classes/mixins etc from the IDE plugin or
using the generator like in rails. For eg, running "./generator.py
create class MyOwnTable qx.ui.table.Table" should generate a new class
called MyOwnTable inherited from the qooxdoo table. Same thing can be
done from a netbeans/eclipse drop down menu called qooxdoo, which'd have
sub menu called generate, like qooxdoo->generate->class, then a wizard
which asks for class name, base class etc. All available base classes
can be shown in a drop down from which the developer can select it. It
will help newbies and save some time and we can also avoid errors here,
say typing an unknown base class can raise an error. I'm into qooxdoo
for around 2-3 months now and I don't find the need for such a generator
anymore.
* A brilliant theme which looks great on default. See cappuccino's
aristo theme in action at http://280slides.com/Editor/.
* An application loading spinner image with percentage of app loaded
shown below. That would help the user of the app to know how much of the
app has loaded.The previous 280slides app has the % of app loaded shown
and has a filling up of their slide document icon, which looks great.

Tying into the back end isn't simple, nor is it preferable. And we'd
have to run with the back ends all the time and keep the backend glue
updated and the docs updated too. Maybe we can keep up with rails,
django etc, but it's best left to the developers themselves. Maybe a
sample project in each backend, one each in rails, django, whatever is
good in other languages like java/perl/php/c/c++ etc should do. Keeping
individual projects updated is far easier :)

Qooxdoo already rocks, with the availability of doc api, playground,
demo browser etc, which is far better than competing frameworks. Kudos
to the team for the good work :)

Just my 2 cents.

cheers,
skar.

--
--
The life so short, the craft so long to learn.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Petr Kobalíček
In reply to this post by Derrell Lipman
Hi,

I read all comments and for me the most time consuming task is to
write forms with correct databinding. In fact I can live without RAD
tools like form designers, because I can write form very quickly. I
wrote small framework for me (can't release, it's very connected with
our app) that solves forms+databinding+dataexchange problems, but my
solution is just solution for our app, nothing heavily engineered and
robust for everyone. I'd like to see really full-featured universal
solution (that fits to 95% cases) for advanced form manipulation and
databinding.

So, for me, instead of RAD tool I'd like to see really good engineered
databinding solution in qooxdoo (I think that this needs everybody).
Of course form designer would be nice too, but I'm spending only
little time doing forms, all other time is databinding,
refactorization and other tasks (finding bugs, waiting to realod,
waiting for server to start, etc...).

So for me - databinding, inteligent refactorization support,
intelligent code assistance (in netbeans/eclipse).

Also I'd like to see databinding comparisons with other js libs, for
example with ExtJS and Smartclient, and maybe Dojo. To compare how
these libs are engineered. Personally I want to try smartclient in my
next app to be able to compare databinding myself.

Best regards
- Petr

2009/10/7 Derrell Lipman <[hidden email]>:

> 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!
>
> What do you find to be your most time-consuming or tedious tasks while
> developing qooxdoo applications?
> 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?
> What is your current qooxdoo application development environment, and in it,
> what features do you find lacking and what features are critical to you?
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Skar-3
Petr Kobalíček wrote:
>
> Also I'd like to see databinding comparisons with other js libs, for
> example with ExtJS and Smartclient, and maybe Dojo. To compare how
> these libs are engineered. Personally I want to try smartclient in my
> next app to be able to compare databinding myself.
>  
Yup, smart client does seem good.
http://www.smartclient.com/index.jsp?skin=Enterprise#fetchOperation has
good demo. For eg, the live grid is the same as qooxdoo's as far as
functionality goes, but looks nicer. Of course, it's a matter of taste,
still I find smart client to have a better theme. Also, their site
http://www.smartclient.com/ has a better look/feel too. Again, it's a
matter of taste, but I think qooxdoo.org website might do well with an
overhaul which makes it look web 2/3 ish :)

cheers,
skar.

--
--
The life so short, the craft so long to learn.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

fritz
On Thu, 8 Oct 2009, skar wrote:

> Yup, smart client does seem good.
> http://www.smartclient.com/index.jsp?skin=Enterprise#fetchOperation has
> good demo. For eg, the live grid is the same as qooxdoo's as far as
> functionality goes, but looks nicer. Of course, it's a matter of taste,
> still I find smart client to have a better theme. Also, their site
> http://www.smartclient.com/ has a better look/feel too. Again, it's a
> matter of taste, but I think qooxdoo.org website might do well with an
> overhaul which makes it look web 2/3 ish :)

Yes, design comes before content these days ...

Cheers,
Fritz

--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker                        +41 62 775 9900 (switch board)
Aarweg 15                            +41 79 675 0630 (mobile)
CH-4600 Olten                   fax: +41 62 775 9905
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Burak Arslan-2
In reply to this post by Derrell Lipman
Hey Derrell,

First off, i'm glad this problem is getting some attention.

Derrell Lipman yazmış:
> 1. What do you find to be your most time-consuming or tedious tasks
> while developing qooxdoo applications?

Two points here:
 * Designing forms. That's why i built jsqt. i'm rewriting it right now,
you'll hear soon again from that project.
 * Debugging: I want to place breakpoints in my ide, not firebug. It's
tedious to find the file, get the line number, place breakpoint and
reload. I'm running my sites off ram (/dev/shm) just to make this
process run faster.

Another point I want to be prepared for is this: RIAs are fine, until
some client is dissatisfied with the performance (of the client). So I
want my interface to be as portable to a desktop environment as
possible. Jsqt is also a factor that facilitates this operation, should
I ever find myself obliged to do it.

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

When I have jsqt, i guess i'm all done. I haven't looked at databinding
stuff yet though.

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

It was the epic failure that is Eclipse, but I've had enough with it.

I'm currently using Netbeans. It still lacks a proper runtime
environment :) Seriously, code completion is a joke. (it's slow. when it
works, it only shows variables i can already see on my screen, along
with usual junk)  It takes ages to start up (Scanning projects? Come
on). It also lacks breakpoints-in-ide.

> 4. Please add any additional comments or suggestions

If i'd attempt this, i'd do it with Qt, with Python or C++ or both. I'd
even look at the option of modifying Qt Creator. (not designer)

Best Regards,
Burak



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
flj
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

flj
In reply to this post by Derrell Lipman
Hi.

My thoughts on this:

First, I'd personally be curious about what tools people use for qooxdoo development right now, in absence of a proper IDE, and of their working habits - what they use more: the inspector, the source build, how they integrate running scripts with their "IDEs" etc.

Second, IMO building a generic application framework integrated into an IDE-like something based on qooxdoo should start by asking people what they do with qooxdoo. Judging by the apps listed in the real-life examples section, I'd say the variability in usage scenario, backend systems and so on is quite high. Which should make the building of a generic "IDE" quite difficult.

Third, I chose qooxdoo for one reason in particular: developing web apps with server-side frameworks is really really cumbersome, since most server-side frameworks, Java, .Net, Ruby, Python or anything else alike, have become bloatware (I know of one particular exception - apache wicket, which provides really nice ajax-based features, but also includes graceful degradation to non-ajax functionality - unfortunately not usable in .Net environments). With qooxdoo, all you need is a decent browser, and can limit server-side development to developing a few web services to communicate with the client. A framework based on qooxdoo which abstracts the server and binds the UI to data is theoretically a nice idea, but IMO not as nice once you start building something a la hibernate to make the data binding possible - you end up with a similar elephant behind the curtains.

Fourth, I agree that qooxdoo could really use some new, updated themes, which should be part of the release. However, my (very short) experience with qooxdoo says that this would be more or less just marketing, since customers always want _their_ themes, even if they look like crap. Nevertheless, marketing is important.

br,

flj

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Helder Magalhães
In reply to this post by Derrell Lipman

Hi Derrell,



Derrell Lipman wrote:
>
> 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.
>

It's great to know you are thinking about this, I really feel like this
would be an great helper for the qooxdoo community, specially when
starting-up. ;-)



Derrell Lipman wrote:
>
>    1. What do you find to be your most time-consuming or tedious tasks
> while
>    developing qooxdoo applications?
>

Crawling through the documentation. The API viewer included with Qooxdoo is
great, but having to crawl for methods/properties every time is pretty
time-consuming.



Derrell Lipman wrote:
>
>    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'd say that these would be nice:
 * Visual designer (like Tartan BluePrint but supporting all qooxdoo
widgets): this is already stated in the aims list;
 * Code completion/list of properties/methods for a given scope (a.k.a.
"Intellisense");
 * Background source/build preparation;
 * Background code validation (invoking the "lint" targets and showing
results in a task list, like Visual Studio does when compile errors are
triggered): this was already suggested by Bruce Bockius;
 * Easy insertion of  http://qooxdoo.org/contrib contributions  and/or
http://qooxdoo.org/documentation/0.8/snippets code snippets  into a project
(automatically setting up the required environment, dynamically fetching the
list of contributions/code snippets from the qooxdoo site, ...).



Derrell Lipman wrote:
>
>    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?
>

Currently, I'm using Microsoft Visual Studio on Windows, but only as an
IDE/code editor:
 * Aggregate important files into a project;
 * Setup utility build tasks into build targets (I use Cygwin for the main
build tasks).



Derrell Lipman wrote:
>
>    4. Please add any additional comments or suggestions
>

I'm convinced that  http://www.aptana.org/studio Aptana Studio  (previously
known as Aptana IDE), which is Eclipse-based, would be a nice base for
development of such a tool. Aptana already supports most of the things being
aimed milestones, including code completion and debugging (apparently for
free only for Firefox, paid for IE). This means that such a project could
potentially be modeled into developing a plug-in for Aptana, mostly taking
care of tweaking the IDE to fit the expected qooxdoo environment. :-)



Derrell Lipman wrote:
>
> Thanks!
> Derrell
>

Hope this helps,
 Helder
--
View this message in context: http://www.nabble.com/qooxdoo-%22IDE%22----Request-for-Comments-tp25789918p25802421.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Loïc Bresson -- Novlog
In reply to this post by Derrell Lipman
>    1. What do you find to be your most time-consuming or tedious tasks
>       while developing qooxdoo applications?

Mainly 3 things:
- check the errors in my code, like wrong method call (missing argument,
bad type, etc)
- go to qooxdoo.org, parse the documentation of the class and super
classes, get back to my IDE and use what I've learned.
- refresh the browser after every modification to see if everything
works and looks good, and since we have a backend, I have to redeploy
everything which can be very time consuming (maybe 10% of my development
time?)


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

Obviously, I'd like to have solutions to the issues I stated in point 1. :
- something that highlights possible errors in my code. Not only an
equivalent of "./generate.py lint", but also something that tells me
I've misused a method. I know that we're in Javascript, but it could be
nice to at least have a warning about things like that. Type checking
would really be a nice feature. But since this is not implemented in the
generator, I think it would be hard to have it in an IDE.
- a sort of equivalent to javadoc, let's call it qooxdoodoc, that when I
type can pop up the available methods available for an object with the
corresponding doc, or can appear when I pass the mouse over an object or
a method.
- being able to have a "design view" would be great. Not something to
build the UI in a graphic designer and generate code (like the Tartan
Blueprint contrib), but the opposite. Something that generates the UI as
we type the code, allowing us to see what we are coding looks like. Of
course, for applications with backends this would not work perfectly,
but for basic apps I think it would be a real improvement.


>    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 recently switched to IntelliJ, which is slower than others like
Eclipse, but really powerful.

As many, I think a plugin for an existing IDE would be better than a
brand new IDE. A project does not always contain only qooxdoo code,
there can be other parts in several different languages, so we don't
want to have a specific IDE for each part of the project.

>    4. Please add any additional comments or suggestions

This is not a suggestion but more a comment about this thread: seeing
all posts, I think it's sometimes getting more in a "what I want that
the qooxdoo framework has not" discussion than a "what I want for a
qooxdoo *IDE*" one. I think we need to stay focused :)


Cheers.

--
Loïc Bresson


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Loïc Bresson -- Novlog
In reply to this post by Skar-3
skar wrote:

> Also, their site
> http://www.smartclient.com/ has a better look/feel too. Again, it's a
> matter of taste, but I think qooxdoo.org website might do well with an
> overhaul which makes it look web 2/3 ish :)

I have nothing to say about the product itself (has not tested it though
  the appearance looks nice), but I personally find their website ugly.
I'm fine with the current qooxdoo site: colors and the organization are
nice, and it's usable although there are a few lacks :)


--
Loïc Bresson


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Thomas Herchenroeder
In reply to this post by Loïc Bresson -- Novlog
> This is not a suggestion but more a comment about this thread: seeing
> all posts, I think it's sometimes getting more in a "what I want that
> the qooxdoo framework has not" discussion than a "what I want for a
> qooxdoo *IDE*" one. I think we need to stay focused :)


I'm not sure about this. I think Derrell deliberately asked those open and
general questions, because only if you know what developers need (whatever
this might be) can you draw conclusions about what could be supported in
an IDE. Therefore I think its quite appropriate to be broad and general in
the answers.

I want to take the opportunity to bring up two other points I'd like to
see mentioned in this discussion:

1) Inspector
I haven't seen any mentioning of the Inspector in this discussion,
although it covers a few points that were brought up. Particularly, it is
not only good for inspecting a running application, but its editor lets
you play with property settings and see the effects they have in the live
application. As property tweaking is one of the major activities during
qooxdoo developement, I guess this would be valuable "early-feedback" tool
for many.

2) Backend Integration
It saddens to see how often backend integration is mentioned in the
context of development difficulties, both within and outside this thread.
After 20+ years of client-server development (and this what you all do)
and modular design it is still not apparent to many people that you do
backend integration *as rarely as possible* during development (namely,
when you do integration testing). All other times you make your best
effort to *decouple* the client part of your application from the backend.
In my view, this is the only sane way to develop client-server
applications. If you think, doing so is too much effort, you haven't
thought about the cost of not doing so. Rather than struggling with server
integration every time you make a change to your frontend

  - test the server independent from the frontend (e.g. with a simple test
client)
  - provide the client with mock objects and -data, so it can run
completely independent of the server.

This also forces you to think modular, and pack server interaction in an
encapsulated i/o layer in your frontend. Everybody developing a more than
primitive web application and not setting it up this way is going down the
wrong path, IMO.

To that end, I had expected to see for quite a while

  - an RPCTestClient contribution that lets you enter a service URL and
request parameter, send the request to the server, and inspect the
returned data, in a simple, form-style application

  - a mock transport class à la "qx.io.remote.transport.Mock" that doesn't
go to the server, but will return prefabricated data on particular
requests, and which can be easily (i.e. changing one line of code)
switched with real transport classes.

It should be easy to see how these two tools could be combined (e.g.
thinking of a Json-style representation of request-reply pairs). This
would relieve everybody's lifes a lot.

T.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

panyasan
Hello Thomas,

thron7-2 wrote
2) Backend Integration
It saddens to see how often backend integration is mentioned in the
context of development difficulties, both within and outside this thread.
After 20+ years of client-server development (and this what you all do)
and modular design it is still not apparent to many people that you do
backend integration *as rarely as possible* during development (namely,
when you do integration testing). All other times you make your best
effort to *decouple* the client part of your application from the backend.
In my view, this is the only sane way to develop client-server
applications. If you think, doing so is too much effort, you haven't
thought about the cost of not doing so. Rather than struggling with server
integration every time you make a change to your frontend

  - test the server independent from the frontend (e.g. with a simple test
client)
  - provide the client with mock objects and -data, so it can run
completely independent of the server.
That sounds good in theory, and I fully agree about the client-server independence. Using JSON-RPC goes along way towards that goal. However, if you look, for example, at the application I am developing:



There are SO many server data request necessary that all depend on each other (because one request's result determines the subsequent requests). There is simply no way this could be done in a mock setup.

thron7-2 wrote
To that end, I had expected to see for quite a while

  - an RPCTestClient contribution that lets you enter a service URL and
request parameter, send the request to the server, and inspect the
returned data, in a simple, form-style application
If have something like this in qcl (PHP backend):



https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/qcl/trunk/backend/php/class/qcl/server/debug_console.php

But it is VERY primitive. I for a long time have wanted to replace it with a qooxdoo frontend. But there is only so much one can do at a time ;-). So if anyone would throw some time into this, it'd be very welcomed. Derrell's RpcExample contribution is a good basis on which to build on.

Cheers,

Christian

Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

panyasan
And concerning Derrell's original request:

As you can see from the screenshot, my app's GUI is data-driven and really complex, and would gain little from visual IDE support - much of it is programmatically generated.

On the other hand, I develop it with QxTransformer, which helps to keep my GUI code transparend, modular and re-usable. So if I had a wish, I would like an IDE which supports the declarative building of the GUI with QxTransformer (or any other XML -> Javascript translator). I know that Siarhei would like to write such an IDE but he has no time to develop qooxdoo stuff at the moment.

Cheers,

Christian
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Skar-3
In reply to this post by Thomas Herchenroeder
thron7 wrote:

> To that end, I had expected to see for quite a while
>
>   - an RPCTestClient contribution that lets you enter a service URL and
> request parameter, send the request to the server, and inspect the
> returned data, in a simple, form-style application
>
>   - a mock transport class à la "qx.io.remote.transport.Mock" that doesn't
> go to the server, but will return prefabricated data on particular
> requests, and which can be easily (i.e. changing one line of code)
> switched with real transport classes.
>
> It should be easy to see how these two tools could be combined (e.g.
> thinking of a Json-style representation of request-reply pairs). This
> would relieve everybody's lifes a lot.
>  
Yes, Inspector is awesome, it does help in easily checking out a small
change in appearance or behavior :)

Yes, I'd like a mock client and mock request objects that's easy to
switch with the real ones and where it's easy to have a set of test
request/response data :) Basically, me too, for Thomas' suggestions :)

cheers,
skar.

--
--
The life so short, the craft so long to learn.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo "IDE" -- Request for Comments

Jim Hunter-2
In reply to this post by panyasan
Christian,

  You need to take a step back from your code for a minute and re-think your application. My application is about 10x the size of yours, and is 100% data driven and everything you see when it runs is generated on the the fly, there are no pre-written screens. And my entire application is developed using mock data and the server is tested separately from the client. There is no need to see 'real' data while you are developing something, all you need to know is what the data is going to 'look' like. Then create a sample set of data, or even a few sample sets and randomly return then if you don't want to always see the same thing. There is, IMHO, never a need to have a connected back end as a requirement during development. You should always be able to use mocks on the client side, or at the least, have the mocks served up from the server until you get all your server code properly written. In my job, mocks are essential to day-to-day development.

Jim

On Sun, Oct 11, 2009 at 6:29 AM, panyasan <[hidden email]> wrote:

Hello Thomas,


thron7-2 wrote:
>
> 2) Backend Integration
> It saddens to see how often backend integration is mentioned in the
> context of development difficulties, both within and outside this thread.
> After 20+ years of client-server development (and this what you all do)
> and modular design it is still not apparent to many people that you do
> backend integration *as rarely as possible* during development (namely,
> when you do integration testing). All other times you make your best
> effort to *decouple* the client part of your application from the backend.
> In my view, this is the only sane way to develop client-server
> applications. If you think, doing so is too much effort, you haven't
> thought about the cost of not doing so. Rather than struggling with server
> integration every time you make a change to your frontend
>
>   - test the server independent from the frontend (e.g. with a simple test
> client)
>   - provide the client with mock objects and -data, so it can run
> completely independent of the server.
>

That sounds good in theory, and I fully agree about the client-server
independence. Using JSON-RPC goes along way towards that goal. However, if
you look, for example, at the application I am developing:

http://n2.nabble.com/file/n3803350/Bild%2B1.png

There are SO many server data request necessary that all depend on each
other (because one request's result determines the subsequent requests).
There is simply no way this could be done in a mock setup.


thron7-2 wrote:
>
>
> To that end, I had expected to see for quite a while
>
>   - an RPCTestClient contribution that lets you enter a service URL and
> request parameter, send the request to the server, and inspect the
> returned data, in a simple, form-style application
>
>

If have something like this in qcl (PHP backend):

http://n2.nabble.com/file/n3803350/Bild%2B2.png

https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/qcl/trunk/backend/php/class/qcl/server/debug_console.php

But it is VERY primitive. I for a long time have wanted to replace it with a
qooxdoo frontend. But there is only so much one can do at a time ;-). So if
anyone would throw some time into this, it'd be very welcomed. Derrell's
RpcExample contribution is a good basis on which to build on.

Cheers,

Christian


--
View this message in context: http://n2.nabble.com/qooxdoo-IDE-Request-for-Comments-tp3782909p3803350.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Client-Server separation - Was: Re: qooxdoo "IDE" -- Request for Comments

panyasan
Hello Jim,

putting this on an extra thread so that it doesn't distract from Derrell's question...

Jim Hunter-2 wrote
Christian,
  You need to take a step back from your code for a minute and re-think your
application. My application is about 10x the size of yours, and is 100% data
driven and everything you see when it runs is generated on the the fly,
there are no pre-written screens. And my entire application is developed
using mock data and the server is tested separately from the client. There
is no need to see 'real' data while you are developing something, all you
need to know is what the data is going to 'look' like. Then create a sample
set of data, or even a few sample sets and randomly return then if you don't
want to always see the same thing. There is, IMHO, never a need to have a
connected back end as a requirement during development. You should always be
able to use mocks on the client side, or at the least, have the mocks served
up from the server until you get all your server code properly written. In
my job, mocks are essential to day-to-day development.
I believe you that this is probably the professional way to do things, no doubt, especially in teams. Because I have so little time (it is just a side project), the way I am working is to constantly adapt the server code to the needs of the client and vice versa - writing mockups would take much more time than just using the server data itself, which also alerts me to problems of the client-server communication as soon as they happen. That's probably not the best way to do things, but the only way I can realistically do it at the moment. So I am not arguing over philosophies here.

But the interesting point is how this would affect and IDE  - Thomas' original point. Wouldn't backend integration simply mean that you create visual objects for the "stores" and then connect them to whatever you want to connect them - mockup data or real server data?

Cheers,

Christian

But the real question is
123