subject:"Tree2"


Hi *,

yes, I'd also like to do an Ajaxified version, but that's not the
first thing I'm looking at.

I believe that extending from UIData is not really what we should do -
UIData is totally row-based, and a row-index doesn't make so much
sense for a dynamic tree.

What are the tree and the table of trinidad sharing with the
UIXCollection interface?

regards,

Martin

On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

Hi M-

On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if we could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with selected nodes.
 Currently, selecting a node fires an action-listener. This is somewhat
 ok, but I believe the selection-model of a tree should rather be a
 list of values, stored at a useful place. Therefore, the tree should
 implement the EditableValueHolder-interface, then we could do a lot
 more with the values of the tree as well.

I am not really sure about the EditableValueHolder. In Trinidad the
Tree (UIXTree) is type of UIXCollection, which is also used by
UIXTable.

I remember some discussions from Sean in the past that they Tree2
should extend UIData instead of UIComponent(Base)


 The change would necessitate to move the current value attribute to
 some other name - I suppose the name model would be more appropriate

nothing wrong w/ using model instead of value, since value makes sense on
(editable)valueHolders to me...
(like UIOutput, UIInput, UISelect*,...)

 anyways (I've never understood why a dataTable has a
 value-attribute, by the way, the semantics for the value-attribute
 are generally quite different).

I guess they just simply introduced that since there was a value of
(edit.)value:_holders



 Additionally, the tree is doing a lot with respect to the markup of
 the component. I'm not sure if this is useful as very large HTML-bases
 result from this. I suspect it would be better to only transfer the
 data-model to the client (and maybe templates for each node-type), and
 then render the nodes on the client dynamically.

you mean sending xml to the client and using a JS_engine to render
on the client side?

-Matthias

 Thoughts?

 regards,

 Martin

 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Tree2


I think a tree is much more about sturctured data instead of input data


The UIXCollection is a base clazz for the stamping, that you can say
var on those tags.

UIComponent
|
+ - UIXComponent
  |
  + - UIXComponentBase
   |
   + UIXCollection

Collection has some subclasses like

UIXHierarchy
  |
  + UIXTree

and

UIXIterator
  |
  + UIXTable



The Trinidad Tree uses a TreeModel which extends CollectionModel
(Trin) which extends DataModel (Faces). CollectionModel is also used
by the Trin Table.

But, I am not really sure, why the table should be EditableValueHolder ?

Thanks!
-Matthias

On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Hi *,

yes, I'd also like to do an Ajaxified version, but that's not the
first thing I'm looking at.

I believe that extending from UIData is not really what we should do -
UIData is totally row-based, and a row-index doesn't make so much
sense for a dynamic tree.

What are the tree and the table of trinidad sharing with the
UIXCollection interface?

regards,

Martin

On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi M-

 On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hi *,
 
  I'm reviewing the tree2 currently, and I was wondering if we could
  have a discussion about some of the concepts.
 
  First thing I'd like to discuss is what happens with selected nodes.
  Currently, selecting a node fires an action-listener. This is somewhat
  ok, but I believe the selection-model of a tree should rather be a
  list of values, stored at a useful place. Therefore, the tree should
  implement the EditableValueHolder-interface, then we could do a lot
  more with the values of the tree as well.

 I am not really sure about the EditableValueHolder. In Trinidad the
 Tree (UIXTree) is type of UIXCollection, which is also used by
 UIXTable.

 I remember some discussions from Sean in the past that they Tree2
 should extend UIData instead of UIComponent(Base)


  The change would necessitate to move the current value attribute to
  some other name - I suppose the name model would be more appropriate

 nothing wrong w/ using model instead of value, since value makes sense on
 (editable)valueHolders to me...
 (like UIOutput, UIInput, UISelect*,...)

  anyways (I've never understood why a dataTable has a
  value-attribute, by the way, the semantics for the value-attribute
  are generally quite different).

 I guess they just simply introduced that since there was a value of
 (edit.)value:_holders


 
  Additionally, the tree is doing a lot with respect to the markup of
  the component. I'm not sure if this is useful as very large HTML-bases
  result from this. I suspect it would be better to only transfer the
  data-model to the client (and maybe templates for each node-type), and
  then render the nodes on the client dynamically.

 you mean sending xml to the client and using a JS_engine to render
 on the client side?

 -Matthias
 
  Thoughts?
 
  regards,
 
  Martin
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 


 --
 Matthias Wessendorf
 http://tinyurl.com/fmywh

 further stuff:
 blog: http://jroller.com/page/mwessendorf
 mail: mwessendorf-at-gmail-dot-com



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Tree2


Hi Matthias,

for the reason that every component that has changing values needs to
be an editable value holder. Imagine the case of a tree embedded in a
data-table - a data-table, at least the ones of both MyFaces and the
RI (I know, Trinidad's data-table does something different) only save
whatever is part of the EditableValueHolder interface.

So the selection model of a tree won't be saved in a dataTable, except
it is part of the EditableValueHolder interface.

regards,

Martin

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

I think a tree is much more about sturctured data instead of input data


The UIXCollection is a base clazz for the stamping, that you can say
var on those tags.

UIComponent
 |
 + - UIXComponent
   |
   + - UIXComponentBase
|
+ UIXCollection

Collection has some subclasses like

UIXHierarchy
   |
   + UIXTree

and

UIXIterator
   |
   + UIXTable



The Trinidad Tree uses a TreeModel which extends CollectionModel
(Trin) which extends DataModel (Faces). CollectionModel is also used
by the Trin Table.

But, I am not really sure, why the table should be EditableValueHolder ?

Thanks!
-Matthias

On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi *,

 yes, I'd also like to do an Ajaxified version, but that's not the
 first thing I'm looking at.

 I believe that extending from UIData is not really what we should do -
 UIData is totally row-based, and a row-index doesn't make so much
 sense for a dynamic tree.

 What are the tree and the table of trinidad sharing with the
 UIXCollection interface?

 regards,

 Martin

 On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi M-
 
  On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hi *,
  
   I'm reviewing the tree2 currently, and I was wondering if we could
   have a discussion about some of the concepts.
  
   First thing I'd like to discuss is what happens with selected nodes.
   Currently, selecting a node fires an action-listener. This is somewhat
   ok, but I believe the selection-model of a tree should rather be a
   list of values, stored at a useful place. Therefore, the tree should
   implement the EditableValueHolder-interface, then we could do a lot
   more with the values of the tree as well.
 
  I am not really sure about the EditableValueHolder. In Trinidad the
  Tree (UIXTree) is type of UIXCollection, which is also used by
  UIXTable.
 
  I remember some discussions from Sean in the past that they Tree2
  should extend UIData instead of UIComponent(Base)
 
 
   The change would necessitate to move the current value attribute to
   some other name - I suppose the name model would be more appropriate
 
  nothing wrong w/ using model instead of value, since value makes sense on
  (editable)valueHolders to me...
  (like UIOutput, UIInput, UISelect*,...)
 
   anyways (I've never understood why a dataTable has a
   value-attribute, by the way, the semantics for the value-attribute
   are generally quite different).
 
  I guess they just simply introduced that since there was a value of
  (edit.)value:_holders
 
 
  
   Additionally, the tree is doing a lot with respect to the markup of
   the component. I'm not sure if this is useful as very large HTML-bases
   result from this. I suspect it would be better to only transfer the
   data-model to the client (and maybe templates for each node-type), and
   then render the nodes on the client dynamically.
 
  you mean sending xml to the client and using a JS_engine to render
  on the client side?
 
  -Matthias
  
   Thoughts?
  
   regards,
  
   Martin
  
   --
  
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Tree2


I think a tree should display structured data and not be an input component.
What should the input be? So you are willing register also validators
on the tree?

maybe that is more specialized use case instead a generic tree use
case you are looking at.

On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Hi Matthias,

for the reason that every component that has changing values needs to
be an editable value holder. Imagine the case of a tree embedded in a
data-table - a data-table, at least the ones of both MyFaces and the
RI (I know, Trinidad's data-table does something different) only save
whatever is part of the EditableValueHolder interface.

So the selection model of a tree won't be saved in a dataTable, except
it is part of the EditableValueHolder interface.

regards,

Martin

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 I think a tree is much more about sturctured data instead of input data


 The UIXCollection is a base clazz for the stamping, that you can say
 var on those tags.

 UIComponent
  |
  + - UIXComponent
|
+ - UIXComponentBase
 |
 + UIXCollection

 Collection has some subclasses like

 UIXHierarchy
|
+ UIXTree

 and

 UIXIterator
|
+ UIXTable



 The Trinidad Tree uses a TreeModel which extends CollectionModel
 (Trin) which extends DataModel (Faces). CollectionModel is also used
 by the Trin Table.

 But, I am not really sure, why the table should be EditableValueHolder ?

 Thanks!
 -Matthias

 On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hi *,
 
  yes, I'd also like to do an Ajaxified version, but that's not the
  first thing I'm looking at.
 
  I believe that extending from UIData is not really what we should do -
  UIData is totally row-based, and a row-index doesn't make so much
  sense for a dynamic tree.
 
  What are the tree and the table of trinidad sharing with the
  UIXCollection interface?
 
  regards,
 
  Martin
 
  On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi M-
  
   On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
   
I'm reviewing the tree2 currently, and I was wondering if we could
have a discussion about some of the concepts.
   
First thing I'd like to discuss is what happens with selected nodes.
Currently, selecting a node fires an action-listener. This is somewhat
ok, but I believe the selection-model of a tree should rather be a
list of values, stored at a useful place. Therefore, the tree should
implement the EditableValueHolder-interface, then we could do a lot
more with the values of the tree as well.
  
   I am not really sure about the EditableValueHolder. In Trinidad the
   Tree (UIXTree) is type of UIXCollection, which is also used by
   UIXTable.
  
   I remember some discussions from Sean in the past that they Tree2
   should extend UIData instead of UIComponent(Base)
  
  
The change would necessitate to move the current value attribute to
some other name - I suppose the name model would be more appropriate
  
   nothing wrong w/ using model instead of value, since value makes sense on
   (editable)valueHolders to me...
   (like UIOutput, UIInput, UISelect*,...)
  
anyways (I've never understood why a dataTable has a
value-attribute, by the way, the semantics for the value-attribute
are generally quite different).
  
   I guess they just simply introduced that since there was a value of
   (edit.)value:_holders
  
  
   
Additionally, the tree is doing a lot with respect to the markup of
the component. I'm not sure if this is useful as very large HTML-bases
result from this. I suspect it would be better to only transfer the
data-model to the client (and maybe templates for each node-type), and
then render the nodes on the client dynamically.
  
   you mean sending xml to the client and using a JS_engine to render
   on the client side?
  
   -Matthias
   
Thoughts?
   
regards,
   
Martin
   
--
   
http://www.irian.at
   
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
  
  
   --
   Matthias Wessendorf
   http://tinyurl.com/fmywh
  
   further stuff:
   blog: http://jroller.com/page/mwessendorf
   mail: mwessendorf-at-gmail-dot-com
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 


 --
 Matthias Wessendorf
 http://tinyurl.com/fmywh

 further stuff:
 blog: http://jroller.com/page/mwessendorf
 mail: mwessendorf-at-gmail-dot-com



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Tree2


also why should a tree, used for navigation structure be an editable
value holder?
It just structures data :)

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

I think a tree should display structured data and not be an input component.
What should the input be? So you are willing register also validators
on the tree?

maybe that is more specialized use case instead a generic tree use
case you are looking at.

On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi Matthias,

 for the reason that every component that has changing values needs to
 be an editable value holder. Imagine the case of a tree embedded in a
 data-table - a data-table, at least the ones of both MyFaces and the
 RI (I know, Trinidad's data-table does something different) only save
 whatever is part of the EditableValueHolder interface.

 So the selection model of a tree won't be saved in a dataTable, except
 it is part of the EditableValueHolder interface.

 regards,

 Martin

 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I think a tree is much more about sturctured data instead of input data
 
 
  The UIXCollection is a base clazz for the stamping, that you can say
  var on those tags.
 
  UIComponent
   |
   + - UIXComponent
 |
 + - UIXComponentBase
  |
  + UIXCollection
 
  Collection has some subclasses like
 
  UIXHierarchy
 |
 + UIXTree
 
  and
 
  UIXIterator
 |
 + UIXTable
 
 
 
  The Trinidad Tree uses a TreeModel which extends CollectionModel
  (Trin) which extends DataModel (Faces). CollectionModel is also used
  by the Trin Table.
 
  But, I am not really sure, why the table should be EditableValueHolder ?
 
  Thanks!
  -Matthias
 
  On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hi *,
  
   yes, I'd also like to do an Ajaxified version, but that's not the
   first thing I'm looking at.
  
   I believe that extending from UIData is not really what we should do -
   UIData is totally row-based, and a row-index doesn't make so much
   sense for a dynamic tree.
  
   What are the tree and the table of trinidad sharing with the
   UIXCollection interface?
  
   regards,
  
   Martin
  
   On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi M-
   
On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if we could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with selected nodes.
 Currently, selecting a node fires an action-listener. This is somewhat
 ok, but I believe the selection-model of a tree should rather be a
 list of values, stored at a useful place. Therefore, the tree should
 implement the EditableValueHolder-interface, then we could do a lot
 more with the values of the tree as well.
   
I am not really sure about the EditableValueHolder. In Trinidad the
Tree (UIXTree) is type of UIXCollection, which is also used by
UIXTable.
   
I remember some discussions from Sean in the past that they Tree2
should extend UIData instead of UIComponent(Base)
   
   
 The change would necessitate to move the current value attribute to
 some other name - I suppose the name model would be more appropriate
   
nothing wrong w/ using model instead of value, since value makes sense 
on
(editable)valueHolders to me...
(like UIOutput, UIInput, UISelect*,...)
   
 anyways (I've never understood why a dataTable has a
 value-attribute, by the way, the semantics for the value-attribute
 are generally quite different).
   
I guess they just simply introduced that since there was a value of
(edit.)value:_holders
   
   

 Additionally, the tree is doing a lot with respect to the markup of
 the component. I'm not sure if this is useful as very large HTML-bases
 result from this. I suspect it would be better to only transfer the
 data-model to the client (and maybe templates for each node-type), and
 then render the nodes on the client dynamically.
   
you mean sending xml to the client and using a JS_engine to render
on the client side?
   
-Matthias

 Thoughts?

 regards,

 Martin

 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

   
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
  
   --
  
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail

Re: Tree2


I haven't said that there is no value for that.
But I am abit against a super tree component :)
Maybe there is value for a specialized editable tree or what ever. I
know scenarios where that would be nice. but on the other hand you
don't want this overhead when just displaying structured data.

I think same is true for an editable table
(not a table w/ inputText in it... ;) )

