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. > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > http://tinyurl.com/fmywh > > > > > > further stuff: > > > blog: http://jroller.com/page/mwessendorf > > > mail: mwessendorf-at-gmail-dot-com > > > > > > > > > > -- > Matthias Wessendorf > http://tinyurl.com/fmywh > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com >
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
