I think #2 should be the immediate solution, not the
long-term change.
-- Adam
On 10/31/06, Kamran Kashanian <[EMAIL PROTECTED]> wrote:
Actually, in my case, #1 below will only help if I do my own decoding and
do not assume a non-null focusRowKey during decode.
On 10/31/06, Kamran Kashanian <[EMAIL PROTECTED]> wrote:
>
> A quick look at the UIXTreeTable code indicates that a non-null
> focusRowKey is assumed during decoding. During decoding, UIXTreeTable
bails
> out with code like this:
>
> Object path = getFocusRowKey();
> if (path == null)
> {
> // no data in this TreeTable
> return;
> }
>
> if a null focusRowKey is encountered.
>
> Perhaps a two step solution is in order:
>
> 1) Move the defaulting code to the renderer and call setFocusRowKey on
the
> component (short-term)
> 2) Change decoding/validation code in UIXTreeTable and utilities such as
> HierarchyUtils to handle a null focusRowKey (long-term)
>
> On 10/30/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> >
> > On 10/30/06, Arjuna Wijeyekoon < [EMAIL PROTECTED]> wrote:
> > > +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.
> >
> > Why? Shouldn't a null focusRowKey mean "decode everything"?
> > I'd prefer some reasonable behavior for this default, instead of
> > an absolute requirement on the renderer.
> >
> > -- Adam
> >
> >
> > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