-M

On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:

Matthias,

I think the Tree component can be used in contexts beyond navigation - for
example, it can be implemented for Content/Document management where a
Category-DocumentType heirarchy needs to be user managed and editable based
on their changing business process and the type of content they wish to
classify.

In the .NET world - this excellent Tree component also supports Node editing
for such scenarios:

http://www.componentart.com/treeview/features.aspx

I believe there is value in the use-case Martin is describing.

Cheers,

Zubin.



On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 also why should a tree, used for navigation structure be an editable
 value holder?
 It just structures data :)

 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I think a tree should display structured data and not be an input
component.
  What should the input be? So you are willing register also validators
  on the tree?
 
  maybe that is more specialized use case instead a generic tree use
  case you are looking at.
 
  On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hi Matthias,
  
   for the reason that every component that has changing values needs to
   be an editable value holder. Imagine the case of a tree embedded in a
   data-table - a data-table, at least the ones of both MyFaces and the
   RI (I know, Trinidad's data-table does something different) only save
   whatever is part of the EditableValueHolder interface.
  
   So the selection model of a tree won't be saved in a dataTable, except
   it is part of the EditableValueHolder interface.
  
   regards,
  
   Martin
  
   On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree is much more about sturctured data instead of
input data
   
   
The UIXCollection is a base clazz for the stamping, that you can
say
var on those tags.
   
UIComponent
 |
 + - UIXComponent
   |
   + - UIXComponentBase
|
+ UIXCollection
   
Collection has some subclasses like
   
UIXHierarchy
   |
   + UIXTree
   
and
   
UIXIterator
   |
   + UIXTable
   
   
   
The Trinidad Tree uses a TreeModel which extends CollectionModel
(Trin) which extends DataModel (Faces). CollectionModel is also used
by the Trin Table.
   
But, I am not really sure, why the table should be
EditableValueHolder ?
   
Thanks!
-Matthias
   
On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi *,

 yes, I'd also like to do an Ajaxified version, but that's not the
 first thing I'm looking at.

 I believe that extending from UIData is not really what we should
do -
 UIData is totally row-based, and a row-index doesn't make so much
 sense for a dynamic tree.

 What are the tree and the table of trinidad sharing with the
 UIXCollection interface?

 regards,

 Martin

 On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
  Hi M-
 
  On 10/4/06, Martin Marinschek [EMAIL PROTECTED]
wrote:
   Hi *,
  
   I'm reviewing the tree2 currently, and I was wondering if we
could
   have a discussion about some of the concepts.
  
   First thing I'd like to discuss is what happens with selected
nodes.
   Currently, selecting a node fires an action-listener. This is
somewhat
   ok, but I believe the selection-model of a tree should rather
be a
   list of values, stored at a useful place. Therefore, the tree
should
   implement the EditableValueHolder-interface, then we could do
a lot
   more with the values of the tree as well.
 
  I am not really sure about the EditableValueHolder. In Trinidad
the
  Tree (UIXTree) is type of UIXCollection, which is also used by
  UIXTable.
 
  I remember some discussions from Sean in the past that they
Tree2
  should extend UIData instead of UIComponent(Base)
 
 
   The change would necessitate to move the current value
attribute to
   some other name - I suppose the name model would be more
appropriate
 
  nothing wrong w/ using model instead of value, since value makes
sense on
  (editable)valueHolders to me...
  (like UIOutput, UIInput, UISelect*,...)
 
   anyways (I've never understood why a dataTable has a
   value-attribute, by the way, the semantics for the
value-attribute
   are generally quite different).
 
  I guess they just simply introduced that since

Re: Tree2


For better scope control perhaps we should have a baseTree and an
advancedTree component set?


yeah, maybe we go the route like Faces does it self.
A generic component (UITree) and some more specialized
(EditableTree) or what ever.

-M



Cheers,

Zubin.

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 I haven't said that there is no value for that.
 But I am abit against a super tree component :)
 Maybe there is value for a specialized editable tree or what ever. I
 know scenarios where that would be nice. but on the other hand you
 don't want this overhead when just displaying structured data.

 I think same is true for an editable table
 (not a table w/ inputText in it... ;) )

 -M

 On 10/5/06, Zubin Wadia  [EMAIL PROTECTED] wrote:
  Matthias,
 
  I think the Tree component can be used in contexts beyond navigation -
for
  example, it can be implemented for Content/Document management where a
  Category-DocumentType heirarchy needs to be user managed and editable
based
  on their changing business process and the type of content they wish to
  classify.
 
  In the .NET world - this excellent Tree component also supports Node
editing
  for such scenarios:
 
  http://www.componentart.com/treeview/features.aspx
 
  I believe there is value in the use-case Martin is describing.
 
  Cheers,
 
  Zubin.
 
 
 
  On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   also why should a tree, used for navigation structure be an editable
   value holder?
   It just structures data :)
  
   On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree should display structured data and not be an input
  component.
What should the input be? So you are willing register also
validators
on the tree?
   
maybe that is more specialized use case instead a generic tree
use
case you are looking at.
   
On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi Matthias,

 for the reason that every component that has changing values needs
to
 be an editable value holder. Imagine the case of a tree embedded
in a
 data-table - a data-table, at least the ones of both MyFaces and
the
 RI (I know, Trinidad's data-table does something different) only
save
 whatever is part of the EditableValueHolder interface.

 So the selection model of a tree won't be saved in a dataTable,
except
 it is part of the EditableValueHolder interface.

 regards,

 Martin

 On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  I think a tree is much more about sturctured data instead of
  input data
 
 
  The UIXCollection is a base clazz for the stamping, that you
can
  say
  var on those tags.
 
  UIComponent
   |
   + - UIXComponent
 |
 + - UIXComponentBase
  |
  + UIXCollection
 
  Collection has some subclasses like
 
  UIXHierarchy
 |
 + UIXTree
 
  and
 
  UIXIterator
 |
 + UIXTable
 
 
 
  The Trinidad Tree uses a TreeModel which extends
CollectionModel
  (Trin) which extends DataModel (Faces). CollectionModel is also
used
  by the Trin Table.
 
  But, I am not really sure, why the table should be
  EditableValueHolder ?
 
  Thanks!
  -Matthias
 
  On 10/5/06, Martin Marinschek  [EMAIL PROTECTED]
wrote:
   Hi *,
  
   yes, I'd also like to do an Ajaxified version, but that's not
the
   first thing I'm looking at.
  
   I believe that extending from UIData is not really what we
should
  do -
   UIData is totally row-based, and a row-index doesn't make so
much
   sense for a dynamic tree.
  
   What are the tree and the table of trinidad sharing with the
   UIXCollection interface?
  
   regards,
  
   Martin
  
   On 10/4/06, Matthias Wessendorf  [EMAIL PROTECTED]  wrote:
Hi M-
   
On 10/4/06, Martin Marinschek  [EMAIL PROTECTED]
  wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if
we
  could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with
selected
  nodes.
 Currently, selecting a node fires an action-listener. This
is
  somewhat
 ok, but I believe the selection-model of a tree should
rather
  be a
 list of values, stored at a useful place. Therefore, the
tree
  should
 implement the EditableValueHolder-interface, then we could
do
  a lot
 more with the values of the tree as well.
   
I am not really sure about the EditableValueHolder. In
Trinidad
  the
Tree (UIXTree) is type of UIXCollection, which is also used
by
UIXTable.
   
I remember some discussions from Sean in the past that they
  Tree2
should extend UIData instead

Re: Tree2


regarding the ajaxized version, would be cool if the renderer takes
care of dojo.
rendering out the dojo:widget / things and adding the dojo.js
file to the *header* of the page. So the widget builds the client
treee.

-M

On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:

Right on. I think drag and drop node switching and editing should be part
of an AJAXized implementation of the Tree component as that model suits it
better.

For better scope control perhaps we should have a baseTree and an
advancedTree component set?


Cheers,

Zubin.

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 I haven't said that there is no value for that.
 But I am abit against a super tree component :)
 Maybe there is value for a specialized editable tree or what ever. I
 know scenarios where that would be nice. but on the other hand you
 don't want this overhead when just displaying structured data.

 I think same is true for an editable table
 (not a table w/ inputText in it... ;) )

 -M

 On 10/5/06, Zubin Wadia  [EMAIL PROTECTED] wrote:
  Matthias,
 
  I think the Tree component can be used in contexts beyond navigation -
