[VOTE] ElementMapping changes & 5 FO's into pagination

[Glen Mazza <gr...@yahoo.com>]

Team,

Two new changes I would next like to make to the trunk
branch--These are unrelated, separate votes:

(1.)  I would like to remove the addToBuilder()
function (and update its subclasses) from the
ElementMapping interface and replace it with
getNamespaceURI() and getFOTable() functions (and
possibly initialize()--depending on committer input on
the below).  

Currently the FOTreeBuilder->ElementMapping attachment
process is somewhat convoluted due to internal
initialization needed in each ElementMapping subclass
to create all the FO's:

step 1) In FOTreeBuilder:
public void addElementMapping(ElementMapping mapping)
{
   mapping.addToBuilder(this);
}

step 2) In FOElementMapping subclass (for example):
public void addToBuilder(FOTreeBuilder builder) {
   setupFO();
   String uri = "http://www.w3.org/1999/XSL/Format";
   builder.addMapping(uri, foObjs);
}

step 3) Back to FOTreeBuilder:
public void addMapping(String namespaceURI, HashMap
table) {
   this.fobjTable.put(namespaceURI, table);
   this.namespaces.add(namespaceURI.intern());
}

What I would like to simplify this to just one
function in FOTreeBuilder:

1) In FOTreeBuilder:
public void addElementMapping(ElementMapping mapping)
{
   mapping.initialize();  // needed? -- see below
   this.fobjTable.put(mapping.getNamespaceURI(), 
      mapping.getFOTable());
  
this.namespaces.add(mapping.getNamespaceURI().intern());
}

Note:  I can make the initialize() private and called
within the ElementMapping subclass upon the first call
to mapping.getFOTable(); then it won't be needed to be
called externally.  (getNamespaceURI() wouldn't need
initialization; it just returns a static string.)  Or
it can be made public and called
explicitly--suggestions welcome.

Here's my +1.

(2.)  I'm starting to look at the FO's currently in
the fo, fo.flow, and fo.pagination packages and
comparing them to the spec.  Most of the FO's are in
fo.flow package, three are in the fo root, and the
remainder are in fo.pagination.

14 of the 19 FO's listed in Section 6.4 "Declarations
and Pagination and Layout Formatting Objects" and also
in the 6.4.1.6 "Pagination Tree Diagram" are in the
pagination package.  Five are not--Declarations,
ColorProfile, and Title are in fo, and StaticContent
and Flow are in the fo.flow package.  I'd like to move
these five to the pagination package--that will keep a
1-to-1 mapping between these FO's and their location
in the spec/diagram, also it will better consolidate
the FO's from 3 to 2 packages.

Here's my +1.

Sorry for the wordy post.

Thanks,
Glen


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [VOTE] ElementMapping changes & 5 FO's into pagination

["J.Pietschmann" <j3...@yahoo.de>]

Glen Mazza wrote:
> (1.)  I would like to remove the addToBuilder()
> function (and update its subclasses) from the
> ElementMapping interface and replace it with
> getNamespaceURI() and getFOTable() functions

+1

BTW this is not a change which requires a vote.

> (2.)   I'd like to move
> these five to the pagination package

-1
While the packaging of the files may be suboptimal, I
don't feel there is much to gain from moving stuff
around right now. In particular I don't think the
FO spec should be the ultimate guide. The package for
Page and Region classes are more of a concern to me
anyway.

J.Pietschmann



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org