Tweaking the FO class hierarchy

[Jeremias Maerki <de...@greenmail.ch>]

I'm currently playing around with external-graphic and
instream-foreign-object as you may have seen. It's my attempt to dive
into the whole layout engine thing.

I realize that there are a lot of similarities (and redundancy) between
the two classes (and even their LM counterparts). I wonder if I should
create a common (abstract) base class for the two. Is there anything
that speaks against that other than it may be appropriate to check for
additional refactoring possibilities? I'm not planning on reworking the
whole thing, just to improve what I stumble upon.

Jeremias Maerki

Re: Tweaking the FO class hierarchy

[Simon Pepping <sp...@leverkruid.nl>]

Jeremias,

On Tue, Dec 28, 2004 at 10:32:01PM +0100, Jeremias Maerki wrote:
> I'm currently playing around with external-graphic and
> instream-foreign-object as you may have seen. It's my attempt to dive
> into the whole layout engine thing.
> 
> I realize that there are a lot of similarities (and redundancy) between
> the two classes (and even their LM counterparts). I wonder if I should
> create a common (abstract) base class for the two. Is there anything
> that speaks against that other than it may be appropriate to check for
> additional refactoring possibilities? I'm not planning on reworking the
> whole thing, just to improve what I stumble upon.

I know nothing that speaks against that.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Tweaking the FO class hierarchy

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

--- Jeremias Maerki <de...@greenmail.ch> wrote:
>
> I'm currently playing around with external-graphic
> and
> instream-foreign-object as you may have seen. It's
> my attempt to dive
> into the whole layout engine thing.
> 

Yes, I was very surprised and happy to see you working
in layout!

> I realize that there are a lot of similarities (and
> redundancy) between
> the two classes (and even their LM counterparts). I
> wonder if I should
> create a common (abstract) base class for the two.

They are similar enough that that would be an
acceptable design.  We already do the same with
fo:static-content and fo:flow (more or less suggested
by the spec, which IIRC declares them both flows), and
the region classes.


> Is there anything
> that speaks against that other than it may be
> appropriate to check for
> additional refactoring possibilities? 

Yes, be careful that the decision is not just based on
coincidentally common functionality.  They should be
closely similar objects.  (Also too many classes, even
if reduced LOC in each as a result, can make FOP seem
larger and more complex than it actually is, which can
intimidate newbies.)

For a silly example, if both class Teacher and class
AlpsMountain happen to have a "getLocation()" method,
it wouldn't necessarily follow that we should have an
abstract TeacherOrAlpsMountain base class.  OTOH,
class Teacher, class Policeman should probably extend
a common abstract class Worker.

The recommendation does not declare any relationship
between instream-foreign-object and external-graphic,
other than that they are both formatting objects. 
This two-tier hierarchy is already present in FOP, as
we  have them both extend FObj.  But, again, they are
close enough that an abstract base class may not be
such a bad idea.

Glen