Hi Jim, Yes I distinctly remember both you and Sebastian replying to many of my
posts. I didn't say that none of my questions were ever answered. I was saying
a good percentage of posts to this list do go unanswered, and the timeliness of
responses is slow when compared to the ExtJs forums.
I think this is simply a case of pure numbers to be honest. I have no idea how
many members this mailing list has, but the Ext forums have 23,500 members -
just over 19,000 of which are currently active.
Cheers
Aaron
----- Original Message -----
From: Jim Hunter
To: qooxdoo Development
Sent: Wednesday, January 23, 2008 8:30 AM
Subject: Re: [qooxdoo-devel] Thoughts on ExtJS vs qooxdoo
Aaron,
I just did a quick search and you have made or contributed to 14 threads in
this list and except for your post from 2 days ago (which now has an answer),
all your posts were responded to, many by me. I don't think there is a problem
with this list at all. The people on this list are more then willing to jump in
and lend a hand. With that said, not all posts get replied to in under an hour,
we are not all in the same time zone. It might take a couple of days, if there
is in fact an answer. I saw a recent post where someone was looking for someone
that has used qooxoo in combination with 2 other technologies. Well, if I have
never done it, I'm not going to respond to the post just to say I don't know.
And if no one else has done it, I am going to guess that question will go
unanswered, as it should. Most questions that have an answer, get one.
I like qooxdoo and I'm sticking with it for the long run. It's just so neat
and clean to create your own classes and objects. You can build complex
applications with little code.
Jim
On Jan 22, 2008 10:57 AM, Aaron Cooper < [EMAIL PROTECTED]> wrote:
To extend on my first post:
An example of my frustrations with the support in the qooxdoo community is a
post I submitted over 2 days ago asking about scroll bars in a window.
I haven't had a single response yet, even one to say that what I'm trying
to
do can't be done or I haven't provided enough info etc etc.
Looking back through the archive on Nabble, there are 70 threads between now
and Dec 14 2007. 21 of these threads have zero replies. That's 30%.
I have to say that I have never had a thread go unanswered on the Ext forum.
Nor do I run into many. The Qooxdoo mailing system still seems to fall short
compared to Ext support unfortunately. I've rarely got a response here,
where as in the Ext community, I rarely don't get a response.
Like I said, it's a biggie for me when I'm using these frameworks to build
large database apps.
Aaron
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED] On Behalf Of Chris
Haynes
Sent: Wednesday, 23 January 2008 5:47 a.m.
To: qooxdoo Development
Subject: Re: [qooxdoo-devel] Thoughts on ExtJS vs qooxdoo
I've not looked at ExtJS, but you might be interested in my experience of
qooxdoo, having adopted it about 6 weeks ago.
My starting point is programming in Java (and, in the past 45 years, Pascal,
Smalltalk, Prolog, Algol, Fortran and various assembly languages).
I had been holding back on converting all of my application to AJAX because
I was concerned about the 'toy' nature of Javascript - the lack of a good
Object structure, lack of type safety, the lack of documentation support
etc.
Qooxdoo has taken away about 90% of my concerns.
I think the framework, development support, API documentation, class
structure (with properties:, members:, statics: etc.) absolutely wonderful.
I'm not that keen, however on the UI widgets. I had bad experiences with
the
qooxdoo layout managers and also could not understand (and got no response
here to a request for help on) the 'theme' system.
So, given that I already had my own library of low-level UI widgets and
browser-agnostic DOM drivers, and a substantial CSS file describing the UI
styles I need, I've adapted these to work within the qooxdoo framework.
A couple of additions I've made in the last week might be of interest:
I was concerned about the efficiency of event handling - I've made my own
Event and EventHandler classes.
I've made a Recycler class, which issues new or recycled instances of
classes and takes them back after use, cleans them up and holds them
available for reuse. This is proving really valuable for recycling event
handlers and events.
I've made a two-way linked list system, which I use instead of Arrays for
holding sequences of event handlers (or anything else I want). It works by
attaching and manipulating pointers to both the list 'owner' object and to
the individual items in the list, which can be placed in any existing class,
including in DOM objects, without their 'knowledge' or co-operation.
With this linked list system I just create a singleton list manager for each
named list (e.g. one for the family of lists called 'eventsToBeBroadcast', a
second one for 'eventsToBeReceived'). These singletons 'know' the names of
all the logical pointers needed for each list (for list items: 'next...',
'previous...', 'owner...'. For the list owner: 'first...', 'last...') and
undertake the pointer manipulation.
No additional run-time objects at all are needed for the individual lists
attached to instances of event sources and clients or for the items within
the lists - it's all done, very quickly, with pointers.
Speed tests: on a typical client - a 2006 mid-range laptop, using Firefox
under Windows XP, adding then removing 100,000 items to/from a list takes 17
microseconds per item.
Simple traversal of the list ( i.e. counting the number of items in the
list)
takes 800 nanoseconds per item.
MSIE6 on the same machine is about 1/3 of this speed, and I had to reduce
the number of items, since it complained about the script execution time.
Performance of Firefox on my development machine - SuSE Linux, processor
about 2* the speed of the laptop's processor - was only about 20% faster -
so speed of memory access is probably the limiting factor, not raw
processing power.
Oh! One other thing I've added. I've made an incremental update system which
uses a separate client 'control-panel' window. My server keeps track of the
timestamps of the individual javascript class files in the original
download
and permits the developer to ask for an incremental download of the
'members:' parts of any classes that have changed.
This, combined with an AJAX request logging system, permits me rapidly to
update and re-try AJAX pages which are many logical steps into my complex
application. I've got the incremental development cycle down to three
clicks:
1) Edit and save my JS class file (in Eclipse),
2) Click on my client control panel for a reload of the changed class,
3) Click to repeat the most recent (or any other) application AJAX request
from client to server.
The only limitation with this at present is that the reloaded classes are
evaluated, so I don't get the source file line numbers in error messages.
I'm hoping the qooxdoo team's work on reloading will solve this one for me!
With these additions of my own, I'm now feeling very confident about taking
full AJAX in production.
Chris Haynes
On Tuesday, January 22, 2008 at 6:29:50 AM, sub wrote:
> Thanks for the detailed responses all.
> I agree that I hope 0.8 brings UI capabilities closer.
> The samples on the extjs homepage do look nice such as the web desktop and
> IM like client. It also feels more responsive but I'm not too sure about
> that.
> I think it's great that there's now strong competition but I do feel like
> qooxdoo has a much stronger/clearer framework.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
