Am 02.02.10 15:25, schrieb Derrell Lipman:
> On Tue, Feb 2, 2010 at 01:41, Tom Schindl <tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>> wrote:
>
> Hi,
>
> Thanks. That solved the problem though I still had to fight a bit
> because the virtual-API looks like has a flaw because the order of API
> calls is important.
>
> Background to this is that I assign my own SimpleTreeDataCellRenderer
> because I don't want to show icons at all.
>
> So my first setup looks like this:
>
> --------8<--------
> tree.setAlwaysShowOpenCloseSymbol(false);
> tree.setExcludeFirstLevelTreeLines(true);
> tree.getTableColumnModel().setDataCellRenderer(0, renderer);
> --------8<--------
>
> But this is not using this working when assigning a new renderer because
> the attributes in reality stored in the renderer itself and when setting
> custom one they are reset to the default.
>
> I think this has to be documented in the API at least and IMHO the
> method should be deprecated in favor of the ones in
> SimpleTreeDataCellRenderer.
>
>
> Thanks for this! I looked at documenting it, but it would be relevant
> only to very few people and would confuse the issue. This actually
> affects many functions, as they are shorthand for retrieving the cell
> renderer and operating on it. I disagree about deprecating the methods
> in TreeVirtual, though. No one, during normal usage (your usage is not
> normal) should have to know or care about the internal workings of the
> widget. For those of us who do really fancy things like altering the
> tree cell renderer, we need to look at the source code and get familiar
> with the code. Making changes to the cell renderer requires looking at
> the code, so the people who would need to do this are already familiar
> with doing so.
>
I disagree with this. IMHO I don't have to browse source code to find
out when I'm able to call an API method.
You are right that my use case is probably not a common one but then it
should be documented at least on SimpleTreeDataCellRenderer-Class-Doc.
IMHO the real problem is that if you want to keep the standard methods
on the virtual tree the default renderer should request the value(s) if
not set explicitly on itself from the tree it is working for to.
Another problem in this area is that it is not documented that I'm
unable to use 2 a cellrenderer for 2 different trees and now calling
setExcludeFirstLevelTreeLines(true); suddenly not only affects the
control it was called on but also others.
So IMHO the JS-Class should be defined like this (holds true for the
other 2 properties as well):
---------------8<---------------
excludeFirstLevelTreeLines :
{
check : "Boolean",
init : null
},
_addIndentation : function(cellInfo, pos)
{
// ...
var bExcludeFirstLevelTreeLines =
_getCalcExcludeFirstLevelTreeLines();
// ...
}
_getCalcExcludeFirstLevelTreeLines : function(cellInfo) {
var bExcludeFirstLevelTreeLines =
this.getExcludeFirstLevelTreeLines();
if( bExcludeFirstLevelTreeLines == null ) {
/*
* fallback to parent probably data has to be passed via
* cellInfo else fall back to old value
*/
bExcludeFirstLevelTreeLines =
cellinfo.excludeFirstLevelTreeLines == null ? false :
cellinfo.excludeFirstLevelTreeLines;
;
}
return bExcludeFirstLevelTreeLines;
}
---------------8<---------------
This way your API gets call order independent and the second problem
can't occur but I admit that I'm a qooxdoo newbie and so probably you
are on the right track.
Tom
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl geschaeftsfuehrer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5/1 A-6020 innsbruck phone ++43 512 935834
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
