Am 02.02.10 16:04, schrieb Tom Schindl:
> 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
^^^^^^^^^^^^^^^^^
unable to use 1 cellrenderer instance for 2 different trees
Sorry for the bad wording .... .
> 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