for
  example, it can be implemented for Content/Document management where a
  Category-DocumentType heirarchy needs to be user managed and editable
based
  on their changing business process and the type of content they wish to
  classify.
 
  In the .NET world - this excellent Tree component also supports Node
editing
  for such scenarios:
 
  http://www.componentart.com/treeview/features.aspx
 
  I believe there is value in the use-case Martin is describing.
 
  Cheers,
 
  Zubin.
 
 
 
  On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   also why should a tree, used for navigation structure be an editable
   value holder?
   It just structures data :)
  
   On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree should display structured data and not be an input
  component.
What should the input be? So you are willing register also
validators
on the tree?
   
maybe that is more specialized use case instead a generic tree
use
case you are looking at.
   
On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi Matthias,

 for the reason that every component that has changing values needs
to
 be an editable value holder. Imagine the case of a tree embedded
in a
 data-table - a data-table, at least the ones of both MyFaces and
the
 RI (I know, Trinidad's data-table does something different) only
save
 whatever is part of the EditableValueHolder interface.

 So the selection model of a tree won't be saved in a dataTable,
except
 it is part of the EditableValueHolder interface.

 regards,

 Martin

 On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  I think a tree is much more about sturctured data instead of
  input data
 
 
  The UIXCollection is a base clazz for the stamping, that you
can
  say
  var on those tags.
 
  UIComponent
   |
   + - UIXComponent
 |
 + - UIXComponentBase
  |
  + UIXCollection
 
  Collection has some subclasses like
 
  UIXHierarchy
 |
 + UIXTree
 
  and
 
  UIXIterator
 |
 + UIXTable
 
 
 
  The Trinidad Tree uses a TreeModel which extends
CollectionModel
  (Trin) which extends DataModel (Faces). CollectionModel is also
used
  by the Trin Table.
 
  But, I am not really sure, why the table should be
  EditableValueHolder ?
 
  Thanks!
  -Matthias
 
  On 10/5/06, Martin Marinschek  [EMAIL PROTECTED]
wrote:
   Hi *,
  
   yes, I'd also like to do an Ajaxified version, but that's not
the
   first thing I'm looking at.
  
   I believe that extending from UIData is not really what we
should
  do -
   UIData is totally row-based, and a row-index doesn't make so
much
   sense for a dynamic tree.
  
   What are the tree and the table of trinidad sharing with the
   UIXCollection interface?
  
   regards,
  
   Martin
  
   On 10/4/06, Matthias Wessendorf  [EMAIL PROTECTED]  wrote:
Hi M-
   
On 10/4/06, Martin Marinschek  [EMAIL PROTECTED]
  wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if
we
  could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with
selected
  nodes.
 Currently, selecting a node fires an action-listener. This
is
  somewhat
 ok, but I believe the selection-model of a tree should
rather
  be a
 list of values, stored at a useful place. Therefore, the
tree
  should
 implement the EditableValueHolder-interface, then we could
do
  a lot
 more with the values of the tree as well

Re: Tree2

2006-10-05 Thread Zubin Wadia

Precisely! Perhaps Werner can chime in some more on this too..Z.On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED]
wrote:regarding the ajaxized version, would be cool if the renderer takes
care of dojo.rendering out the dojo:widget / things and adding the dojo.jsfile to the *header* of the page. So the widget builds the clienttreee.-MOn 10/5/06, Zubin Wadia
[EMAIL PROTECTED] wrote: Right on. I think drag and drop node switching and editing should be part of an AJAXized implementation of the Tree component as that model suits it
better. For better scope control perhaps we should have a baseTree and an advancedTree component set? Cheers, Zubin. On 10/5/06, Matthias Wessendorf
[EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I
know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table
(not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias,
I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable
based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node
editing for such scenarios: http://www.componentart.com/treeview/features.aspx
I believe there is value in the use-case Martin is describing. Cheers, Zubin.
On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:also why should a tree, used for navigation structure be an editablevalue holder?
It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input
component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree
use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED]
wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded
in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only
save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable,
except it is part of the EditableValueHolder interface. regards, Martin
On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of
input data The UIXCollection is a base clazz for the stamping, that you
can say var on those tags. UIComponent |
+ - UIXComponent | + - UIXComponentBase |
+ UIXCollection Collection has some subclasses like UIXHierarchy
| + UIXTree and UIXIterator
| + UIXTable The Trinidad Tree uses a TreeModel which extends
CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table.
But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias
On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:Hi *,
yes, I'd also like to do an Ajaxified version, but that's not thefirst thing I'm looking at.
I believe that extending from UIData is not really what we should do -UIData is totally row-based, and a row-index doesn't make so
muchsense for a dynamic tree. What are the tree and the table of trinidad sharing with the
UIXCollection interface? regards, Martin
On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M-
On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *, I'm reviewing the tree2 currently, and I was wondering if
we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with
selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should
rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface

Re: Tree2


I bet! :)

On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:

Precisely! Perhaps Werner can chime in some more on this too..


Z.

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 regarding the ajaxized version, would be cool if the renderer takes
 care of dojo.
 rendering out the dojo:widget / things and adding the dojo.js
 file to the *header* of the page. So the widget builds the client
 treee.

 -M

 On 10/5/06, Zubin Wadia  [EMAIL PROTECTED] wrote:
  Right on. I think drag and drop node switching and editing should be
part
  of an AJAXized implementation of the Tree component as that model suits
it
  better.
 
  For better scope control perhaps we should have a baseTree and an
  advancedTree component set?
 
 
  Cheers,
 
  Zubin.
 
  On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   I haven't said that there is no value for that.
   But I am abit against a super tree component :)
   Maybe there is value for a specialized editable tree or what ever. I
   know scenarios where that would be nice. but on the other hand you
   don't want this overhead when just displaying structured data.
  
   I think same is true for an editable table
   (not a table w/ inputText in it... ;) )
  
   -M
  
   On 10/5/06, Zubin Wadia  [EMAIL PROTECTED] wrote:
Matthias,
   
I think the Tree component can be used in contexts beyond navigation
-
  for
example, it can be implemented for Content/Document management where
a
Category-DocumentType heirarchy needs to be user managed and
editable
  based
on their changing business process and the type of content they wish
to
classify.
   
In the .NET world - this excellent Tree component also supports Node
  editing
for such scenarios:
   
http://www.componentart.com/treeview/features.aspx
   
I believe there is value in the use-case Martin is describing.
   
Cheers,
   
Zubin.
   
   
   
On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 also why should a tree, used for navigation structure be an
editable
 value holder?
 It just structures data :)

 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I think a tree should display structured data and not be an
input
component.
  What should the input be? So you are willing register also
  validators
  on the tree?
 
  maybe that is more specialized use case instead a generic
tree
  use
  case you are looking at.
 
  On 10/5/06, Martin Marinschek [EMAIL PROTECTED] 
wrote:
   Hi Matthias,
  
   for the reason that every component that has changing values
needs
  to
   be an editable value holder. Imagine the case of a tree
embedded
  in a
   data-table - a data-table, at least the ones of both MyFaces
and
  the
   RI (I know, Trinidad's data-table does something different)
only
  save
   whatever is part of the EditableValueHolder interface.
  
   So the selection model of a tree won't be saved in a
dataTable,
  except
   it is part of the EditableValueHolder interface.
  
   regards,
  
   Martin
  
   On 10/5/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
I think a tree is much more about sturctured data instead
of
input data
   
   
The UIXCollection is a base clazz for the stamping, that
you
  can
say
var on those tags.
   
UIComponent
 |
 + - UIXComponent
   |
   + - UIXComponentBase
|
+ UIXCollection
   
Collection has some subclasses like
   
UIXHierarchy
   |
   + UIXTree
   
and
   
UIXIterator
   |
   + UIXTable
   
   
   
The Trinidad Tree uses a TreeModel which extends
  CollectionModel
(Trin) which extends DataModel (Faces). CollectionModel is
also
  used
by the Trin Table.
   
But, I am not really sure, why the table should be
EditableValueHolder ?
   
Thanks!
-Matthias
   
On 10/5/06, Martin Marinschek  [EMAIL PROTECTED]
  wrote:
 Hi *,

 yes, I'd also like to do an Ajaxified version, but that's
not
  the
 first thing I'm looking at.

 I believe that extending from UIData is not really what we
  should
do -
 UIData is totally row-based, and a row-index doesn't make
so
  much
 sense for a dynamic tree.

 What are the tree and the table of trinidad sharing with
the
 UIXCollection interface?

 regards,

 Martin

 On 10/4/06, Matthias Wessendorf  [EMAIL PROTECTED] 
wrote:
  Hi M-
 
  On 10/4/06, Martin Marinschek 
[EMAIL PROTECTED]
wrote:
   Hi *,
  
   I'm reviewing the tree2 currently, and I was wondering
if
  we
could

[jira] Created: (TOMAHAWK-727) tree2 do not work with clientSideToggle=true and preserveToggle=false

2006-10-05 Thread Mario Ivankovits (JIRA)

tree2 do not work with clientSideToggle=true and preserveToggle=false
-

 Key: TOMAHAWK-727
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-727
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Mario Ivankovits


The reason is that the server side treeModel do not know which nodes are 
expanded and so do not call decode on them.

1) In HtmlTreeRenderer.decode
If a node is expanded or not will be restored from the cookie (client-side) or 
from a request parameter (server-side)
There the case that in client-side toggle there is no cookie will not be honored

2) UITreeData.processNodes
There the TreeWalker see a all nodes closed tree and stops traversing

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-727) tree2 do not work with clientSideToggle=true and preserveToggle=false

2006-10-05 Thread Mario Ivankovits (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-727?page=comments#action_12440099 
] 

Mario Ivankovits commented on TOMAHAWK-727:
---

IMHO the correct solution is to transfer the tree state through a hidden field.

