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/10/31 01:28:43 UTC
TreeTable focusRowKey
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.
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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Re: Re: TreeTable focusRowKey
Posted by Kamran Kashanian <ka...@gmail.com>.
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 Adam Winer <aw...@gmail.com>.
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 Kamran Kashanian <ka...@gmail.com>.
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 Kamran Kashanian <ka...@gmail.com>.
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 <ar...@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 <aw...@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 <ka...@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 Adam Winer <aw...@gmail.com>.
On 10/30/06, Arjuna Wijeyekoon <ar...@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 <aw...@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 <ka...@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: TreeTable focusRowKey
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
+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 <aw...@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 <ka...@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: TreeTable focusRowKey
Posted by Adam Winer <aw...@gmail.com>.
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 <ka...@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: TreeTable focusRowKey
Posted by venkata guddanti <ve...@gmail.com>.
On 10/30/06, Kamran Kashanian <ka...@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
>
>