> -----Original Message-----
> From: Tibor Vyletel [mailto:[EMAIL PROTECTED]


> 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?

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();


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,

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

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.



Reply via email to