The problem one might have then is, that the tree will show the nodes 
expanded after postback (even without preserverToggle).
For me having the nodes expanded is the behavior I await from the tree.

Any objections?

 tree2 do not work with clientSideToggle=true and preserveToggle=false
 -

 Key: TOMAHAWK-727
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-727
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Mario Ivankovits

 The reason is that the server side treeModel do not know which nodes are 
 expanded and so do not call decode on them.
 1) In HtmlTreeRenderer.decode
 If a node is expanded or not will be restored from the cookie (client-side) 
 or from a request parameter (server-side)
 There the case that in client-side toggle there is no cookie will not be 
 honored
 2) UITreeData.processNodes
 There the TreeWalker see a all nodes closed tree and stops traversing

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Tree2

2006-10-05 Thread Werner Punz

Let me read the entire thread first :-)
later tonight

Matthias Wessendorf schrieb:
 I bet! :)
 
 On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:
 Precisely! Perhaps Werner can chime in some more on this too..


 Z.

Re: Tree2

2006-10-05 Thread Arash Rajaeeyan

Hello Mattias,

I am so new to this list and may be I am not allowed to say this, but I
think most developers I have seen use menu related components for only
displaying structured data, and most of times data is displayed to user for one
of the following purposes:

1) selecting one item
2) selecting multiple item
3) displaying and editing tree structured data (like organization chart,
directory services, etc)

the first 2 options are currently supported features of tree2, the 3'rd is
under debate.

May be if we can use same parent for both menu and tree navigation related
components and simple tree data structure as said by matias and zubin, for
parent of all these components can have following benefits:

1) simplifying development
2) simplifying learning for users
3) making it easier to add more advanced trees later on demand

Best regards

Arash

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree should display structured data and not be an input component.What should the input be? So you are willing register also validatorson the tree?maybe that is more specialized use case instead a generic tree use
case you are looking at.On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to
be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save
whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards,
Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data
The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent |
+ - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like
UIXHierarchy | + UIXTree and UIXIterator | + UIXTable
The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table.
But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek
[EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at.
I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree.
What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin
On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi M- On 10/4/06, Martin Marinschek
[EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could
have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat
ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot
more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad theTree (UIXTree) is type of UIXCollection, which is also used by
UIXTable. I remember some discussions from Sean in the past that they Tree2should extend UIData instead of UIComponent(Base)
The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate
nothing wrong w/ using model instead of value, since value makes sense on(editable)valueHolders to me...(like UIOutput, UIInput, UISelect*,...)
anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different).
I guess they just simply introduced that since there was a value of(edit.)value:_holders
Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases
result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically.
you mean sending xml to the client and using a JS_engine to renderon the client side? -Matthias
Thoughts? regards, Martin
-- http://www.irian.at Your JSF powerhouse -
JSF Consulting, Development

Re: Tree2


hi Arash,

sure your feedback is welcome :)

like said before, a generic raw version + aditional tree stuff.
During that task we should also take a look at tree / treeTable, IMHO.

-M

On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:



Hello Mattias,

I am so new to this list and may be I am not allowed to say this, but I
think most developers I have seen use menu related components for only
displaying structured data, and most of times data is displayed to user for
one of the following purposes:

1) selecting one item
 2) selecting multiple item
 3) displaying and editing tree structured data (like organization chart,
directory services, etc)

 the first 2 options are currently supported features of tree2, the 3'rd is
under debate.

May be if we can use same parent for both menu and tree navigation related
components and simple tree data structure as said by matias and zubin, for
parent of all these components can have following benefits:

 1) simplifying development
 2) simplifying learning for users
 3) making it easier to add more advanced trees later on demand

Best regards

Arash



On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 I think a tree should display structured data and not be an input
component.
 What should the input be? So you are willing register also validators
 on the tree?

 maybe that is more specialized use case instead a generic tree use
 case you are looking at.

 On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hi Matthias,
 
  for the reason that every component that has changing values needs to
  be an editable value holder. Imagine the case of a tree embedded in a
  data-table - a data-table, at least the ones of both MyFaces and the
  RI (I know, Trinidad's data-table does something different) only save
  whatever is part of the EditableValueHolder interface.
 
  So the selection model of a tree won't be saved in a dataTable, except
  it is part of the EditableValueHolder interface.
 
  regards,
 
  Martin
 
  On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   I think a tree is much more about sturctured data instead of input
data
  
  
   The UIXCollection is a base clazz for the stamping, that you can say
   var on those tags.
  
   UIComponent
|
+ - UIXComponent
  |
  + - UIXComponentBase
   |
   + UIXCollection
  
   Collection has some subclasses like
  
   UIXHierarchy
  |
  + UIXTree
  
   and
  
   UIXIterator
  |
  + UIXTable
  
  
  
   The Trinidad Tree uses a TreeModel which extends CollectionModel
   (Trin) which extends DataModel (Faces). CollectionModel is also used
   by the Trin Table.
  
   But, I am not really sure, why the table should be EditableValueHolder
?
  
   Thanks!
   -Matthias
  
   On 10/5/06, Martin Marinschek  [EMAIL PROTECTED] wrote:
Hi *,
   
yes, I'd also like to do an Ajaxified version, but that's not the
first thing I'm looking at.
   
I believe that extending from UIData is not really what we should do
-
UIData is totally row-based, and a row-index doesn't make so much
sense for a dynamic tree.
   
What are the tree and the table of trinidad sharing with the
UIXCollection interface?
   
regards,
   
Martin
   
On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi M-

 On 10/4/06, Martin Marinschek  [EMAIL PROTECTED]
wrote:
  Hi *,
 
  I'm reviewing the tree2 currently, and I was wondering if we
could
  have a discussion about some of the concepts.
 
  First thing I'd like to discuss is what happens with selected
nodes.
  Currently, selecting a node fires an action-listener. This is
somewhat
  ok, but I believe the selection-model of a tree should rather be
a
  list of values, stored at a useful place. Therefore, the tree
should
  implement the EditableValueHolder-interface, then we could do a
lot
  more with the values of the tree as well.

 I am not really sure about the EditableValueHolder. In Trinidad
the
 Tree (UIXTree) is type of UIXCollection, which is also used by
 UIXTable.

 I remember some discussions from Sean in the past that they Tree2
 should extend UIData instead of UIComponent(Base)


  The change would necessitate to move the current value
attribute to
  some other name - I suppose the name model would be more
appropriate

 nothing wrong w/ using model instead of value, since value makes
sense on
 (editable)valueHolders to me...
 (like UIOutput, UIInput, UISelect*,...)

  anyways (I've never understood why a dataTable has a
  value-attribute, by the way, the semantics for the
value-attribute
  are generally quite different).

 I guess they just simply introduced that since there was a value
of
 (edit.)value:_holders


 
  Additionally, the tree is doing a lot with respect to the markup
of
  the component. I'm

Re: Tree2


Well, it wouldn't be a problem to have an extended version of the tree
which implements EditableValueHolder, but not if the model of the tree
is configured by setting the value-attribute - then extending won't
work.

regards,

Martin

On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

hi Arash,

sure your feedback is welcome :)

like said before, a generic raw version + aditional tree stuff.
During that task we should also take a look at tree / treeTable, IMHO.

-M

On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:


 Hello Mattias,

 I am so new to this list and may be I am not allowed to say this, but I
 think most developers I have seen use menu related components for only
 displaying structured data, and most of times data is displayed to user for
 one of the following purposes:

 1) selecting one item
  2) selecting multiple item
  3) displaying and editing tree structured data (like organization chart,
 directory services, etc)

  the first 2 options are currently supported features of tree2, the 3'rd is
 under debate.

 May be if we can use same parent for both menu and tree navigation related
 components and simple tree data structure as said by matias and zubin, for
 parent of all these components can have following benefits:

  1) simplifying development
  2) simplifying learning for users
  3) making it easier to add more advanced trees later on demand

 Best regards

 Arash



 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I think a tree should display structured data and not be an input
 component.
  What should the input be? So you are willing register also validators
  on the tree?
 
  maybe that is more specialized use case instead a generic tree use
  case you are looking at.
 
  On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hi Matthias,
  
   for the reason that every component that has changing values needs to
   be an editable value holder. Imagine the case of a tree embedded in a
   data-table - a data-table, at least the ones of both MyFaces and the
   RI (I know, Trinidad's data-table does something different) only save
   whatever is part of the EditableValueHolder interface.
  
   So the selection model of a tree won't be saved in a dataTable, except
   it is part of the EditableValueHolder interface.
  
   regards,
  
   Martin
  
   On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree is much more about sturctured data instead of input
 data
   
   
The UIXCollection is a base clazz for the stamping, that you can say
var on those tags.
   
UIComponent
 |
 + - UIXComponent
   |
   + - UIXComponentBase
|
+ UIXCollection
   
Collection has some subclasses like
   
UIXHierarchy
   |
   + UIXTree
   
and
   
UIXIterator
   |
   + UIXTable
   
   
   
The Trinidad Tree uses a TreeModel which extends CollectionModel
(Trin) which extends DataModel (Faces). CollectionModel is also used
by the Trin Table.
   
But, I am not really sure, why the table should be EditableValueHolder
 ?
   
Thanks!
-Matthias
   
On 10/5/06, Martin Marinschek  [EMAIL PROTECTED] wrote:
 Hi *,

 yes, I'd also like to do an Ajaxified version, but that's not the
 first thing I'm looking at.

 I believe that extending from UIData is not really what we should do
 -
 UIData is totally row-based, and a row-index doesn't make so much
 sense for a dynamic tree.

 What are the tree and the table of trinidad sharing with the
 UIXCollection interface?

 regards,

 Martin

 On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi M-
 
  On 10/4/06, Martin Marinschek  [EMAIL PROTECTED]
 wrote:
   Hi *,
  
   I'm reviewing the tree2 currently, and I was wondering if we
 could
   have a discussion about some of the concepts.
  
   First thing I'd like to discuss is what happens with selected
 nodes.
   Currently, selecting a node fires an action-listener. This is
 somewhat
   ok, but I believe the selection-model of a tree should rather be
 a
   list of values, stored at a useful place. Therefore, the tree
 should
   implement the EditableValueHolder-interface, then we could do a
 lot
   more with the values of the tree as well.
 
  I am not really sure about the EditableValueHolder. In Trinidad
 the
  Tree (UIXTree) is type of UIXCollection, which is also used by
  UIXTable.
 
  I remember some discussions from Sean in the past that they Tree2
  should extend UIData instead of UIComponent(Base)
 
 
   The change would necessitate to move the current value
 attribute to
   some other name - I suppose the name model would be more
 appropriate
 
  nothing wrong w/ using model instead of value, since value makes
 sense on
  (editable)valueHolders to me

Re: Tree2


No, it's a pity that not, but I can't. I'm at a client here in Germany
until end of November, can't take off a week.

regards,

Martin

On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote:

Martin: I haven't had time to read this thread yet but I will shortly.
 Are you going to be at Apache Con this year?  If so we can discuss
some of your ideas in person as well.

Sean

On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Well, it wouldn't be a problem to have an extended version of the tree
 which implements EditableValueHolder, but not if the model of the tree
 is configured by setting the value-attribute - then extending won't
 work.

 regards,

 Martin

 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  hi Arash,
 
  sure your feedback is welcome :)
 
  like said before, a generic raw version + aditional tree stuff.
  During that task we should also take a look at tree / treeTable, IMHO.
 
  -M
 
  On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
  
  
   Hello Mattias,
  
   I am so new to this list and may be I am not allowed to say this, but I
   think most developers I have seen use menu related components for only
   displaying structured data, and most of times data is displayed to user 
