Re: DefaultTreeModel doesnt user encoder to get the node
how-to maven install the github stitch master zip... http://www.java-forum.org/web-tier/151331-tapestry-einbinden-componentlibraries.html auf Deutschland!http://translate.google.com On Sun, Jul 14, 2013 at 6:33 AM, Boris Horvat wrote: > Component librarybut I can just copy the code as well so no need to > bother on my account. > > Thanks > > > On Sun, Jul 14, 2013 at 2:32 PM, Lance Java >wrote: > > > Hi Boris, > > > > I've always considered tapestry-stitch as more of a "how to" rather than > a > > jar that you'd want on your classpath. I see the main benefit being the > > live demo where you can see the examples running in a servlet container > and > > then the github repo where you can dig a bit deeper. > > > > I've never created an official release and the version has remained at > > 0.0.1-SNAPSHOT. It's probably easiest to copy / paste the code from the > > live demo or from github. > > > > I'm assuming you were referring to the component library (ie the jar). Or > > did you want the demo war? > > > > > > On 13 July 2013 19:56, Boris Horvat wrote: > > > > > Hi Lance, > > > > > > Is there a maven repository that I could used, or do I have to download > > it > > > manually? > > > > > > > > > -- > Sincerely > *Boris Horvat* >
Re: DefaultTreeModel doesnt user encoder to get the node
Component librarybut I can just copy the code as well so no need to bother on my account. Thanks On Sun, Jul 14, 2013 at 2:32 PM, Lance Java wrote: > Hi Boris, > > I've always considered tapestry-stitch as more of a "how to" rather than a > jar that you'd want on your classpath. I see the main benefit being the > live demo where you can see the examples running in a servlet container and > then the github repo where you can dig a bit deeper. > > I've never created an official release and the version has remained at > 0.0.1-SNAPSHOT. It's probably easiest to copy / paste the code from the > live demo or from github. > > I'm assuming you were referring to the component library (ie the jar). Or > did you want the demo war? > > > On 13 July 2013 19:56, Boris Horvat wrote: > > > Hi Lance, > > > > Is there a maven repository that I could used, or do I have to download > it > > manually? > > > -- Sincerely *Boris Horvat*
Re: DefaultTreeModel doesnt user encoder to get the node
Hi Boris, I've always considered tapestry-stitch as more of a "how to" rather than a jar that you'd want on your classpath. I see the main benefit being the live demo where you can see the examples running in a servlet container and then the github repo where you can dig a bit deeper. I've never created an official release and the version has remained at 0.0.1-SNAPSHOT. It's probably easiest to copy / paste the code from the live demo or from github. I'm assuming you were referring to the component library (ie the jar). Or did you want the demo war? On 13 July 2013 19:56, Boris Horvat wrote: > Hi Lance, > > Is there a maven repository that I could used, or do I have to download it > manually? >
Re: DefaultTreeModel doesnt user encoder to get the node
Hi Lance, Is there a maven repository that I could used, or do I have to download it manually? On Sat, Jun 22, 2013 at 3:02 PM, Lance Java wrote: > FYI I've just cleaned up the demo and added a bit of documentation > http://tapestry-stitch.uklance.cloudbees.net/databasetreedemo > > > > On 20 June 2013 18:16, Boris Horvat wrote: > > > Hm...Ok I see the benefit of your implementation I will definitely give > it > > a try this weekend > > > > Thanks > > > > On Thu, Jun 20, 2013 at 3:16 AM, Lance Java > >wrote: > > > > > Yes, that's exactly why I created the LazyTreeModel. > > > > > > The DefaultTreeModel works best when the entire model is loaded into > > memory > > > and the model is stored between requests (in the session or as a > > > singleton). The first time a node is expanded, it must be found by > > > traversing from the root which has complexity O(N). Subsequent > expansions > > > of the same node have complexity O(1) since a hash lookup in a cache is > > > done. > > > > > > In contrast, the LazyTreeModel has complexity of O(1) without needing > to > > be > > > stored between requests. For this reason, I feel it is more scalable > > since > > > you never store the entire tree in memory. > > > > > > > > > > > -- > > Sincerely > > *Boris Horvat* > > > -- Sincerely *Boris Horvat*
Re: DefaultTreeModel doesnt user encoder to get the node
FYI I've just cleaned up the demo and added a bit of documentation http://tapestry-stitch.uklance.cloudbees.net/databasetreedemo On 20 June 2013 18:16, Boris Horvat wrote: > Hm...Ok I see the benefit of your implementation I will definitely give it > a try this weekend > > Thanks > > On Thu, Jun 20, 2013 at 3:16 AM, Lance Java >wrote: > > > Yes, that's exactly why I created the LazyTreeModel. > > > > The DefaultTreeModel works best when the entire model is loaded into > memory > > and the model is stored between requests (in the session or as a > > singleton). The first time a node is expanded, it must be found by > > traversing from the root which has complexity O(N). Subsequent expansions > > of the same node have complexity O(1) since a hash lookup in a cache is > > done. > > > > In contrast, the LazyTreeModel has complexity of O(1) without needing to > be > > stored between requests. For this reason, I feel it is more scalable > since > > you never store the entire tree in memory. > > > > > > -- > Sincerely > *Boris Horvat* >
Re: DefaultTreeModel doesnt user encoder to get the node
Hm...Ok I see the benefit of your implementation I will definitely give it a try this weekend Thanks On Thu, Jun 20, 2013 at 3:16 AM, Lance Java wrote: > Yes, that's exactly why I created the LazyTreeModel. > > The DefaultTreeModel works best when the entire model is loaded into memory > and the model is stored between requests (in the session or as a > singleton). The first time a node is expanded, it must be found by > traversing from the root which has complexity O(N). Subsequent expansions > of the same node have complexity O(1) since a hash lookup in a cache is > done. > > In contrast, the LazyTreeModel has complexity of O(1) without needing to be > stored between requests. For this reason, I feel it is more scalable since > you never store the entire tree in memory. > -- Sincerely *Boris Horvat*
Re: DefaultTreeModel doesnt user encoder to get the node
Yes, that's exactly why I created the LazyTreeModel. The DefaultTreeModel works best when the entire model is loaded into memory and the model is stored between requests (in the session or as a singleton). The first time a node is expanded, it must be found by traversing from the root which has complexity O(N). Subsequent expansions of the same node have complexity O(1) since a hash lookup in a cache is done. In contrast, the LazyTreeModel has complexity of O(1) without needing to be stored between requests. For this reason, I feel it is more scalable since you never store the entire tree in memory.
Re: DefaultTreeModel doesnt user encoder to get the node
I will try it out, however my current implementation works for me. I guess what I like about using encoder is that it allows me to easily override findById (since it is using encoders) and then I can prevent loading of the nodes that cant possible be the one a user clicked... Cheer On Wed, Jun 19, 2013 at 11:13 PM, Lance Java wrote: > FYI I've just added a database backed demo of the LazyTreeModel to > tapestry-stitch > http://tapestry-stitch.uklance.cloudbees.net/lazytreedemo > > Note: The documentation is lacking, the demo is ugly and the sample data is > very sparse... the code could probably do with a refactor too!! > I'll tidy it up when I get some time. > > Cheers, > Lance. > > > On 17 June 2013 20:42, Boris Horvat wrote: > > > Well it is true that encoder cant return Node but the value inside it. > > However that can easily be transformed into a node as I have done. So I > > guess then there will be no plans to change this behaviour in the future? > > > > > > > > On Mon, Jun 17, 2013 at 2:24 PM, Lance Java > >wrote: > > > > > There is no connection to tapestry-stitch. I might put together a demo > in > > > the future if I get the time > > > > > > > > > > > -- > > Sincerely > > *Boris Horvat* > > > -- Sincerely *Boris Horvat*
Re: DefaultTreeModel doesnt user encoder to get the node
FYI I've just added a database backed demo of the LazyTreeModel to tapestry-stitch http://tapestry-stitch.uklance.cloudbees.net/lazytreedemo Note: The documentation is lacking, the demo is ugly and the sample data is very sparse... the code could probably do with a refactor too!! I'll tidy it up when I get some time. Cheers, Lance. On 17 June 2013 20:42, Boris Horvat wrote: > Well it is true that encoder cant return Node but the value inside it. > However that can easily be transformed into a node as I have done. So I > guess then there will be no plans to change this behaviour in the future? > > > > On Mon, Jun 17, 2013 at 2:24 PM, Lance Java >wrote: > > > There is no connection to tapestry-stitch. I might put together a demo in > > the future if I get the time > > > > > > -- > Sincerely > *Boris Horvat* >
Re: DefaultTreeModel doesnt user encoder to get the node
Hi Willy, you seem to have hijacked a thread to start a new topic. I think your problem is caused because you are trying to flatten a grid with no rows. You'll need to render at least one row (even if it contains blank values) for it to be flattened. This could be done by wrapping your GridDataSource in an implementation that returns one empty row when the list is empty. If you require further help, please start a new thread with a new subject.
Re: DefaultTreeModel doesnt user encoder to get the node
my problem is still the same. I am trying to use your Stitch Demo with
gridcollapse to display nested grids. This worked okay, then I suddenly got
this error message a wrote you about.
/*
Hi,
i have been trying to solve this problem for weeks now without any success. I
have some difficulties using your stich-demo.
i get the error message: org.apache.tapestry5.dom.Text cannot be cast to
org.apache.tapestry5.dom.Element
it comes from GridCollapse.java in the function:
private Element findTable(Element container) {
List topChildren = container.getChildren();
Element containingDiv = (Element) topChildren.get(topChildren.size()-1);
//this line causes the error
Element table = containingDiv.find("table");
if (table == null) {
throw new RuntimeException("Could not find table element");
}
return table;
}
}
*/
I just dont get it.
Will
De : Lance Java
À : Tapestry users
Envoyé le : Mardi 18 juin 2013 9h35
Objet : Re: DefaultTreeModel doesnt user encoder to get the node
Even if this functionality changes, I still think that DefaultTreeModel is
flawed.
DefaultTreeModel requires the roots to be instantiated for the model to
exist (it's part of the constructor). If you source your data from a
database and don't store the model in the session or as a singleton this
will cause unnecessary hits to the database. For example when expanding a
tree node, the model is required but the roots are not.
Luckily, TreeModel is an interface and DefaultTreeModel is optional. You
can use my LazyTreeModel or similar.
Re: DefaultTreeModel doesnt user encoder to get the node
Even if this functionality changes, I still think that DefaultTreeModel is flawed. DefaultTreeModel requires the roots to be instantiated for the model to exist (it's part of the constructor). If you source your data from a database and don't store the model in the session or as a singleton this will cause unnecessary hits to the database. For example when expanding a tree node, the model is required but the roots are not. Luckily, TreeModel is an interface and DefaultTreeModel is optional. You can use my LazyTreeModel or similar.
Re: DefaultTreeModel doesnt user encoder to get the node
Well it is true that encoder cant return Node but the value inside it. However that can easily be transformed into a node as I have done. So I guess then there will be no plans to change this behaviour in the future? On Mon, Jun 17, 2013 at 2:24 PM, Lance Java wrote: > There is no connection to tapestry-stitch. I might put together a demo in > the future if I get the time > -- Sincerely *Boris Horvat*
Re: DefaultTreeModel doesnt user encoder to get the node
There is no connection to tapestry-stitch. I might put together a demo in the future if I get the time
Re: DefaultTreeModel doesnt user encoder to get the node
Hi, i am not sure how to connect this to the stitch-demo you wrote before... veillez! car nul ne sait ni l'heure ni ne jour. De : Lance Java À : Tapestry users Envoyé le : Lundi 17 juin 2013 11h49 Objet : Re: DefaultTreeModel doesnt user encoder to get the node FYI, I have always thought that the DefaultTreeModel makes it difficult to efficiently load a TreeModel from the database. If you're not careful, you will fire N+1 selects. I have created an (untested) LazyTreeModel which IMO is much easier to implement an efficient database lookup for tree nodes. The LazyTreeModelAdapter is a much more database friendly interface which logically separates the calls. Code here https://gist.github.com/uklance/5795703 BE WARNED: It's untested
Re: DefaultTreeModel doesnt user encoder to get the node
FYI, I have always thought that the DefaultTreeModel makes it difficult to efficiently load a TreeModel from the database. If you're not careful, you will fire N+1 selects. I have created an (untested) LazyTreeModel which IMO is much easier to implement an efficient database lookup for tree nodes. The LazyTreeModelAdapter is a much more database friendly interface which logically separates the calls. Code here https://gist.github.com/uklance/5795703 BE WARNED: It's untested
Re: DefaultTreeModel doesnt user encoder to get the node
The encoder can't retrieve values of type TreeNode, it can only get values of type T. It seems that DefaultTreeModel is optimised for session persistence. If you'd prefer to load on demand, you might want to override getById() to lookup all node properties from the database
DefaultTreeModel doesnt user encoder to get the node
Hi all. I will try first to explain my use case as that might shad some
light on the problem that I encountered here.
I have a tree that always has 4 main nodes, 2 nodes under each main one and
the then rest of the nodes are created from the db. So something like
category1
subcategory11
subcategory12
category2
subcategory21
subcategory22
category3
subcategory31
subcategory32
category4
subcategory41
subcategory42
So since I didnt wanted to load the complex data structure during the page
load I was quite happy to read that tree has ajax events called on node
expansion.
So all was cool, I wrote my node structure to and it looked like everything
was work however what I noticed is that the *findById * method in
DefaultTreeModel was trying to access each node in the tree to find the
correct one.
Example
User clicks on category2 the DefaultTreeModel will load all nodes from
category1.
Looking into the code of the before mentioned class I could see the problem
private TreeNode findById(String id)
{
TreeNode result = cache.get(id);
if (result != null)
return result;
LinkedList> queue = new LinkedList>(roots);
while (!queue.isEmpty())
{
TreeNode node = queue.removeFirst();
String nodeId = node.getId();
cache.put(nodeId, node);
if (nodeId.equals(id))
return node;
if (!node.isLeaf() && node.getHasChildren())
{
for (TreeNode child : node.getChildren())
{
queue.addFirst(child);
}
}
}
return null;
}
There is no call to the encoder method
toValue(String clientValue)
In this method I have "smart" logic that wont iterate through all of the
nodes but only through the loaded ones.
The implementation is quite simple
private TreeNode findById(String id) {
TreeNode result = cache.get(id);
if (result != null) {
return result;
}
LinkedList> queue = new LinkedList>(roots);
T toValue = encoder.toValue(id);
if (toValue != null) {
DefaultTreeNode node = new
FlowTreeModel.DefaultTreeNode(toValue);
cache.put(node.getId(), node);
return node;
}
return null;
}
So my question is why does DefaultTreeModel doesnt use encoder to get the
node but it instead it tries to iterate through all of the nodes?
Cheers
--
Sincerely
*Boris Horvat*
