How to test TreeTable

[Antonio Petrelli <ap...@apache.org>]

Hi list,
I am sorry for the really stupid question. I noticed that XAP has 
probably the only-javascript-based TreeTable solution (based on Dojo if 
I am correct).
I have to say that I don't want to deploy the complete XAP (at least in 
production).
Is there a way to test TreeTable, so that I can see how it works?

Thanks a lot in advance

Ciao
Antonio

RE: How to test TreeTable

[Michael Turyn <MT...@nexaweb.com>]

As far as I can tell, there were (wisely) no bits of Xap used in building the class, so using it with vanilla Dojo should be no problem, at least for a smoke test...

Dojo.require() and stack overflow issues

[James Margaris <jm...@nexaweb.com>]

So I hit an interesting problem today. Apparently in IE if you have a
file that requires another file that requires a third file etc etc you
can get a stack overflow error somewhat quickly. (After about 10 levels
of nesting or so.)

Thinking of ways to avoid this, one thing I think would make sense would
be to organize things like utils so that it has a package-level listing,
and structure that so that things required by other thing are on top.
For example, Hashtable requires Exception. So if we list them like:

Hashtable
Exception

When hashtable is loaded it will then load exception. If we list them
like:

Exception
Hashtable

Then when Hashtable is loaded Exception has already been loaded first.
If exception itself requires other classes this can save a few stack
frames. 

---

This is more a problem with unit tests right now as a real application
should run against a compiled profile that should have more things baked
into it rather than a bunch of nested requires.

James Margaris

RE: ArrayHelper and other helpers

[James Margaris <jm...@nexaweb.com>]

Yes you may be right, leaving the "Helper" on is probably better, although xap.helpers might be better than xap.util. Right now util is a collection of a whole bunch of junk that isn't all that similar. xap.helpers would be pretty straightforward.
 
Right now we just just Array but we need String as well. (I have some code that sticks a toString() onto a string directly that I need to remove) I can also see something like XmlHttpRequestHelper being useful in the future.
 
James Margaris

________________________________

From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Wed 9/20/2006 8:44 PM
To: xap-dev@incubator.apache.org
Subject: RE: ArrayHelper and other helpers



>If you look at xap.util.ArrayHelper, it al-
>ways takes an array as the first argument.

This seems natural and simple.

I'd propose a further (and particularly uninspired) convention
that when a Java method exists, it be used:
       aString.trim()  --->  StringHelper.trim(aString)
or
       aFoo.bar(a_0,...,a_n)  --->  FooHelper.bar(aFoo,a_0,...,a_n)



>I would like to remove the "Helper" part and just
>have the formula where "xap.util.XXXX" is a helper
>class if XXXX is a standard JS class.

This does not seem natural or simple; to have a class named "xap.foo.String"
or "xap.blah.Array" seems like a recipe for future confusion; I think
appending a "Helper" isn't so bad and accurately describes the class.


>Maybe instead of xap.util this should be under xap.lang or xap.js
>or something like that?
Well, if we _do_ do it that way, I'd prefer
          xap.helpers.String
