Michael Wechner wrote:
Andreas Hartmann wrote:
Hi Lenya devs,
recently there was a discussion about the Creator interface
in 1.4. I guess some of you lost track, so I'd like to summarize
a question that IMO should be discussed:
Do we want to keep the Creator mechanism? An alternative would
be to handle specific creation mechanisms in usecases. The usecase
framework provides an easy-to-use approach for overriding usecases
in publications, as already used in the blog publication.
The basic question is if we need a configurable doctype-based
creation polymorphism. IMO we don't - it is not too hard to
implement something like that in a publication. This would be
more flexible, and would probably allow better mechanisms than
the current parameter map.
I agree that it's complicated at the moment and stuff grew historically.
Neverthless I still think we should offer some kind of "framework".
Can you explain a bit more what you have in mind?
First, some remarks about the problem:
Passing parameter maps is known as the MagicContainer antipattern, see
[1] for more explainations. It generally shouldn't be used for communication
in OO systems (see [2], Stamp/Data-structure Coupling).
What we want is a component which has a clear responsibility
(creating a document). But we can't find a reasonable interface,
because we don't know which data will be passed from the client
(create usecase) to the service (creator).
One solution is the strategy pattern [3], which would look like
this:
Creator creator = new MyDoctypeCreator(...);
creator.setThisAndThat(...);
documentManager.add(document, doctype, creator);
This way, we don't have to define a generic contract for setting up
the Creator object. The problem here is that we have to initialize the
creator object by hand and that we have to select the Creator class
manually.
I can see no solution for this problem. So I'd rather propose the
following design:
- A document is created in a generic way using DocumentManager.add().
If the doctype provides a sample, the sample is used.
If the doctype provides no sample, the contents of the document
is not initialized. This is fine for collections.
The Lenya-specific meta data are set.
- The client (create usecase) executes any non-generic initializations.
If someone needs a doctype-dependent initialization, it could be
implemented like this:
/**
* Template method to initialize the created document.
*/
public void initializeDocument(Document document) {
DocumentType doctype = document.getResourceType();
if (doctype.equals("frontpage")) {
...
}
else if (doctype.equals("dossier")) {
...
}
else if ...
}
I understand that this approach is not perfect, but I'd prefer it to
the parameter map.
But the problem is not critical or urgent, so we can discuss it and
wait until something better occurs to us.
-- Andreas
----------------------------------------------------------------
[1] http://www.c2.com/cgi/wiki?MagicContainer
[2] http://www.c2.com/cgi/wiki?CouplingAndCohesion
[3]
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
