Hello,
----- Original Message -----
From: "Andreas L. Delmelle" <[EMAIL PROTECTED]>
>
> Hi,
>
> > I have attached first phase (a working example) of the refactoring I was
> > talking about in my previous mails. Please let me know, if this change
is
> > acceptable for you. If it is, I will finish it afterwards.
> >
>
> Just let me see if I get this straight...
> The only real change that is being proposed, is delegating the creation of
> Areas to a Factory which is an instance variable in the UserAgent, where
> currently the instantiations happen directly in the LMs (new ...)?
Correct?
> And all that leads to being able to plug in custom Area Factories?
>
Yes, that's all. Very similar situation would take place in case of
pluggable LMs.
> Complexity of design doesn't increase very much... (well, it certainly
> doesn't 'shoot through the roof' :-) )
>
> To address Glen's concern about changing:
>
> curBlockArea = new Block();
>
> into
>
> curBlockArea = (Block) fobj.getUserAgent().
> getAreaFactory().create(Block.class, fobj, this);
>
> Couldn't we, say, add a method to the UserAgent that contains the
> communication with the AreaFactory, so that the above would become:
>
> curBlockArea = (Block) fobj.getUserAgent().createArea(Block.class, fobj,
> this)
>
> The method in the UserAgent would simply be:
>
> Area UserAgent.createArea(...) {
> return getAreaFactory.create(...);
> }
>
> Or maybe even add one to the fobj itself, so that in the LMs the code
would
> be:
>
> curBlockArea = (Block) fobj.createArea(Block.class, this)
>
> In combination with the above, the method in FObj would look like:
>
> Area FObj.createArea(class, LM) {
> return getUserAgent().createArea(class, this, LM);
> }
>
> Adding the possibility for the FObj to intervene, manipulate the Area
before
> returning it from the UA to the LM... (--usefulness?)
> Dunno, maybe the logic of 'creating/instantiating' the Areas should indeed
> be moved away from the LMs --restrict the task of the LM to merely 'laying
> out the content on' the Areas as supplied, in this case, by the
UserAgent...
>
> Actually, doesn't seem like such a bad idea to me, but I'd definitely like
> to hear some other opinions.
>
>
> Cheers,
>
> Andreas
I don't like decreased readabality of more complicated code for Area
creation, too.
But:
1) createArea(...) in UserAgent:
In my opinion, UserAgent is more a place which provides configuration
details for other elements in XSL-FO processing (layouter, renderer, ...),
creation of areas (although only delegated to actual AreaFactory) is not a
concern of this class
2) createArea(..) in FObj: FObj tree is a data structure independent of the
layout; layout phase uses FObjs to get properties and content from them to
calculate visual representation. Polluting FObj with link to LayoutManager
and Area classes would create a circular reference between FO Tree and
Layout phases and unnecessary coupling between them would be introduced.
So if the goal is to increase the aesthetics of code which creates area
objects in LM, the right place is LM itself:
Area LayoutManager.createArea(Class, FObj) {
return FObj.getUserAgent().getAreaFactory().create(Class, FObj, this);
}
and then:
curBlockArea = (Block)createArea(Block.class, fobj);
Best regards,
Tibor Vyletel
ICQ# 79458455
