You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Kamran Kashanian <ka...@gmail.com> on 2006/11/01 01:42:51 UTC
Re: Re: Re: TreeTable focusRowKey
OK. So we need to remove any defaulting of the focusRowKey attribute and fix
TreeTable decoding to support a null focusRowKey.
Arjuna - Based on your knowledge of TreeTable decoding, do you see any
issues with this?
On 10/31/06, Adam Winer <aw...@gmail.com> wrote:
>
> I think #2 should be the immediate solution, not the
> long-term change.
>
> -- Adam
>
>
> On 10/31/06, Kamran Kashanian <ka...@gmail.com> 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 <ka...@gmail.com> 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 <aw...@gmail.com> wrote:
> > > >
> > > > On 10/30/06, Arjuna Wijeyekoon < arjuna@gmail.com> 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 <awiner@gmail.com > 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 <ve...@gmail.com>
> wrote:
> > > > > > > On 10/30/06, Kamran Kashanian < kamrankashanian@gmail.com>
> > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Re: Re: TreeTable focusRowKey
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
hmm, We need to be careful not to break the UIXMenu hierarchy of components
which use a focusRowKey coming
from the MenuModel.
But I think we can do #2 without too much of a problem.
We should still do part of #1, which is move the defaulting to the Renderer.
--arjuna
On 10/31/06, Kamran Kashanian <ka...@gmail.com> wrote:
>
> OK. So we need to remove any defaulting of the focusRowKey attribute and
> fix
> TreeTable decoding to support a null focusRowKey.
>
> Arjuna - Based on your knowledge of TreeTable decoding, do you see any
> issues with this?
>
> On 10/31/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > I think #2 should be the immediate solution, not the
> > long-term change.
> >
> > -- Adam
> >
> >
> > On 10/31/06, Kamran Kashanian <ka...@gmail.com> 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 <ka...@gmail.com> 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 <aw...@gmail.com> wrote:
> > > > >
> > > > > On 10/30/06, Arjuna Wijeyekoon < arjuna@gmail.com> 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 <awiner@gmail.com > 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 <ve...@gmail.com>
> > wrote:
> > > > > > > > On 10/30/06, Kamran Kashanian < kamrankashanian@gmail.com>
> > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>