(but just look at that name---it looks like it's a string in itself....)

RE: ArrayHelper and other helpers

[Michael Turyn <MT...@nexaweb.com>]

>If you look at xap.util.ArrayHelper, it al-
>ways takes an array as the first argument. 

This seems natural and simple.

I'd propose a further (and particularly uninspired) convention 
that when a Java method exists, it be used:
       aString.trim()  --->  StringHelper.trim(aString)
or
       aFoo.bar(a_0,...,a_n)  --->  FooHelper.bar(aFoo,a_0,...,a_n)



>I would like to remove the "Helper" part and just 
>have the formula where "xap.util.XXXX" is a helper
>class if XXXX is a standard JS class.

This does not seem natural or simple; to have a class named "xap.foo.String"
or "xap.blah.Array" seems like a recipe for future confusion; I think 
appending a "Helper" isn't so bad and accurately describes the class.


>Maybe instead of xap.util this should be under xap.lang or xap.js 
>or something like that?
Well, if we _do_ do it that way, I'd prefer
          xap.helpers.String
(but just look at that name---it looks like it's a string in itself....)

ArrayHelper and other helpers

[James Margaris <jm...@nexaweb.com>]

I want to come up with a standard helper type of class format, where a
helper is defined as a class that adds additional functionality to an
existing javascript class.

I don't think we want to modify object definitions directly, that could
have some problems when people start mixing in conflicting toolkits.

If you look at xap.util.ArrayHelper, it always takes an array as the
first argument. I would like to remove the "Helper" part and just have
the formula where

"xap.util.XXXX" is a helper class if XXXX is a standard JS class. Maybe
instead of xap.util this should be under xap.lang or xap.js or something
like that?

Thoughts?

James Margaris

TreeTable progress

[James Margaris <jm...@nexaweb.com>]

So I am making some pretty decent progress with treetable. The idea of tree table is that it is a combined tree and table. A multi-column tree, or a table with nested rows.

The idea is to have tree, table and treeTable all based on the same class as tree and table are just simpler (single column and un-nested) versions of treeTable. (And so is listbox really)

I am trying to strike a balance between proofing features to make sure they will work and not leaving too many odd tasks lying around. It took me a while to get the general setup of the control going but it seems to be ok right now. There are a few remaining sizing issues that a browser specific (for example on IE if you don't fix the height it is really tall; on Mozilla if you drag to the right the table will slide off the screen) but for the most part it works fairly well. I am trying to accomplish all of the following layout-related things:

1. User does not have to fix the width or height of table or individual columns/rows.

2. Top headers scroll horizontally with table but don't scroll vertically. (Are always displayed at top of visual portion of table)

3: Users can add/remove rows on the fly, change cell contents, etc.

4: Avoid a system like Dojo has for some components where component will not resize correctly unless you specifically tell it that the size has changed.

 

I think things like column-sorting and row selection will not be too bad as they are basically logical operations that don't interact too much with the browser. The layout stuff is tricky because it does interact a lot with the peculiarities of different implementations and weird HTML things. I tried a lot of different combinations of HTML controls until I found one that works well in both Mozilla and IE.

The table sample under widgets has a treeTable people can mess with. It is *far* from production quality but the basics work. It scrolls correctly, you can expand/contract nodes, etc. It isn't really usable but it should give people an idea of what I am going for.

 

James Margaris

 

Re: How to test TreeTable

[Antonio Petrelli <ap...@apache.org>]

James Margaris ha scritto:
> I hope to be at that point relatively soon, say 7-14 days or so.
>   

Hey there is no need to hurry :-) Thank you for the response, it was 
really clarifying.

Ciao
Antonio

RE: How to test TreeTable

[James Margaris <jm...@nexaweb.com>]

Hello Antonio. I am working on that class right now, but it is not very far along. It should be implemented as a standard Dojo component although it will not do what many Dojo components do and form itself based on the original HTML.
 
It will take me a few weeks to get the basics working, but here is what I want to support at first:
 
Column headers you can click to sort.
The ability to put basic strings in the table as well as more complex components like comboBox.
Row expansion/collapse.
Single row selection.
 
After that there are a bunch of other things like:
multiple selection
navigation via keyboard
Column resizing and swapping
locked columns, footer rows
cell editing. (Clicking or double clicking swaps the cell with an editor like a comboBox or textField)
 
It would be *great* to have someone else use it, but the code has just barely started being written. 
 
If you want to look at some existing test applications, if you look in examples/widgets there are a bunch of pages that are all in the a similar format that show what syntax and operations we support. As I continue to work on treetable I will update this area with some more samples.
 
Once I am further along there you should start to see separate samples for table, tree and treeTable. At that point when those samples demonstrate some basic functionality the treeTable should be ready for testing. I hope to be at that point relatively soon, say 7-14 days or so.
 
James Margaris

________________________________

From: Antonio Petrelli [mailto:apetrelli@apache.org]
Sent: Thu 9/14/2006 12:56 AM
To: xap-dev@incubator.apache.org
Subject: Re: How to test TreeTable



Bob Buffone ha scritto:
> Currently we have not fully implemented the treeTable widget. We are
> working on finishing it but right now it is a prototype.

No problem, I could test it and eventually help with the debugging,
because I have to work on a real-world problem.

> Regarding the
> whether or not you can use just treeTable: It may be possible to use
> just the treeTable, but it will be much easier to add it to your
> application using the declarative markup. 
>  

Yes I know that, but I would like to add the Dojo engine plus the
TreeTable, I don't need all the XAP engine (though I must say it is very
interesting).
Supposing that I prepare a test webapp that uses XAP, is there an HTML
page, or a link, that I can use to see the result of the prototype
TreeTable? (sorry but I cannot find one, maybe I have to check my eyes :-) )
Thank you

Ciao
Antonio

Re: How to test TreeTable

[Antonio Petrelli <ap...@apache.org>]

Bob Buffone ha scritto:
> Currently we have not fully implemented the treeTable widget. We are
> working on finishing it but right now it is a prototype.

No problem, I could test it and eventually help with the debugging, 
because I have to work on a real-world problem.

> Regarding the
> whether or not you can use just treeTable: It may be possible to use
> just the treeTable, but it will be much easier to add it to your
> application using the declarative markup.  
>   

Yes I know that, but I would like to add the Dojo engine plus the 
TreeTable, I don't need all the XAP engine (though I must say it is very 
interesting).
Supposing that I prepare a test webapp that uses XAP, is there an HTML 
page, or a link, that I can use to see the result of the prototype 
TreeTable? (sorry but I cannot find one, maybe I have to check my eyes :-) )
Thank you

Ciao
Antonio

RE: How to test TreeTable

[Bob Buffone <rb...@nexaweb.com>]

Currently we have not fully implemented the treeTable widget. We are
working on finishing it but right now it is a prototype. Regarding the
whether or not you can use just treeTable: It may be possible to use
just the treeTable, but it will be much easier to add it to your
application using the declarative markup.  

Bob (Buffone)

-----Original Message-----
From: Antonio Petrelli [mailto:apetrelli@apache.org] 
Sent: Wednesday, September 13, 2006 10:43 AM
To: xap-dev@incubator.apache.org
Subject: How to test TreeTable

Hi list,
I am sorry for the really stupid question. I noticed that XAP has 
probably the only-javascript-based TreeTable solution (based on Dojo if 
I am correct).
I have to say that I don't want to deploy the complete XAP (at least in 
production).
Is there a way to test TreeTable, so that I can see how it works?

Thanks a lot in advance

Ciao
Antonio