for
   one of the following purposes:
  
   1) selecting one item
2) selecting multiple item
3) displaying and editing tree structured data (like organization chart,
   directory services, etc)
  
the first 2 options are currently supported features of tree2, the 3'rd 
is
   under debate.
  
   May be if we can use same parent for both menu and tree navigation related
   components and simple tree data structure as said by matias and zubin, for
   parent of all these components can have following benefits:
  
1) simplifying development
2) simplifying learning for users
3) making it easier to add more advanced trees later on demand
  
   Best regards
  
   Arash
  
  
  
   On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think a tree should display structured data and not be an input
   component.
What should the input be? So you are willing register also validators
on the tree?
   
maybe that is more specialized use case instead a generic tree use
case you are looking at.
   
On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi Matthias,

 for the reason that every component that has changing values needs to
 be an editable value holder. Imagine the case of a tree embedded in a
 data-table - a data-table, at least the ones of both MyFaces and the
 RI (I know, Trinidad's data-table does something different) only save
 whatever is part of the EditableValueHolder interface.

 So the selection model of a tree won't be saved in a dataTable, except
 it is part of the EditableValueHolder interface.

 regards,

 Martin

 On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  I think a tree is much more about sturctured data instead of 
input
   data
 
 
  The UIXCollection is a base clazz for the stamping, that you can 
say
  var on those tags.
 
  UIComponent
   |
   + - UIXComponent
 |
 + - UIXComponentBase
  |
  + UIXCollection
 
  Collection has some subclasses like
 
  UIXHierarchy
 |
 + UIXTree
 
  and
 
  UIXIterator
 |
 + UIXTable
 
 
 
  The Trinidad Tree uses a TreeModel which extends CollectionModel
  (Trin) which extends DataModel (Faces). CollectionModel is also used
  by the Trin Table.
 
  But, I am not really sure, why the table should be 
EditableValueHolder
   ?
 
  Thanks!
  -Matthias
 
  On 10/5/06, Martin Marinschek  [EMAIL PROTECTED] wrote:
   Hi *,
  
   yes, I'd also like to do an Ajaxified version, but that's not the
   first thing I'm looking at.
  
   I believe that extending from UIData is not really what we should 
do
   -
   UIData is totally row-based, and a row-index doesn't make so much
   sense for a dynamic tree.
  
   What are the tree and the table of trinidad sharing with the
   UIXCollection interface?
  
   regards,
  
   Martin
  
   On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi M-
   
On 10/4/06, Martin Marinschek  [EMAIL PROTECTED]
   wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if we
   could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with selected
   nodes.
 Currently, selecting a node fires an action-listener. This is
   somewhat
 ok, but I believe the selection-model of a tree should rather 
be
   a
 list of values, stored at a useful place. Therefore, the tree
   should

Tree2

2006-10-04 Thread Martin Marinschek


Hi *,

I'm reviewing the tree2 currently, and I was wondering if we could
have a discussion about some of the concepts.

First thing I'd like to discuss is what happens with selected nodes.
Currently, selecting a node fires an action-listener. This is somewhat
ok, but I believe the selection-model of a tree should rather be a
list of values, stored at a useful place. Therefore, the tree should
implement the EditableValueHolder-interface, then we could do a lot
more with the values of the tree as well.

The change would necessitate to move the current value attribute to
some other name - I suppose the name model would be more appropriate
anyways (I've never understood why a dataTable has a
value-attribute, by the way, the semantics for the value-attribute
are generally quite different).

Additionally, the tree is doing a lot with respect to the markup of
the component. I'm not sure if this is useful as very large HTML-bases
result from this. I suspect it would be better to only transfer the
data-model to the client (and maybe templates for each node-type), and
then render the nodes on the client dynamically.

Thoughts?

regards,

Martin

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Tree2

2006-10-04 Thread Arash Rajaeeyan

Dear Martin I think for most people its easier to use list of values as selection model of the tree.would you please also consider adding an Ajax capability to Tree2 ?(beside server mode and client mode)
regardsOn 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,I'm reviewing the tree2 currently, and I was wondering if we couldhave a discussion about some of the concepts.First thing I'd like to discuss is what happens with selected nodes.Currently, selecting a node fires an action-listener. This is somewhat
ok, but I believe the selection-model of a tree should rather be alist of values, stored at a useful place. Therefore, the tree shouldimplement the EditableValueHolder-interface, then we could do a lotmore with the values of the tree as well.
The change would necessitate to move the current value attribute tosome other name - I suppose the name model would be more appropriateanyways (I've never understood why a dataTable has a
value-attribute, by the way, the semantics for the value-attributeare generally quite different).Additionally, the tree is doing a lot with respect to the markup ofthe component. I'm not sure if this is useful as very large HTML-bases
result from this. I suspect it would be better to only transfer thedata-model to the client (and maybe templates for each node-type), andthen render the nodes on the client dynamically.Thoughts?
regards,Martin--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
-- Arash Rajaeeyan

Re: Tree2

2006-10-04 Thread Matthias Wessendorf


would you please also consider adding an Ajax capability to Tree2 ?
(beside server mode and client mode)


there is a cool post from Rick Hightower how to use dojo and tree2 (or
was it tree)

-Matthias



regards


On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hi *,

 I'm reviewing the tree2 currently, and I was wondering if we could
 have a discussion about some of the concepts.

 First thing I'd like to discuss is what happens with selected nodes.
 Currently, selecting a node fires an action-listener. This is somewhat
 ok, but I believe the selection-model of a tree should rather be a
 list of values, stored at a useful place. Therefore, the tree should
 implement the EditableValueHolder-interface, then we could do a lot
 more with the values of the tree as well.

 The change would necessitate to move the current value attribute to
 some other name - I suppose the name model would be more appropriate
 anyways (I've never understood why a dataTable has a
 value-attribute, by the way, the semantics for the value-attribute
 are generally quite different).

 Additionally, the tree is doing a lot with respect to the markup of
 the component. I'm not sure if this is useful as very large HTML-bases
 result from this. I suspect it would be better to only transfer the
 data-model to the client (and maybe templates for each node-type), and
 then render the nodes on the client dynamically.

 Thoughts?

 regards,

 Martin

 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




--
Arash Rajaeeyan



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Tree2

2006-10-04 Thread Matthias Wessendorf


Hi M-

On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Hi *,

I'm reviewing the tree2 currently, and I was wondering if we could
have a discussion about some of the concepts.

First thing I'd like to discuss is what happens with selected nodes.
Currently, selecting a node fires an action-listener. This is somewhat
ok, but I believe the selection-model of a tree should rather be a
list of values, stored at a useful place. Therefore, the tree should
implement the EditableValueHolder-interface, then we could do a lot
more with the values of the tree as well.


I am not really sure about the EditableValueHolder. In Trinidad the
Tree (UIXTree) is type of UIXCollection, which is also used by
UIXTable.

I remember some discussions from Sean in the past that they Tree2
should extend UIData instead of UIComponent(Base)



The change would necessitate to move the current value attribute to
some other name - I suppose the name model would be more appropriate


nothing wrong w/ using model instead of value, since value makes sense on
(editable)valueHolders to me...
(like UIOutput, UIInput, UISelect*,...)


anyways (I've never understood why a dataTable has a
value-attribute, by the way, the semantics for the value-attribute
are generally quite different).


I guess they just simply introduced that since there was a value of
(edit.)value:_holders




Additionally, the tree is doing a lot with respect to the markup of
the component. I'm not sure if this is useful as very large HTML-bases
result from this. I suspect it would be better to only transfer the
data-model to the client (and maybe templates for each node-type), and
then render the nodes on the client dynamically.


you mean sending xml to the client and using a JS_engine to render
on the client side?

-Matthias


Thoughts?

regards,

Martin

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

[jira] Commented: (TOMAHAWK-437) Tree2 uses cookies when preserveToggle==false

2006-09-29 Thread Martin Schlierf (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-437?page=comments#action_12438666 
] 

Martin Schlierf commented on TOMAHAWK-437:
--

Can you add a cookiePrefix parameter?
That would help me with my issue which has the same root.

My problem is:
I use the tree to show the content of a folder which can be selected by a 
combobox.

The user selects a folder.
The Tree shows the content.
The user opens some subfolders.
The user selects another folder in the combobox.
The tree is reinitialised and shows the content of the new folder but tries to 
expand the same subfolders as the folder before, because it´s saved in the 
cookie.



 Tree2 uses cookies when preserveToggle==false
 -

 Key: TOMAHAWK-437
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-437
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.2
 Environment: actually the release version is 1.1.3
Reporter: Chris Hane
 Assigned To: sean schofield
Priority: Minor
 Fix For: 1.1.4-SNAPSHOT


 This should probably be two issues, but I will let you decide that.
 1. Can not have same screen open in two windows.  Cookies from one screen 
 affect the toggle status of the tree in the secon window.
 2. preserveToggle==false still sets a cookie...
 Here is the original email to the list 
 http://marc.theaimsgroup.com/?l=myfaces-devm=114727809302352w=2:
 paste
 I have been playing around with the tree2 control trying to make it do what I 
 want.  Nice control
 Question, I have been having issues with the following setup:
  - clientSideToggle = true
  - preserveToggle = false
 When I have two windows open on the same view, the tree2 state is shared 
 between both.  This means that someone can not view two different records and 
 have different tree expand/collapse states.  Or more specifically, when I 
 execute an action (commandLink) on the tree and return the same view (i.e., 
 add/delete a TreeNode), the state of expanded/collpased nodes is read from 
 the cookie.
 I think I traced it down to the HtmlTreeRenderer.decode method.
 At line 123 is:
 if(tree.isClientSideToggle())
 {
restoreStateFromCookies(context, component);
 }
 Shouldn't the if statement also look at the tree.isPreserveToggle()? Not an 
 expert in JSF by any stretch of the imagination, so if I'm on the wrong track 
 or this doesn't make sense just let me know
 Chris 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-718) duplicated menu item for Tree2

2006-09-28 Thread Luis Parravicini (JIRA)

duplicated menu item for Tree2
--

 Key: TOMAHAWK-718
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-718
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Luis Parravicini
Priority: Minor


There are two menu items in http://myfaces.apache.org/tomahawk/index.html for 
the Tree2 component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (TOMAHAWK-534) tree2 expan/collapse broken when nested in a dataTable

