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
