+1 to moving the defaulting code to the renderer. However, the renderer must call setFocusRowKey on the component with the default value, so that decode/validate/update will work correctly.
if the focusRowKey is null upon postback, it could cause errors during decode. --arjuna On 10/30/06, Adam Winer <[EMAIL PROTECTED]> wrote:
Question 2 would be what we should do if the focusRowKey is null? If we simply removed the defaulting code altogether, what would go wrong, and where? -- Adam On 10/30/06, venkata guddanti <[EMAIL PROTECTED]> wrote: > On 10/30/06, Kamran Kashanian <[EMAIL PROTECTED]> wrote: > > > > In UIXTreeTable the focusRowKey attribute specifies the rowKey of the > > currently focused row. In the renderer, the row with the focusRowKey is > > rendered as the root node of the TreeTable and a focus path is rendered > > above the TreeTable. > > > > When no focusRowKey attribute is specified on the component, UIXTreeTable > > defaults the focusRowKey to the first node in the treeModel. So the > > focusRowKey can never be null. > > > > This defaulting of the focusRowKey is OK for UIXTreeTable because it only > > supports a single root node. > > > > The issue I have with this is that I want to support multi-rooted > > TreeTables. So I want to do two things: > > > > 1) When no focusRowKey attribute is specified on the component, I will > > render all of the root nodes in the TreeTable (multi-rooted TreeTable). > > 2) When a focusRowKey attribute is specified, I will render the row with > > the > > focusRowKey as the single root node of the TreeTable. > > > > Unfortunately, becuase UIXTreeTable always sets a default focusRowKey, I > > can't achieve #1 above. The defaulting of the focusRowKey is done in the > > _init() method of UIXTreeTable, which is a package scoped method. So I > > can't > > override this default behavior in my subclass of UIXTreeTable. > > > > There are a couple of solutions to this: > > > > 1) Move the defaulting logic to a protected method in the UIXTreeTable so > > that it can be overriden in subclasses > > 2) Move the defaulting logic out of the component and into the renderer. > > > > +1 to moving it to the renderer since it is a renderer specific feature. > > > Venkata > > I hope all of this makes sense, and any input on this is very much > > appreciated. > > > > > > -- Kamran > > > > > >
