4

I am attempting to construct a component tree in JSF 1.2 (Mojarra) where the tree consists of multiple types of junction and leaf nodes. Each leaf node needs to render in a unique way and needs to be posted-back with potential changes. The purpose is to allow the user to update processing logic where each leaf node represents an operation, such as "value equals" or "value not equal".

For example:

Root
|
+- InternalNode1 (type I_A)
|  |
|  +- LeafNode1 (type L_A)
|  |
|  +- LeafNode2 (type L_B)
|
+- InternalNode2 (type I_B)
   |
   +- LeafNode3 (type L_B)
   |
   +- LeafNode4 (type L_A)

Each type of leaf node needs to render differently, depending on the needs of that node type. Additionally, the tree will be modifiable and nodes can be added or removed with Javascript and updates posted back to the server, etc. For example, in the above tree, LeafNode4 could be removed, or its type changed to L_B.

Is this even possible with JSF components? Am I going about it the wrong way by attempting to use polymorphic UI components?

Michael Edgar
  • 350
  • 3
  • 12

2 Answers2

2

You might want to look at <rich:tree>.

Don Roby
  • 40,677
  • 6
  • 91
  • 113
  • Thank you for your reply. Depending on the route I take, I may be able to use some of the concepts discussed. Using RichFaces probably won't be an option at my place of employment however :-) – Michael Edgar Jun 08 '11 at 13:47
1

It is possible to build a component tree programmatically, but this would be the wrong approach for your use-case. It would generally be unsecure to allow the user-agent to manipulate such server-side code.

It would be better to use a model to manage your tree structure (which is essentially the approach Don Roby is suggesting.) The data that makes up this model can then be validated like any other user input to ensure attackers aren't trying to put server-side data into an invalid state.

JSF's declarative approach makes it challenging to do this out of the box (you can see a crude tree rendering example here.) If you don't want to drag in a 3rd party library (or write your own control) you may be better off handling all the tree UI in JavaScript and using a JSF hidden field to transport it to/from the server.

Community
  • 1
  • 1
McDowell
  • 107,573
  • 31
  • 204
  • 267
  • Thank you for your response. I am interested in the custom `UIComponent` approach you mentioned where the component contains my data model. My trouble is understanding how the data is reconstituted on post-back. If the leaf nodes of the data model contain pluggable classes (polymorphic) that each have varying inputs/selects/etc, then do I need code in the component's `decode` method to parse that out and recontruct the tree? The JavaScript/hidden field solution are also interesting. It could be possible to manipulate a JSON tree and parse that and get away from the entire component idea. – Michael Edgar Jun 08 '11 at 13:43
  • @MGE - generally, you would decode submitted data in the `Renderer` from the request parameter map. If you want to allow forms to send data back to the server, you'll probably need to use hidden fields anyway. Which approach you take is largely a matter of personal preference - do you want the deserialization logic in beans, a `Converter` or a `Renderer`? Do you want a `Renderer` to emit the tree as HTML or parse data in JS and recreate on page load? You are going to have to write the JavaScript to a greater or lesser extent anyway. – McDowell Jun 08 '11 at 14:55