Ok

Using checkboxes works just fine, and the tree structure seems to work now. But the lack of control when rendering the tree is unfortunately a very big problem for me, so I guess I'll have to do this using other techniques than the tacos or tapestry tree components.

My main problem is that I don't have the luxury of telling the designers that they have to change the page layout to adjust to my implementation needs. I have to adjust to the page design.

My current page design is like this:

for each tree node {
 Start a table tag
   Draw checkbox in first table data
   Draw collapse/expand icon in second table data
   Draw node name with some link in third table data
 End table tag
}

The icon and the node name could be placed in one single table data too.

I looked a little bit at the tacos source code, trying to figure out a way to add this kind of flexibility in presenting the tree, but I only met a lot of walls due to the nested complexity :) The code is very elegant and surprisingly simple looking, by the way!

Inge



Jesse Kuhnert wrote:
The css attributes control most of the formatting, but you are kind of
on your own if you're going to go pre-tapestry4. (unless other people
here can help you) .

I'm using the tree component within forms, with checkboxes as well.
They are displayed to the right of the tree nodes though, it seemed
cleaner.   This is of course with tacos4 only though.

jesse
On 11/9/05, Inge Solvoll <[EMAIL PROTECTED]> wrote:

Thanks for the help, it seems that my problem was caused by stupidity
and a lazy developer who didn't want to face the fact that his
contentProvider could be null.

One complaint: Isn't it possible to keep up with the excellent line
precise error reporting in Tapestry, and let the Tree component return a
more precise error message on these errors?

As of now, I'm up to speed with my tree structure, and now I proceed
with the visual layout. I have one more question:

I want to have a checkbox to the far left of the page for each node,
with functionality like: "Check this node if you want to delete it".
Until now I haven't been able to make this happen, the checkbox appears
between the plus-icon and the node name. Is there any way to achieve
this behaviour, to put parts of the node rendering "outside" of the tree
iteration?

I would also like to use something like ListEdit to get
selected-properties out of the checkbox for each tree node, but I guess
this isn't possible without some custom code from me.

Thanks again for all the great help from the mailing list, this is one
of the biggest pros to this great framework!

Inge


Jesse Kuhnert wrote:

This usually means either an IContentProvider or IKeyProvider wasn't
available during render. You can also try setting nodeLinkAjax
parameter to false to see if I've introduced a new bug. Let me know.

jesse
On 11/8/05, Inge Solvoll <[EMAIL PROTECTED]> wrote:


I'm trying to use a tacos:Tree component in my page, without luck. I get
the following error when clicking on the plus image, expanding a node:

Unable to invoke method expansion on
[EMAIL PROTECTED]/$DivisionSelectionTree.tree]:
null

I've tried switching to the excact same jar-files as the demo
application uses, no difference.

As you've probably understood, the tree renders correctly at first
showing the root node with a plus-icon next to it. When clicking on the
plus-icon, there is one child node of the root node that should be made
visible.

I've tried setting breakpoints in my content provider, as well as in the
component containing the tree component, but the page crashes before
these are called. I've also tried to put breakpoints in all methods in
Tree and TreeManager, but none are reached. This usually works for me in
other classes.

Any ideas?

Here's the rest of the stack trace:



java.lang.IllegalArgumentException
Stack Trace:

   * net.sf.tacos.tree.TreeManager.<init>(Unknown Source)
   * net.sf.tacos.tree.Tree.getManager(Unknown Source)
   * net.sf.tacos.tree.Tree.expansion(Unknown Source)
   * sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   *
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   *
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   * java.lang.reflect.Method.invoke(Method.java:324)
   *
org.apache.tapestry.listener.ListenerMap.invokeTargetMethod(ListenerMap.java:257)
   *
org.apache.tapestry.listener.ListenerMap.access$100(ListenerMap.java:46)
   *
org.apache.tapestry.listener.ListenerMap$SyntheticListener.invoke(ListenerMap.java:97)
   *
org.apache.tapestry.listener.ListenerMap$SyntheticListener.actionTriggered(ListenerMap.java:102)
   * org.apache.tapestry.link.DirectLink.trigger(DirectLink.java:119)
   *
org.apache.tapestry.engine.DirectService.service(DirectService.java:169)
   *
org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:889)
   *
org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:198)
   *
org.apache.tapestry.ApplicationServlet.doGet(ApplicationServlet.java:159)
   * javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
   * javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   *
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
   *
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   *
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
   *
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
   *
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   *
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   *
no.dossier.moby.frontend.common.filters.BasicFilter.doFilter(BasicFilter.java:161)
   *
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   *
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   *
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
   *
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
   *
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
   *
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   *
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
   *
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
   *
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
   *
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
   *
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
   *
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
   *
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
   * java.lang.Thread.run(Thread.java:534)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to