[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
[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
--- 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
--- 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?
[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
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
[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
--- 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
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
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
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
11 matches
Mail list logo
