Oh no...I meant removing the TreeExt interface, and instead coding for the underlying BookmarkData object that it represents within AreaTreeHandler instead. Our code including id resolution (it will still implement Resolvable) remains mostly the same, and in the same places (AreaTreeHandler and RenderPagesModel.)
Increasingly I'm seeing AreaTreeHandler as something of a RootLayoutManager, responsible for handling its graphical objects -- Bookmarks and (future) Metadata -- in the same manner that all the other LayoutManagers create/handle their area objects: explicitly ordered and coded. And yes, all renderers will still receive a handleBookmarkData() function call (instead of the current handleExtension()), and also a future handleMetaData(), with the hopes that as many as possible can work with the information. Glen --- Keiron Liddle <[EMAIL PROTECTED]> wrote: > > 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 > > >
