If you hard code the bookmarks how would you handle the id resolution, as that is done through the area tree. Potentially you could code the bookmarks in other renderers like AWT.
-----Original Message----- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Monday, 25 October 2004 12:26 PM To: [EMAIL PROTECTED] Subject: RE: meaning of Area.TreeExt interface Thanks for the clarification. PDF Bookmarks aren't working currently, so that's what I'm looking at ATM. We may have another object extending the TreeExt interface, should we have a fox:metadata in the future. Still, I wonder if it may be better to do away with this interface and just hardcode the layout/rendering of these objects (i.e. bookmarks) directly, just like we do all the other Area objects that are created during the layout process. This would simplify area.extensions.BookmarkData and area.AreaTreeModel processing code. Thoughts (anyone)? The major benefit I see of TreeExt is that our Renderer interface can remain with a single renderExtension() for this and any other TreeExt in the future. But OTOH clarity arguments can be made for explicitly spelling out each object that a Renderer may need to support. For example, having renderBookmarks(), processMetaData(), etc. methods instead of using instanceof within renderExtension() methods to determine the TreeExt object in question. Thanks, Glen