2006-09-27 Thread Grant Smith (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-534?page=all ]

Grant Smith reopened TOMAHAWK-534:
--

 

 tree2 expan/collapse broken when nested in a dataTable
 --

 Key: TOMAHAWK-534
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-534
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.3
 Environment: JBoss4.0.4.GA
Reporter: Michal Borowiecki
 Assigned To: Grant Smith
 Attachments: HtmlTreeRenderer.patch, TreeToggle.PNG, TreeToggleDOM.PNG


 When a tree2 component is nested inside a dataTable the expand/collapse 
 button doesn't work properly.
 Only the buttons in the tree in the first table row work correctly.
 Clicking the button to expand the root node in a tree in any row of the table 
 always causes the root node in the first row to expand.
 This is caused by duplicate ids of the SPAN elements. 
 The ids are rendered by HtmlTreeRenderer which incorrectly uses the tree's 
 (simple) id instead of the (full) client id.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (TOMAHAWK-534) tree2 expan/collapse broken when nested in a dataTable

2006-09-27 Thread Grant Smith (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-534?page=all ]

Grant Smith resolved TOMAHAWK-534.
--

Resolution: Fixed

 tree2 expan/collapse broken when nested in a dataTable
 --

 Key: TOMAHAWK-534
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-534
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.3
 Environment: JBoss4.0.4.GA
Reporter: Michal Borowiecki
 Assigned To: Grant Smith
 Attachments: HtmlTreeRenderer.patch, TreeToggle.PNG, TreeToggleDOM.PNG


 When a tree2 component is nested inside a dataTable the expand/collapse 
 button doesn't work properly.
 Only the buttons in the tree in the first table row work correctly.
 Clicking the button to expand the root node in a tree in any row of the table 
 always causes the root node in the first row to expand.
 This is caused by duplicate ids of the SPAN elements. 
 The ids are rendered by HtmlTreeRenderer which incorrectly uses the tree's 
 (simple) id instead of the (full) client id.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-671) Tree2 fails with NumberFormat Exception or Null Pointer Exception when ExpandAll button is placed in the same form as Tree2 using RI

2006-09-15 Thread Stan Laufik (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-671?page=all ]

Stan Laufik updated TOMAHAWK-671:
-

Status: Patch Available  (was: Open)

 Tree2 fails with NumberFormat Exception or Null Pointer Exception when 
 ExpandAll button is placed in the same form as Tree2 using RI
 

 Key: TOMAHAWK-671
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-671
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: WindowsXP, SUN JSF RI 1.1.02, Tomahawk 1.1.5
Reporter: Stan Laufik
 Attachments: UITreeData.patch


 When a button that executes HtmlTree.expandAll is put into the same h:form 
 then the Tree2 component after clicking on the button Tree2 throws 
 NumberFormat or NullPointer exception (depending on which build of Tomahawk 
 is used).
 On our system I have fixed it with teh following code:
 package org.apache.myfaces.custom.tree2
 class UITreeData
 public void broadcast(FacesEvent event) throws AbortProcessingException
 {
 if (event instanceof FacesEventWrapper)
 {
 FacesEventWrapper childEvent = (FacesEventWrapper) event;
 String currNodeId = getNodeId();
 setNodeId(childEvent.getNodeId());
 FacesEvent nodeEvent = childEvent.getFacesEvent();
 nodeEvent.getComponent().broadcast(nodeEvent);
 setNodeId(currNodeId);
 return;
 }
 else if(event instanceof ToggleExpandedEvent)
 {
 ToggleExpandedEvent toggleEvent = (ToggleExpandedEvent) event;
 
 if (toggleEvent.getNodeId() != null   
 !null.equals(toggleEvent.getNodeId())) {
   String currentNodeId = getNodeId();
   setNodeId(toggleEvent.getNodeId());
   toggleExpanded();
   setNodeId(currentNodeId);
 }
 
 }
 else
 {
 super.broadcast(event);
 return;
 }
 }
 The chanegd code first check if the node to be toggledis valid before it 
 performs the toggle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-671) Tree2 fails with NumberFormat Exception or Null Pointer Exception when ExpandAll button is placed in the same form as Tree2 using RI

2006-09-15 Thread Stan Laufik (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-671?page=all ]

Stan Laufik updated TOMAHAWK-671:
-

Status: Open  (was: Patch Available)

 Tree2 fails with NumberFormat Exception or Null Pointer Exception when 
 ExpandAll button is placed in the same form as Tree2 using RI
 

 Key: TOMAHAWK-671
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-671
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: WindowsXP, SUN JSF RI 1.1.02, Tomahawk 1.1.5
Reporter: Stan Laufik
 Attachments: UITreeData.patch


 When a button that executes HtmlTree.expandAll is put into the same h:form 
 then the Tree2 component after clicking on the button Tree2 throws 
 NumberFormat or NullPointer exception (depending on which build of Tomahawk 
 is used).
 On our system I have fixed it with teh following code:
 package org.apache.myfaces.custom.tree2
 class UITreeData
 public void broadcast(FacesEvent event) throws AbortProcessingException
 {
 if (event instanceof FacesEventWrapper)
 {
 FacesEventWrapper childEvent = (FacesEventWrapper) event;
 String currNodeId = getNodeId();
 setNodeId(childEvent.getNodeId());
 FacesEvent nodeEvent = childEvent.getFacesEvent();
 nodeEvent.getComponent().broadcast(nodeEvent);
 setNodeId(currNodeId);
 return;
 }
 else if(event instanceof ToggleExpandedEvent)
 {
 ToggleExpandedEvent toggleEvent = (ToggleExpandedEvent) event;
 
 if (toggleEvent.getNodeId() != null   
 !null.equals(toggleEvent.getNodeId())) {
   String currentNodeId = getNodeId();
   setNodeId(toggleEvent.getNodeId());
   toggleExpanded();
   setNodeId(currentNodeId);
 }
 
 }
 else
 {
 super.broadcast(event);
 return;
 }
 }
 The chanegd code first check if the node to be toggledis valid before it 
 performs the toggle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-667) Tree2 always collapse all on refresh

2006-09-14 Thread eric (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-667?page=comments#action_12434666 
] 

eric commented on TOMAHAWK-667:
---

I think it comes from faces-config.xml

I use tiles, so in order to upgrade Mafaces 1.1.1 to 1.1.3 I changed 

org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl
to
org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl

Since, the Tree don't keep state's nodes.

 Tree2 always collapse all on refresh
 

 Key: TOMAHAWK-667
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-667
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Jboss
Reporter: eric

 I have this code in my jsp : 
 h:form
 t:tree2 value=#{arbre.tree} clientSideToggle=false showRootNode=true 
 var=node varNodeToggler=t binding=#{arbre.treeBinding} 
  javascriptLocation=/ressources/js/arbre 
 imageLocation=/ressources/js/arbre/images
   f:facet name=Racine
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1racine/
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2racine/
 t:outputText value=#{node.description} styleClass=nodeFolder 
 forceId=true id=textracine/
   /h:panelGroup
   /f:facet
   f:facet name=Dossier
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1dossier/
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2dossier/
   t:outputText value=#{node.description} 
 styleClass=nodeFolder forceId=true id=textdossier/
   t:outputText value= (#{node.childCount}) 
 styleClass=childCount rendered=#{!empty node.children} forceId=true 
 id=textdossier2/
   /h:panelGroup
   /f:facet
   
   f:facet name=DossierGrpCriteres
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/blue-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1dossiergrp/
   t:graphicImage 
 value=/ressources/images/treenode/blue-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2dossiergrp/
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectGrpCritere} id=lienDossierGrpcCritere
   h:outputText value=#{node.description} 
 id=textDossierGrpCritere/
   f:param name=id value=#{node.identifier} 
 id=paramDossierGrpCritere/  
 /h:commandLink
   /h:panelGroup
   /f:facet
   
   f:facet name=TypeObjet
   h:panelGroup
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectTypeObjet} id=lienTypeObjet
   t:graphicImage 
 value=/ressources/images/treenode/document.png border=0 
 id=imageTypeObjet/
   h:outputText value=#{node.description} 
 id=textTypeObjet/
   f:param name=id value=#{node.identifier} 
 id=paramGrpCritere/ 
 /h:commandLink
   /h:panelGroup
   /f:facet
   
   f:facet name=GrpCritere
   h:panelGroup
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectGrpCritere} id=lienGrpcCritere
   t:graphicImage 
 value=/ressources/images/treenode/document.png border=0 
 id=imageGrpCritere/
   h:outputText value=#{node.description} 
 id=textGrpCritere/
   f:param name=id value=#{node.identifier} 
 id=paramGrpCritere/ 
 /h:commandLink
   /h:panelGroup
   /f:facet
 /t:tree2
 /h:form
 When I click on a link, all my nodes are rendered collapse. I tried to call 
 the method expandAll in the action of the link, but it didn't work.
 What can I do to fix this bug?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-671) Tree2 fails with NumberFormat Exception or Null Pointer Exception when ExpandAll button is placed in the same form as Tree2 using RI

2006-09-14 Thread Mike Kienenberger (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-671?page=comments#action_12434799 
] 

Mike Kienenberger commented on TOMAHAWK-671:


Thanks for working on this issue.

Can you create a unified diff of your changes, attach the file to this issue, 
and click on the grant-rights-to-ASF radio button?

Thanks!


 Tree2 fails with NumberFormat Exception or Null Pointer Exception when 
 ExpandAll button is placed in the same form as Tree2 using RI
 

 Key: TOMAHAWK-671
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-671
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: WindowsXP, SUN JSF RI 1.1.02, Tomahawk 1.1.5
Reporter: Stan Laufik

 When a button that executes HtmlTree.expandAll is put into the same h:form 
 then the Tree2 component after clicking on the button Tree2 throws 
 NumberFormat or NullPointer exception (depending on which build of Tomahawk 
 is used).
 On our system I have fixed it with teh following code:
 package org.apache.myfaces.custom.tree2
 class UITreeData
 public void broadcast(FacesEvent event) throws AbortProcessingException
 {
 if (event instanceof FacesEventWrapper)
 {
 FacesEventWrapper childEvent = (FacesEventWrapper) event;
 String currNodeId = getNodeId();
 setNodeId(childEvent.getNodeId());
 FacesEvent nodeEvent = childEvent.getFacesEvent();
 nodeEvent.getComponent().broadcast(nodeEvent);
 setNodeId(currNodeId);
 return;
 }
 else if(event instanceof ToggleExpandedEvent)
 {
 ToggleExpandedEvent toggleEvent = (ToggleExpandedEvent) event;
 
 if (toggleEvent.getNodeId() != null   
 !null.equals(toggleEvent.getNodeId())) {
   String currentNodeId = getNodeId();
   setNodeId(toggleEvent.getNodeId());
   toggleExpanded();
   setNodeId(currentNodeId);
 }
 
 }
 else
 {
 super.broadcast(event);
 return;
 }
 }
 The chanegd code first check if the node to be toggledis valid before it 
 performs the toggle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-667) Tree2 always collapse all on refresh

