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.
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
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.