Re: meaning of Area.TreeExt interface
[Glen] 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)? [me] That would make the life of extension writers harder. Thus I would prefer that TreeExt stay. [Glen] Finn, ***be very careful***, the definition of tree extension was #2, *not* #1 (see previous email). I don't like its name, it should be OutOfAreaObject or something like that. And why shouldn't extensions be allowed to create OutOfAreaObjects? Some extension writers will needed that just like the author of fox:bookmarks needed it. regards, finn
Re: meaning of Area.TreeExt interface
[Glen] Actually, to clarify what I wrote: why do we need an extension interface (TreeExt) for objects placed outside the document (pdf bookmarks/metadata), while *not* needing one for extension objects that end up placed *on* the document? You subclass Area for elements on the document and TreeExt for elements outside the document. For the latter types, area creation is hardcoded within our layout managers (to be replaced by extension writers when they have new FO's), so I don't logically see why we can't do the same with the former types. How can an extension pass information onto the renderer if TreeExt (or whatever we want to call it) is removed? regards, finn
Re: meaning of Area.TreeExt interface
--- Finn Bock [EMAIL PROTECTED] wrote: [Glen] Finn, ***be very careful***, the definition of tree extension was #2, *not* #1 (see previous email). I don't like its name, it should be OutOfAreaObject or something like that. And why shouldn't extensions be allowed to create OutOfAreaObjects? Some extension writers will needed that just like the author of fox:bookmarks needed it. OK, now I see. Thanks. Glen
Re: meaning of Area.TreeExt interface
--- Finn Bock [EMAIL PROTECTED] wrote: [Glen] Actually, to clarify what I wrote: why do we need an extension interface (TreeExt) for objects placed outside the document (pdf bookmarks/metadata), while *not* needing one for extension objects that end up placed *on* the document? You subclass Area for elements on the document and TreeExt for elements outside the document. OK, I'd like to 1) rename TreeExt to OffDocumentItem (to clarify what it's really for) 2) change it from an interface to an abstract base class. 3.) Have this base class hold the when parameter for when this ODI is to be generated, so the when does not need to be hardcoded into AreaTreeHandler as it is currently for PDF Bookmarks. (Helps with extensibility.) 4.) Rename Renderer.renderTreeExtension() to Renderer.processOffDocumentItem(). Any problems with this? Thanks, Glen
Re: meaning of Area.TreeExt interface
[Glen] OK, I'd like to 1) rename TreeExt to OffDocumentItem (to clarify what it's really for) 2) change it from an interface to an abstract base class. 3.) Have this base class hold the when parameter for when this ODI is to be generated, so the when does not need to be hardcoded into AreaTreeHandler as it is currently for PDF Bookmarks. (Helps with extensibility.) 4.) Rename Renderer.renderTreeExtension() to Renderer.processOffDocumentItem(). Any problems with this? No. regards, finn
RE: meaning of Area.TreeExt interface
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
Re: meaning of Area.TreeExt interface
[Glen] 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)? That would make the life of extension writers harder. Thus I would prefer that TreeExt stay. regards, finn
Re: meaning of Area.TreeExt interface
--- Finn Bock [EMAIL PROTECTED] wrote: [Glen] 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)? That would make the life of extension writers harder. Thus I would prefer that TreeExt stay. regards, finn Finn, ***be very careful***, the definition of tree extension was #2, *not* #1 (see previous email). I don't like its name, it should be OutOfAreaObject or something like that. Also, TreeExt will be abused, as it could be used for non-#2 reasons. Will you please elaborate how it would hurt extension writers though? Glen
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 --- Keiron Liddle [EMAIL PROTECTED] wrote: Hi Glen, Yes it is sort of #2. I think the naming is along the lines that it is an extension at the tree level, outside the normal formatting areas, not an extension to the area tree as such. In the example of the bookmarks it is an extension that encompasses the whole document (in terms of resolving and output) so rather than being an area it is an extension at the area tree (document) level. Not sure what other examples there would be, but of course it was originally done to handle bookmarks and anything like that that came along. Hope that is clear. Keiron -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Sunday, 24 October 2004 10:46 AM To: [EMAIL PROTECTED] Subject: meaning of Area.TreeExt interface Keiron (or others?), A few years back Keiron created an Area.TreeExt interface for area tree extensions. PDF Bookmarks are our only object that implements this interface currently. I'm not certain what was originally meant by an area tree extension though. Is it: 1.) A layout area that is generated from a non-W3C formatting object (i.e., were fox:bookmarks fo:bookmarks instead, it wouldn't be extending TreeExt.) or 2.) A layout area that is external to what gets printed on the document itself (i.e., fox:bookmarks again, because PDF bookmarks appear outside the document.) From the coding, I'm guessing #2 is the intent. Am I correct? Thanks, Glen
RE: meaning of Area.TreeExt interface
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