2006-09-13 Thread eric (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-667?page=comments#action_12434421 
] 

eric commented on TOMAHAWK-667:
---

This isn't a problem of library, in my point of view, it's a problem of 
configuration.
Maybe the web.xml file, i don't know

 Tree2 always collapse all on refresh
 

 Key: TOMAHAWK-667
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-667
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Jboss
Reporter: eric

 I have this code in my jsp : 
 h:form
 t:tree2 value=#{arbre.tree} clientSideToggle=false showRootNode=true 
 var=node varNodeToggler=t binding=#{arbre.treeBinding} 
  javascriptLocation=/ressources/js/arbre 
 imageLocation=/ressources/js/arbre/images
   f:facet name=Racine
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1racine/
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2racine/
 t:outputText value=#{node.description} styleClass=nodeFolder 
 forceId=true id=textracine/
   /h:panelGroup
   /f:facet
   f:facet name=Dossier
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1dossier/
   t:graphicImage 
 value=/ressources/images/treenode/yellow-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2dossier/
   t:outputText value=#{node.description} 
 styleClass=nodeFolder forceId=true id=textdossier/
   t:outputText value= (#{node.childCount}) 
 styleClass=childCount rendered=#{!empty node.children} forceId=true 
 id=textdossier2/
   /h:panelGroup
   /f:facet
   
   f:facet name=DossierGrpCriteres
   h:panelGroup
   t:graphicImage 
 value=/ressources/images/treenode/blue-folder-open.png 
 rendered=#{t.nodeExpanded} border=0 id=image1dossiergrp/
   t:graphicImage 
 value=/ressources/images/treenode/blue-folder-closed.png 
 rendered=#{!t.nodeExpanded} border=0 id=image2dossiergrp/
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectGrpCritere} id=lienDossierGrpcCritere
   h:outputText value=#{node.description} 
 id=textDossierGrpCritere/
   f:param name=id value=#{node.identifier} 
 id=paramDossierGrpCritere/  
 /h:commandLink
   /h:panelGroup
   /f:facet
   
   f:facet name=TypeObjet
   h:panelGroup
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectTypeObjet} id=lienTypeObjet
   t:graphicImage 
 value=/ressources/images/treenode/document.png border=0 
 id=imageTypeObjet/
   h:outputText value=#{node.description} 
 id=textTypeObjet/
   f:param name=id value=#{node.identifier} 
 id=paramGrpCritere/ 
 /h:commandLink
   /h:panelGroup
   /f:facet
   
   f:facet name=GrpCritere
   h:panelGroup
   h:commandLink immediate=true 
 styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
 action=#{arbre.selectGrpCritere} id=lienGrpcCritere
   t:graphicImage 
 value=/ressources/images/treenode/document.png border=0 
 id=imageGrpCritere/
   h:outputText value=#{node.description} 
 id=textGrpCritere/
   f:param name=id value=#{node.identifier} 
 id=paramGrpCritere/ 
 /h:commandLink
   /h:panelGroup
   /f:facet
 /t:tree2
 /h:form
 When I click on a link, all my nodes are rendered collapse. I tried to call 
 the method expandAll in the action of the link, but it didn't work.
 What can I do to fix this bug?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-671) Tree2 fails with NumberFormat Exception or Null Pointer Exception when ExpandAll button is placed in the same form as Tree2 using RI

2006-09-13 Thread Stan Laufik (JIRA)

Tree2 fails with NumberFormat Exception or Null Pointer Exception when 
ExpandAll button is placed in the same form as Tree2 using RI


 Key: TOMAHAWK-671
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-671
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: WindowsXP, SUN JSF RI 1.1.02, Tomahawk 1.1.5
Reporter: Stan Laufik


When a button that executes HtmlTree.expandAll is put into the same h:form 
then the Tree2 component after clicking on the button Tree2 throws NumberFormat 
or NullPointer exception (depending on which build of Tomahawk is used).

On our system I have fixed it with teh following code:


package org.apache.myfaces.custom.tree2
class UITreeData

public void broadcast(FacesEvent event) throws AbortProcessingException
{
if (event instanceof FacesEventWrapper)
{
FacesEventWrapper childEvent = (FacesEventWrapper) event;
String currNodeId = getNodeId();
setNodeId(childEvent.getNodeId());
FacesEvent nodeEvent = childEvent.getFacesEvent();
nodeEvent.getComponent().broadcast(nodeEvent);
setNodeId(currNodeId);
return;
}
else if(event instanceof ToggleExpandedEvent)
{
ToggleExpandedEvent toggleEvent = (ToggleExpandedEvent) event;

if (toggleEvent.getNodeId() != null   
!null.equals(toggleEvent.getNodeId())) {
String currentNodeId = getNodeId();
setNodeId(toggleEvent.getNodeId());
toggleExpanded();
setNodeId(currentNodeId);
}

}
else
{
super.broadcast(event);
return;
}
}

The chanegd code first check if the node to be toggledis valid before it 
performs the toggle.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-667) Tree2 always collapse all on refresh

2006-09-11 Thread eric (JIRA)

Tree2 always collapse all on refresh


 Key: TOMAHAWK-667
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-667
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree2
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Jboss
Reporter: eric


I have this code in my jsp : 

h:form
t:tree2 value=#{arbre.tree} clientSideToggle=false showRootNode=true 
var=node varNodeToggler=t binding=#{arbre.treeBinding} 
 javascriptLocation=/ressources/js/arbre 
imageLocation=/ressources/js/arbre/images

f:facet name=Racine
h:panelGroup
t:graphicImage 
value=/ressources/images/treenode/yellow-folder-open.png 
rendered=#{t.nodeExpanded} border=0 id=image1racine/
t:graphicImage 
value=/ressources/images/treenode/yellow-folder-closed.png 
rendered=#{!t.nodeExpanded} border=0 id=image2racine/
t:outputText value=#{node.description} styleClass=nodeFolder 
forceId=true id=textracine/
/h:panelGroup
/f:facet

f:facet name=Dossier
h:panelGroup
t:graphicImage 
value=/ressources/images/treenode/yellow-folder-open.png 
rendered=#{t.nodeExpanded} border=0 id=image1dossier/
t:graphicImage 
value=/ressources/images/treenode/yellow-folder-closed.png 
rendered=#{!t.nodeExpanded} border=0 id=image2dossier/
t:outputText value=#{node.description} 
styleClass=nodeFolder forceId=true id=textdossier/
t:outputText value= (#{node.childCount}) 
styleClass=childCount rendered=#{!empty node.children} forceId=true 
id=textdossier2/
/h:panelGroup
/f:facet

f:facet name=DossierGrpCriteres
h:panelGroup
t:graphicImage 
value=/ressources/images/treenode/blue-folder-open.png 
rendered=#{t.nodeExpanded} border=0 id=image1dossiergrp/
t:graphicImage 
value=/ressources/images/treenode/blue-folder-closed.png 
rendered=#{!t.nodeExpanded} border=0 id=image2dossiergrp/
h:commandLink immediate=true 
styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
action=#{arbre.selectGrpCritere} id=lienDossierGrpcCritere
h:outputText value=#{node.description} 
id=textDossierGrpCritere/
f:param name=id value=#{node.identifier} 
id=paramDossierGrpCritere/  
/h:commandLink

/h:panelGroup
/f:facet


f:facet name=TypeObjet
h:panelGroup
h:commandLink immediate=true 
styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
action=#{arbre.selectTypeObjet} id=lienTypeObjet
t:graphicImage 
value=/ressources/images/treenode/document.png border=0 
id=imageTypeObjet/
h:outputText value=#{node.description} 
id=textTypeObjet/
f:param name=id value=#{node.identifier} 
id=paramGrpCritere/ 
/h:commandLink
/h:panelGroup
/f:facet

f:facet name=GrpCritere
h:panelGroup
h:commandLink immediate=true 
styleClass=#{t.nodeSelected ? 'documentSelected':'document'} 
action=#{arbre.selectGrpCritere} id=lienGrpcCritere
t:graphicImage 
value=/ressources/images/treenode/document.png border=0 
id=imageGrpCritere/
h:outputText value=#{node.description} 
id=textGrpCritere/
f:param name=id value=#{node.identifier} 
id=paramGrpCritere/ 
/h:commandLink
/h:panelGroup
/f:facet
/t:tree2
/h:form

When I click on a link, all my nodes are rendered collapse. I tried to call the 
method expandAll in the action of the link, but it didn't work.
What can I do to fix this bug?



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1379) CLONE -commandLink actions ignored inside tree2

2006-08-18 Thread John Deverall









Hi, 



In response to your post at http://www.mail-archive.com/dev@myfaces.apache.org/msg16259.html



Have you tried using immediate=true in your
command link?



I dont have any scientific basis for explaining
this.. all I know is that immediate=true skips the validation
phase?  which I cant relate to the functioning of tree2. 



However using immediate=true caused my events
to start working in this code here. 



If I do not use immediate=true, events do not
fire. 



An explanation for this would be welcome also!



t:tree2 id=userTeamTree value=#{treeMenu.treeModel} var=node showRootNode=false 

 !-- render
nodes of type root --

 f:facet name=root

  h:panelGroup

  h:outputText value=All Teams and Users/

 /h:panelGroup

 /f:facet

 

%-- render nodes of
type team --%

 f:facet name=team 

 h:panelGroup

  t:graphicImage value=../images/teams.png/

 h:commandLink immediate=true value=#{node.description} action=#{treeMenu.teamsInterface}

 f:param name=team_id value=#{node.identifier}/

   /h:commandLink 

 /h:panelGroup 

 /f:facet

 


 !-- chosen
to render nodes of type user --

 f:facet name=user

 h:panelGroup

 h:commandLink immediate=true action=#{treeMenu.usersInterface}


  h:outputText value=#{node.description}/


 f:param name=user_id value=#{node.identifier}/

  /h:commandLink


/h:panelGroup

 /f:facet

/t:tree2
















--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.2/422 - Release Date: 17/08/2006

tree2 component retains its state after sessin invaldation

2006-08-11 Thread Saama


I am using tree2 component as navigator in my application. The code is as
follows:

t:tree2 id=navMenu

value=#{NavigationTreeHandler.expandedTreeData}

binding=#{NavigationTreeHandler.tree}
var=node
varNodeToggler=t
showLines=false 
showNav=false
showRootNode=false 
preserveToggle=false

clientSideToggle=false

The tree works absolutely fine , but it persists its state even after the
session has ended. When a new user logs in , instead of initially showing
all the nodes collapsed the tree appears in the same state as the previous
user had left it. How can I solve this. Need your help urgently

-- 
View this message in context: 
http://www.nabble.com/tree2-component-retains-its-state-after-sessin-invaldation-tf2090367.html#a5761362
Sent from the My Faces - Dev forum at Nabble.com.

[jira] Created: (MYFACES-1379) CLONE -commandLink actions ignored inside tree2

