Hi,
did just that:
http://issues.apache.org/jira/browse/TOMAHAWK-739
regards,
Martin
On 10/14/06, Sean Schofield [EMAIL PROTECTED] wrote:
The problem was that you changed the TreeWalker interface. I've fixed
my TreeWalker implementations but everyone else is going to have to do
the same.
The problem was that you changed the TreeWalker interface. I've fixed
my TreeWalker implementations but everyone else is going to have to do
the same. I suggest at a minimum that you create a JIRA issue and
mark it resolved so it makes it into the release notes.
Sean
On 10/10/06, Martin
Hi Sean,
ok, I see - I thought it would be good to separate Tree and TreeWalker
a bit more, so that I could reuse at least some of the functionality.
I don't want the tree to _contain_ EditableValueHolders, but the tree
to be an EditableValueHolder itself - imagine a dropdown which shows a
I don't want the tree to _contain_ EditableValueHolders, but the tree
to be an EditableValueHolder itself - imagine a dropdown which shows a
tree, and you can select values from it...
maybe a subclass is needed here, since that seams not to be a common
use case, right?
(I think we already said
Yeah. I've already settled for a subclass. I had to copy over almost
everything from the tree-sources. The only thing which rescued me from
having to copy all was introducing the interface. Sean, is there a way
you can get the interface working according to your needs?
regards,
Martin
On
Martin,
What is the big deal about EditableValueHolder? Why should tree2
implement this? The idea is that Tree2 contains a tree of whatever
types of JSF components you choose (just like dataTable.) You can use
editable value holders right now if you want to. Just add one to your
node. I am
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
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
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
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
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
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
For better scope control perhaps we should have a baseTree and an
advancedTree component set?
yeah, maybe we go the route like Faces does it self.
A generic component (UITree) and some more specialized
(EditableTree) or what ever.
-M
Cheers,
Zubin.
On 10/5/06, Matthias Wessendorf [EMAIL
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
Precisely! Perhaps Werner can chime in some more on this too..Z.On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED]
wrote:regarding the ajaxized version, would be cool if the renderer takes
care of dojo.rendering out the dojo:widget / things and adding the dojo.jsfile to the *header* of the
I bet! :)
On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:
Precisely! Perhaps Werner can chime in some more on this too..
Z.
On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
regarding the ajaxized version, would be cool if the renderer takes
care of dojo.
rendering out the
Let me read the entire thread first :-)
later tonight
Matthias Wessendorf schrieb:
I bet! :)
On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote:
Precisely! Perhaps Werner can chime in some more on this too..
Z.
Hello Mattias,
I am so new to this list and may be I am not allowed to say this, but I
think most developers I have seen use menu related components for only
displaying structured data, and most of times data is displayed to user for one
of the following purposes:
1) selecting one item
2)
hi Arash,
sure your feedback is welcome :)
like said before, a generic raw version + aditional tree stuff.
During that task we should also take a look at tree / treeTable, IMHO.
-M
On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
Hello Mattias,
I am so new to this list and may be I am
Well, it wouldn't be a problem to have an extended version of the tree
which implements EditableValueHolder, but not if the model of the tree
is configured by setting the value-attribute - then extending won't
work.
regards,
Martin
On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi
No, it's a pity that not, but I can't. I'm at a client here in Germany
until end of November, can't take off a week.
regards,
Martin
On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote:
Martin: I haven't had time to read this thread yet but I will shortly.
Are you going to be at Apache Con
Dear Martin I think for most people its easier to use list of values as selection model of the tree.would you please also consider adding an Ajax capability to Tree2 ?(beside server mode and client mode)
regardsOn 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,I'm reviewing the tree2
would you please also consider adding an Ajax capability to Tree2 ?
(beside server mode and client mode)
there is a cool post from Rick Hightower how to use dojo and tree2 (or
was it tree)
-Matthias
regards
On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
I'm reviewing the
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
I'm throwing all the documentation issues I encounter into this thread
for now. Hopefully, I'll have time to update the docs at a later
point.
No documentation on what the allowable facets are. No documentation
stating that expand and collapse facets need to be UIGraphic
components. [Guess I
On 8/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm throwing all the documentation issues I encounter into this thread
for now. Hopefully, I'll have time to update the docs at a later
point.
Thanks, and so we don't lose track of your comments:
I'm guessing var and value work like any UIData component (and it
should be simple to copy those into the tlddocs from dataTable).
You guessed correctly.
However, varNodeToggler doesn't have any non-code documentation that I
could find. I'm guessing it's an object that implements some kind
No documentation on what the allowable facets are. No documentation
stating that expand and collapse facets need to be UIGraphic
components. [Guess I shouldn't have tried replacing these with
h:outputTexts]
The facets should be named after the node type. I know we need more
documentation - I
On 8/7/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm throwing all the documentation issues I encounter into this thread
for now. Hopefully, I'll have time to update the docs at a later
point.
Thanks, and so we don't lose track of your
Sounds like a bug. Please file a JIRA issue and I will take a look at
it. Include the suggested fix mentioned in your email. This is the
best way to make sure things don't get lost.
Sean
On 5/10/06, Chris Hane [EMAIL PROTECTED] wrote:
I have been playing around with the tree2 control
The backing beans are in the svn repository.
Use subversion:
svn checkout of https://svn.apache.org/repos/asf/myfaces/current/
and look in the tomahawk/examples dir.
Sean
ps. Please post these types of questions to the user list in the future.
On 4/25/06, joe_ersinghaus [EMAIL PROTECTED]
Please post to the user list.
FYI I hope to turn my attention to many of the outstanding tree2
issues shortly. Stay tuned on the user list.
Sean
On 2/8/06, Michal Glowacki [EMAIL PROTECTED] wrote:
Hello all,
I've got question to Sean (well, maybe someone else could help me as
well).
Please post these questions to the users list *only.*
Regards,
Sean
On 2/1/06, Yixing Ma [EMAIL PROTECTED] wrote:
How to expand tree in MyFaces 1.0.9?
I've been using tree2 for a while. So far only the myfaces 1.0.9 works for
my program. Other implementations have this and that problems,
OK. thanks for reply
- Original Message -
From: Sean Schofield [EMAIL PROTECTED]
To: MyFaces Development dev@myfaces.apache.org
Sent: Wednesday, February 01, 2006 4:25 PM
Subject: Re: tree2 expand myfaces 1.0.9
Please post these questions to the users list *only.*
Regards,
Sean
[EMAIL PROTECTED]
Date: Wed Jan 25 11:19:05 CST 2006
To: [EMAIL PROTECTED]
Subject: RE: tree2 clientSideToggle question need more help
Remove the cached files including the cookies from your browser when changed to
clientsidetoggle
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Please post to the user list. This list is for discussions about the
codebase and infrastructure issues.
Regards,
Sean
On 1/19/06, Laurent Laniau [EMAIL PROTECTED] wrote:
Hello,
I would like to expand a tree2. I use a framework which link jsf with
hibernate. So i have a bean, which
On 11/24/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
[snip]
The easiest solution (in my opinion) is to have the tag attribute
names and the component attribute names be the same. Almost all
components in tomahawk and JSF currently have matching names.
I guess this is ok.
Another
Sure. I'm not in any rush, so just let me know when.
On 11/28/05, Sean Schofield [EMAIL PROTECTED] wrote:
On 11/24/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
[snip]
The easiest solution (in my opinion) is to have the tag attribute
names and the component attribute names be the same.
It's not that it can't be done in facelets -- it's that it's kludgy to
handle attributes named one thing on the page tag and another thing on
the component class.
Facelets doesn't require a tag handler class to assign attributes.
It directly reads the attributes off the page text and assigns
Mike,
I don't know much about facelets but I'm curious to know what is
causing the problem. If facelets doesn't support attribute properties
with '.' characters in the name then IMO that is really the source of
the problem.
Its considered good practice to have fully qualifies names in your
Hi Anu,
You'll want to post these kinds of messages to the group, because other
people are using Tree2 as well.
The facets for Tree2 are purely user-defined; they must correspond
exactly to the type property values of the nodes you instantiate.
You don't have to write any renderers to use Tree2
No comments on this? The bugs are fairly serious.
Or should I just expect the comments to be You found
it, now fix it! ;-)
-- Jon
On Sep 6, 2005, at 5:40 PM, Jon Travis wrote:
I've been evaluating recent changes to Tree2 to see if they
work out in a dynamic environment (when the contents
Sorry I haven't had a chance to look at it in detail. I've been
really busy with my day job. I will try to look at it soon. Perhaps
Mathias can also take a look?
sean
On 9/9/05, Jon Travis [EMAIL PROTECTED] wrote:
No comments on this? The bugs are fairly serious.
Or should I just expect
I've had a few people email me asking about tree2 status so I'm
bumping this message to the top of the list for people to respond to.
Please see the archives for the original part of this thread.
sean
On 7/26/05, Sean Schofield [EMAIL PROTECTED] wrote:
Some of my larger tree2 forms are
That's a possibility.
We've gotten our lazy load to work as follows (which admittedly is
sub-optimal, since it doesn't use the navigation icon features built
into the component):
x:tree2 id=serverTree value=#{treeBacker.treeData} var=node
varNodeToggler=t
clientSideToggle=false
Some of my larger tree2 forms are incredibly
slow - even slower than the JIRA. As many other users, I approached
the problem with a lazy load mechanism.
It turned out the bottleneck was bandwidth.
One page was a 1.7 MB download. I am now extending the renderer
and using CSS instead of HTML
Some of my larger tree2 forms are incredibly slow - even slower than the
JIRA. As many other users, I approached the problem with a lazy load
mechanism.
It turned out the bottleneck was bandwidth. One page was a 1.7 MB download.
I am now extending the renderer and using CSS instead
Hi,
Try to prefix the generated id from
context.getViewRoot().createUniqueId() with something else.
Mathias
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 07, 2005 9:35 AM
To: MyFaces Development
Subject: tree2 expand/collapse graphic and
Doh! That was left over from when I was debugging a JIRA fix. The
fix is that if the node is missing you get a message instead of a null
pointer. That was in there intentionally to create null pointers. It
was supposed to come out.
I will commit the fix shortly. Thanks for the heads up.
The fix is in.
On 5/25/05, Sean Schofield [EMAIL PROTECTED] wrote:
Doh! That was left over from when I was debugging a JIRA fix. The
fix is that if the node is missing you get a message instead of a null
pointer. That was in there intentionally to create null pointers. It
was supposed to
Change is now in CVS. Thanks for contributing to MyFaces!
sean
On Apr 5, 2005 9:36 PM, Jon Travis [EMAIL PROTECTED] wrote:
Here's a patch to get Tree2 working with the binding attribute
(and render, apparently). Note, also, that myfaces_ext.tld
is riddled with tabs, and therefore looks
I forwarded you (dirctly) an older email from
Sean, that fits your needs, I hope.
-Matthias
Eric Hsieh wrote:
Is there an easy way in tree2 to mark the currently
selected node in the tree? I want to replicate the
behavior that the original tree had wherein you
clicked on a node and the node would
Sean,
you do not accept my argument that the wrapper objects I would need
following your programming model waste memory. That's fine for me. But
tell you what: I do not accept your argument that implementing TreeModel
is a special case nobody else is using. My colleagues and I have
implemented
Oliver,
You continue to embarass yourself with these ranting email messages.
Up until this point I have been *more* than patient with your antics.
I have tried over and over again to be diplomatic with you about this.
I understand that you put a lot of hard work into the original tree
control
I am sorry if the email I just sent made it to the list. I initially
meant to reply to the list but changed my mind and decided that I
would just include Manfred and Oliver. I stand by the contents of the
email but I had not meant to bother the rest of the developers with
this matter.
I am
Schofield [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 13, 2005 7:13 PM
To: MyFaces Development
Cc: Manfred Geiler
Subject: [offlist] End of the Road (Was Re: Tree2)
Oliver,
You continue to embarass yourself with these ranting email messages.
Up until this point I have been *more* than
Sean Schofield wrote:
snip
Yes you are repeating yourself over and over on this point. I do not
see how tree2 has changed the basic requirments of the user. You keep
saying that I am against TreeModel and for TreeNode. That is not the
case. Let me try to phrase my argument differently ...
You
Oliver,
You are correct that option 3 is missing in the new tree and that its
present in JTree and the current tree. This was not designed to
intentionally deprive you of functionality that you need in your
application. It didn't really occur to me that tree should support
this kind of
Manfred,
I don't know what was wrong with my post or with Sean's reply that
caused you to write this message, but anyway I sign 99% of it's content.
The 1% I can not follow completely is the point according interface
changes. From my POV we have to be careful in changing existing
components.
Sean,
I'm sorry if I was not specific enough in my first attempt so let's try
again:
o) TreeNode instead of TreeModel
My argument here is that TreeModel in the way it is used by the current
tree component and in the way it is used by the Swing JTree is more
generic and lightweight than your
I don't know what was wrong with my post or with Sean's reply that
caused you to write this message, but anyway I sign 99% of it's content.
The 1% I can not follow completely is the point according interface
changes. From my POV we have to be careful in changing existing
components. If you
Sean,
I'm sorry but I feel somewhat like talking to stones at the moment :-(
I'm repeating myself over and over again but you just seem to ignore my
argument that TreeNode is nothing more than a helper interface to
support the Swing JTree component. Please have a look at the sources if
you
Oliver,
I'm sorry but I feel somewhat like talking to stones at the moment :-(
I'm repeating myself over and over again but you just seem to ignore my
argument that TreeNode is nothing more than a helper interface to
support the Swing JTree component. Please have a look at the sources if
you
I am actually working on a change for that right now. I'm going to
add three new tag attributes: javascriptLocation, styleLocation,
imageLocation (right now styleLocation is unecessary.) So you can
specify your own location for the navigation images and javascript (or
replace them with your
Yeah this way you aren't forced to use the extensions filter, etc.
While that is a nice feature (I plan to use it myself) its not for
everyone. Plus you can override the icons and potentially override
the javascript.
BTW, there is an option to turn off the navigation icons and
connecting lines
Oliver, Sean,
I do not understand every single issue in your current discussion, but
what I see is some danger in the direction your discussion is heading
for at the moment. Please, both, lean back for a few seconds. My stuff
is better discussions are always counterproductive and often end with
None of your components, tree or tree2, is better than the other one.
Both are excellent components with perhaps different features.
Agreed. When Oliver and I started this process we agreed that there
was room for improvement in the current tree control. I think we've
made some of those
67 matches
Mail list logo
