Re: [VOTE] ElementMapping changes & 5 FO's into pagination
J.Pietschmann wrote:
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.
Change done.
> (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
+1 (still)
Let me see if I can give you an acceptable
non-spec-heavy reason to make these changes. I agree
that the spec should not be the ultimate guide for
where to put the classes--but currently the spec and
Fop's architectural implementation appear to be saying
one thing, while the package/class layout is saying
another:
1) The fo.flow.Flow and its fo.flow.StaticContent
subclass, in addition to not referencing anything in
Flow package, are both referencing pagination classes.
These are the only classes in fo.flow doing so.
2) Also, in fo.pagination.*, the only fo.flow objects
being referenced are flow.Flow and flow.StaticContent.
So moving these two classes to pagination would make
both packages completely independent of each
other--meaning we've made a very nice break of the
formatting objects--hard to do considering there's 57
of them.
As for the other three still sitting in "fo"--I
believe the original decision to subclass the fo's is
because there are too many of them, and also a desire
to keep them separate from the FOTreeBuilder-specific
code. It is strange to move just 54 out of 57 of
them, however, and not *all* to subclasses.
Regardless, looking at their spec definitions:
fo:title: The fo:title formatting object is used to
associate a title with a given page-sequence.
(therefore, tied to pagination.PageSequence?)
fo:declarations: The fo:declarations formatting object
is used to group global declarations for a stylesheet.
(pagination.Root?)
fo:color-profile: The fo:color-profile formatting
object is used to declare an ICC Color Profile for a
stylesheet. (spec would indicate pagination.root, but
possibly {pagination}.declarations).
It seems that sooner or later these three should also
move to pagination--but I'm less certain on these than
I am on the other two.
Thanks,
Glen
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] ElementMapping changes & 5 FO's into pagination
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[VOTE] ElementMapping changes & 5 FO's into pagination
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