2006-08-07 Thread Pavel Rezny (JIRA)

CLONE -commandLink actions ignored inside tree2
---

 Key: MYFACES-1379
 URL: http://issues.apache.org/jira/browse/MYFACES-1379
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.0.9m9
 Environment: tested on tomcat 5.0.30, windows2000 and redhat linux 9.
Reporter: Pavel Rezny
 Assigned To: sean schofield


When a commandLink inside a tree2 has an action attr, actionListener attr, or 
f:actionListener tag they are never queued or broadcast and the associated 
methods never get called.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1379) CLONE -commandLink actions ignored inside tree2

2006-08-07 Thread Pavel Rezny (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1379?page=comments#action_12426150 
] 

Pavel Rezny commented on MYFACES-1379:
--

I have the same problem with ignored Action listener of 
CommandButton/Commandlink.
Java 1.5 update 7, Tomcat 5.5.17, JSF RI 1.1.02, Tomahawk Snapshot 1.1.4/1.1.5.
The Listener is called if the definition is included in the JSP file. But 
creating the facet programmatically cause Listener to be ignored.
(Actually I want to add whole tree programmatically to a page.)
(I tried adding listener by method setActionListener and addActionListener - 
the same behaviour = listener ignored.)
(Appearance of root node cause no change of the behavour.)

HtmlTree tree = (HtmlTree) app.createComponent(HtmlTree.COMPONENT_TYPE);
Map treeFacets = tree.getFacets();
treeFacets.clear();
HtmlCommandButton ot2 = (HtmlCommandButton) 
app.createComponent(HtmlCommandButton.COMPONENT_TYPE);
ot2.setValue(Author);
ot2.addActionListener(new ActionListener()
 {
  public void processAction(ActionEvent e)
   { 
  throw new RuntimeException(YES);
   }
 });
treeFacets.put(clickable, ot2); // COMMENTING THIS LINE CAUSE USE OF FACET 
DEFINED IN JSP FILE AND ALL WORKS FINE

Working definition in JSP file:
h:form id=my_tree
t:tree2 binding=#{DynamicTree['cidListTree']} 
value=#{TreeModelHolder.treeModel} id=my_tree_tree
   f:facet name=clickable
  h:commandLink actionListener=#{EventTrigger.onTreeNodeClick} 
value=#{node.description}/
   /f:facet
/t:tree
/h:form


 CLONE -commandLink actions ignored inside tree2
 ---

 Key: MYFACES-1379
 URL: http://issues.apache.org/jira/browse/MYFACES-1379
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.0.9m9
 Environment: tested on tomcat 5.0.30, windows2000 and redhat linux 9.
Reporter: Pavel Rezny
 Assigned To: sean schofield

 When a commandLink inside a tree2 has an action attr, actionListener attr, or 
 f:actionListener tag they are never queued or broadcast and the associated 
 methods never get called.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Mike Kienenberger


I'm taking a look at tree2 for the first time.

One thing I've noticed right off is the documentation, or lack thereof  :)

Most of the documentation is in the wiki, except for the tld.

However, three attributes aren't documented at all: value, var, and
varNodeToggler.

I'm guessing var and value work like any UIData component (and it
should be simple to copy those into the tlddocs from dataTable).

However, varNodeToggler doesn't have any non-code documentation that I
could find.   I'm guessing it's an object that implements some kind of
isExpanded/isCollapsed functionality and acts accordingly when a
node's visibility state changes.

Also, the http://www.irian.at/myfaces/tree2NoNav.jsf example seems
kinda lame (only one node visible).

Re: tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Mike Kienenberger


I'm throwing all the documentation issues I encounter into this thread
for now.  Hopefully, I'll have time to update the docs at a later
point.

No documentation on what the allowable facets are.  No documentation
stating that expand and collapse facets need to be UIGraphic
components.  [Guess I shouldn't have tried replacing these with
h:outputTexts]

On 8/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

I'm taking a look at tree2 for the first time.

One thing I've noticed right off is the documentation, or lack thereof  :)

Most of the documentation is in the wiki, except for the tld.

However, three attributes aren't documented at all: value, var, and
varNodeToggler.

I'm guessing var and value work like any UIData component (and it
should be simple to copy those into the tlddocs from dataTable).

However, varNodeToggler doesn't have any non-code documentation that I
could find.   I'm guessing it's an object that implements some kind of
isExpanded/isCollapsed functionality and acts accordingly when a
node's visibility state changes.

Also, the http://www.irian.at/myfaces/tree2NoNav.jsf example seems
kinda lame (only one node visible).

Re: tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Wendy Smoak


On 8/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

I'm throwing all the documentation issues I encounter into this thread
for now.  Hopefully, I'll have time to update the docs at a later
point.


Thanks, and so we don't lose track of your comments:

  http://issues.apache.org/jira/browse/TOMAHAWK-584

--
Wendy

Re: tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Sean Schofield


I'm guessing var and value work like any UIData component (and it
should be simple to copy those into the tlddocs from dataTable).


You guessed correctly.


However, varNodeToggler doesn't have any non-code documentation that I
could find.   I'm guessing it's an object that implements some kind of
isExpanded/isCollapsed functionality and acts accordingly when a
node's visibility state changes.


Yes.  I will try to elaborate on that shortly (facing a deadline atm.)


Also, the http://www.irian.at/myfaces/tree2NoNav.jsf example seems
kinda lame (only one node visible).


That doesn't sound right?  Did you try expanding it?  Again, I will
look at it shortly.

Sean

Re: tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Sean Schofield


No documentation on what the allowable facets are.  No documentation
stating that expand and collapse facets need to be UIGraphic
components.  [Guess I shouldn't have tried replacing these with
h:outputTexts]


The facets should be named after the node type.  I know we need more
documentation - I just never got around to it with all of the myfaces
release stuff that I was doing.  I'm taking a step back from the
release stuff for now so I'll try and get back to some tree2 business.

Please fell free to start some docs on the site.  I'm happy to answer questions.

Sean

Re: tree2 documentation: value, var, varNodeToggler missing

2006-08-07 Thread Mike Kienenberger


On 8/7/06, Wendy Smoak [EMAIL PROTECTED] wrote:

On 8/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 I'm throwing all the documentation issues I encounter into this thread
 for now.  Hopefully, I'll have time to update the docs at a later
 point.

Thanks, and so we don't lose track of your comments:

   http://issues.apache.org/jira/browse/TOMAHAWK-584


Thanks, Wendy.   I probably should have done that, but I wanted to
make sure I hadn't missed any other documentation first.


On 8/7/06, Sean Schofield [EMAIL PROTECTED] wrote:

Yes.  I will try to elaborate on that shortly (facing a deadline atm.)


Completely understand.   Take your time.  I've got a deadline in a
couple of weeks myself to meet.


 Also, the http://www.irian.at/myfaces/tree2NoNav.jsf example seems
 kinda lame (only one node visible).

That doesn't sound right?  Did you try expanding it?  Again, I will
look at it shortly.


It doesn't seem to have any navigation controls (hence the name -- NoNav).


On 8/7/06, Sean Schofield [EMAIL PROTECTED] wrote:

 No documentation on what the allowable facets are.  No documentation
 stating that expand and collapse facets need to be UIGraphic
 components.  [Guess I shouldn't have tried replacing these with
 h:outputTexts]

The facets should be named after the node type.


In addition, there's also collapse and expand facets -- I checked
the source -- that expect UIGraphic children.



I know we need more
documentation - I just never got around to it with all of the myfaces
release stuff that I was doing.  I'm taking a step back from the
release stuff for now so I'll try and get back to some tree2 business.


Sean, let me go ahead and work with it for a little bit.   Right now,
I can work on documentation for tree2 (at least documentation drafts),
but I can't work on releases.  I'd rather let you do what only you can
do :)  (or at least, what you can do that I can't).   My new eyes
might point out some things that experienced tree2 users wouldn't see.



Please fell free to start some docs on the site.  I'm happy to answer questions.


Yep,  I'll do this once I get a better feel for the component.

[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example

2006-08-03 Thread Wendy Smoak (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425566 
] 

Wendy Smoak commented on MYFACES-1376:
--

On 02-Aug-2006, Matthias wrote:
 FIXED IN BRANCH

URL: http://svn.apache.org/viewvc?rev=428231view=rev
Log: fixed MYFACES-1376 by moving to commits from svn commit: r421297 to 
branch

URL: http://svn.apache.org/viewvc?rev=428230view=rev
Log: fixed MYFACES-1376 by moving to commits from svn commit: r421297 to 
branch

... and r421297 is:
Author: mmarinschek
Date: Wed Jul 12 08:54:40 2006
New Revision: 421297

URL: http://svn.apache.org/viewvc?rev=421297view=rev
Log:
made calling of several javascript functions dependent on if they are actually 
present. Added source section to the poms. Default message now also prints the 
message of the causes of an exception.


 getScrolling is not defined in simple tree2 example
 ---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
 Assigned To: Matthias Weßendorf
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


 tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example

2006-08-03 Thread Wendy Smoak (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425678 
] 

Wendy Smoak commented on MYFACES-1376:
--

Matthias reverted part of r421297, here:

http://svn.apache.org/viewvc?rev=428629view=rev (shared 2.0.4 trunk)
http://svn.apache.org/viewvc?rev=428630view=rev (shared 2.0.3 branch)

myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/util/JavascriptUtils.java

-private static final String AUTO_SCROLL_PARAM = 
org_apache_myfaces_autoScroll;
-private static final String AUTO_SCROLL_FUNCTION = 
org_apache_myfaces_getScrolling;
+private static final String AUTO_SCROLL_PARAM = autoScroll;
+private static final String AUTO_SCROLL_FUNCTION = getScrolling;



 getScrolling is not defined in simple tree2 example
 ---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
 Assigned To: Matthias Weßendorf
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


 tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-1376) getScrolling is not defined in simple tree2 example

getScrolling is not defined in simple tree2 example
---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example

[ 
http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425401 
] 

sean schofield commented on MYFACES-1376:
-

schedule1.jsf component is also experiencing this problem when you try to 
advance the calendar

 getScrolling is not defined in simple tree2 example
 ---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


 tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1376) getScrolling is not defined in simple tree2 example

2006-08-02 Thread Michael Hartman (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-1376?page=all ]

Michael Hartman updated MYFACES-1376:
-

Status: Patch Available  (was: Open)

 getScrolling is not defined in simple tree2 example
 ---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


 tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1376) getScrolling is not defined in simple tree2 example

 [ http://issues.apache.org/jira/browse/MYFACES-1376?page=all ]

sean schofield updated MYFACES-1376:


Status: Open  (was: Patch Available)

 getScrolling is not defined in simple tree2 example
 ---

 Key: MYFACES-1376
 URL: http://issues.apache.org/jira/browse/MYFACES-1376
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4-SNAPSHOT
Reporter: sean schofield
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT


 tree2NiceWrap.jsf throws a javascript error when you try to expand the node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example