Hi Jason,
Sounds reasonable. You may also consider leveraging JSF's "facet"
capability so that your tree renderer does not have to be so "smart"
when displaying the contents. In my case, I relied on this to define
any TreeNode that was more complicated than plain text or an href.
Another piece of advice (which may be obvious and you may be doing
already), when rendering the child tree nodes, don't cast or check for
instanceof on any of the child UIComponents... just render all of
them. Some components I've seen written cast to an specific instance
(i.e. TreeNode) and call their getters... this prevents things like
Ed's AjaxZone from being inserted in the UIComponent tree to re-render
portions of the tree dynamically.
Good luck!
Ken Paulsen
ken.paulsen@sun.com
https://jsftemplating.dev.java.net
Jason Lee wrote:
Hmm. For now, it's using the
Swing class, but I think I may create some Java classes that mimic, in
terms of nomenclature, the classes supported by the JS component:
TreeNode
TextNode
HTMLNode
MenuNode
A TreeNode would be able to hold
0 or more TreeNode elements for nested levels. This hierarchy would
help me identify at render time what type of node in the JS i need to
create for the given TreeNode on the Java side.
Anyone see any problems with
that?
-----
Jason Lee, SCJP
Programmer/Analyst
Hi Jason,
I have had the privilege of writing a JSF tree component and faced the
same issue. There's more than one right approach (or is that more than
one wrong approach?). But I can share what I did.
On the component side, I composed the Tree of multiple UIComponents. I
defined 2 types of components:
Tree
TreeNode
From an implementation point-of-view, I ended up having Tree extend
TreeNode b/c the root node (represented by Tree) was just a specialized
TreeNode. You could then easily build a tree staticly in a JSP,
Facelets xhtml, or JSFTemplating .jsf file. However, this doesn't
(didn't) address the root of your question.
So... on the "data" side, here's what I did. I defined a factory class
for instantiating part of a Tree structure as described above (or the
entire structure if you want). The factory class required a
"TreeAdaptor" implementation. TreeAdaptor" was an interface that
exposed methods for walking a tree structure that that factory would
call. The interface also exposed methods for getting meta data needed
for the UIComponent (image urls, hyperlink, facets, etc.). The
TreeAdaptor implementations could be written to accept any type of data
structure (i.e. swing TreeNode). This allowed me to walk existing tree
structures and "adapt" them to the UIComponent tree structure required
to represent them in JSF.
You can see the code here:
https://jsftemplating.dev.java.net/source/browse/jsftemplating/src/java/com/sun/jsftemplating/component/factory/tree/
And for impl. of the TreeAdaptor inteface:
https://glassfish.dev.java.net/source/browse/glassfish/admin-gui/admin-jsf/src/java/com/sun/enterprise/tools/admingui/tree/
I don't know if this type of approach is what you're looking for or
not... but I thought I'd share how I dealt with it.
Good luck!
Ken Paulsen
ken.paulsen@sun.com
https://jsftemplating.dev.java.net
Jason Lee wrote:
I'm
trying to write a JSF component wrapper for the YUI tree component. My
first thought on how to represent the tree's data to the component,
based on discussions I've overheard around the office is TreeNode, with
which I have no experience. I quickly discovered that that interface's
package is javax.swing.tree. My gut reaction is that it seems a little
odd to have a JSF component using a Swing interface for its data model,
but I see no better, existing interface/class with which to model my
tree's data. Another option is to design a custom class for just this
purpose. Anyone have any thoughts? For now, I'll probably keep
plodding along with TreeNode and see what happens in the interim. :)
Thanks!
-----
Jason Lee, SCJP
Programmer/Analyst
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net