Sean Schofield wrote:
maintaining the expanded state adds a requirement to the node objects
that is not necessary from my POV. This is pure presentation stuff so
why should we annoy the implementer of the model with that kind of
things. In fact it would be nice to use the 'rendered' attribute. But
Sean Schofield wrote:
The tree just happens to be the object with the methods you are
calling. The method will indicated isExpanded (and toggleExpanded)
for the *current node* (not the tree itself.) The tree component is
the actual bean with these methods that gets called by the value
binding exp
The tree just happens to be the object with the methods you are
calling. The method will indicated isExpanded (and toggleExpanded)
for the *current node* (not the tree itself.) The tree component is
the actual bean with these methods that gets called by the value
binding expression. The tree alw
So, the expanded property for the varNodeToggler will apply to a given
TreeNode object?
I wouldn't think that there would be much need to have the tree either
collapsed or expanded as a whole compared to having individual nodes
expanded or collapsed.
On Tue, 8 Feb 2005 11:06:35 -0500, Sean Schof
who generates the varNodeToggler?
On Mon, 7 Feb 2005 12:29:16 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> Here is a revised proposal of how we could do this:
>
>
>
>
>
>rendered="#{t.expanded}" border="0"/>
>value="folder-closed.png"rendere
Here is a revised proposal of how we could do this:
This is similar to earlier examples except the expand/collapse
informa
> For our tree, we render the entire tree on every request, so that the
> user could expand/collapse it as far as they like w/o a reload.
This is how the "client-side" version of the tree will work. It will
use javascript to do this.
> Originally, we built flags into the model such that you coul
> maintaining the expanded state adds a requirement to the node objects
> that is not necessary from my POV. This is pure presentation stuff so
> why should we annoy the implementer of the model with that kind of
> things. In fact it would be nice to use the 'rendered' attribute. But if
> the conse
For our tree, we render the entire tree on every request, so that the
user could expand/collapse it as far as they like w/o a reload.
Originally, we built flags into the model such that you could declare
certain leaves to reload the page if expanded. This way, if you had a
huge tree, you didn't h
Sean,
maintaining the expanded state adds a requirement to the node objects
that is not necessary from my POV. This is pure presentation stuff so
why should we annoy the implementer of the model with that kind of
things. In fact it would be nice to use the 'rendered' attribute. But if
the conse
Oliver,
The rendering rule is an interesting concept. This idea (or a
variation of it) might work. I still find myself wondering if we
can't make this simpler by avoiding introducing these rules and
conditions into the mix.
Take this simple example:
Now I
> In general you don't have to implement TreeNode. What you have to
> implement is TreeModel which should be possible for any kind of
> hierarchial data. TreeNode (and it's implementation
> DefaultMutableTreeNode) is just a helper to be used in combination with
> DefaultTreeModel to create kind of
OK I have a working example. I am enclosing the JSF and a screen shot
in this message. I have also sent those that have expressed interest
a copy of the WAR file. If you would like to receive a copy of the
WAR file to test, just send me an email. I did not want to send it
directly to the list d
Sean Schofield wrote:
I wanted to start a new thread concerning some of the progress I have
been making with the new tree component.
The first bit of news is that I discovered that Hans Bergsten, author
of the O'Reilly JSF book, has a fairly complete example of a custom
tree component. Its been s
Sean,
I don't like to have information like if a node is expanded or not in
the tree data. I was reflecting on that topic and following idea came to
my mind: what about introducing a rendering rule component.
This way we
In general you don't have to implement TreeNode. What you have to
implement is TreeModel which should be possible for any kind of
hierarchial data. TreeNode (and it's implementation
DefaultMutableTreeNode) is just a helper to be used in combination with
DefaultTreeModel to create kind of ad hoc
Heath,
I think that most cases will be covered by the scheme I am proposing.
Ultimately I think it will be hard to implement any kind of tree if
you are unwilling to put your data into some sort of TreeNode
interface.
I see you are using things like #{root.children} and #{child.text}.
So you a
The design you proposed is reflected in the tag.
I'd just want a simple way to define each level.
We actually get very good client-side performance from our trees, its
the server-side memory that's the problem. We might be forced to go
to a server-side tree just to solve that issue, however I'd
> The reason that I'm still a bit opposed to this kind of layout is that
> the way I'm currently using trees is to have different requirements
> for each layer in the tree's hierarchy. That is, different icons at
> different levels, and different nodes being enabled or disabled.
This is what I wa
The reason that I'm still a bit opposed to this kind of layout is that
the way I'm currently using trees is to have different requirements
for each layer in the tree's hierarchy. That is, different icons at
different levels, and different nodes being enabled or disabled.
We currently have a javas
I wanted to start a new thread concerning some of the progress I have
been making with the new tree component.
The first bit of news is that I discovered that Hans Bergsten, author
of the O'Reilly JSF book, has a fairly complete example of a custom
tree component. Its been simplified somewhat bu
21 matches
Mail list logo
