[1.4] Creator interface (was: Re: [1.4] DocumentManager.add())

[Andreas Hartmann <an...@apache.org>]

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.

The default publication does not need creation polymorphism, neither
does the blog publication. IMO the Creator concept should be abolished
in favor of custom publication-specific solutions. It adds complexity
without generating a reasonable benefit.

Or is there another concept that could supersede the Creator without
the parameter map?

WDYT?

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [1.4] Creator interface (was: Re: [1.4] DocumentManager.add())

["Gregor J. Rothfuss" <gr...@apache.org>]

Michael Wechner wrote:

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

+1

doctypes can be wildly different, and there is no way to anticipate 
method signatures to cover all doctypes beyond the useless array of 
parameters we have today



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [1.4] Creator interface

["J. Wolfgang Kaltz" <jw...@apache.org>]

Michael Wechner schrieb:
> 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".

IIUC the question is this:
should Lenya provide, in its core, a doctype-specific mechanism for 
creating documents of this doctype ? Or, should the core mechanism be 
publication-wide; meaning the default mechanism is the same for all 
documents in a publication, regardless of its doctype ?

What we now have is this:
the doctype configuration specifies which class is used to create a 
document of this type. In default & blog pubs, the way they are now in 
the Lenya source base, this feature is not used: the types in default 
use one class, the type in blog uses another; so the knowledge of how 
documents are created is (de facto) publication-wide, and not doctype 
specific.

Has anybody using Lenya implemented a doctype which requires another 
creation mechanism than another doctype in the same publication ? Or, 
can anybody come up with a meaningful scenario where this would be needed ?

I can't think of such a scenario right now :) Furthermore, the current 
framework is actually dangerous, which I painfully found out last week. 
The way document ids are mapped to Lenya paths is defined as a 
publication-wide mechanism (configured in publication.xconf); but if the 
individual document creator specifies an id creation mechanism which is 
different from what is expected for the publication (this was the case 
in blog), you have an incompatibility between the publication and some 
or all of its documents.

Plus, I agree with Andreas' comments re. the magic parameter map being 
passed through now, being suboptimal.

So, unless somebody comes up with scenarios where doctype-specific 
creation is required, here is my
+1 to completely remove the doctype creator and move any knowledge 
currently there to publication code.

What exactly "publication code" means is then a subject of debate ;) We 
can put this knowledge in the usecases as Andreas pointed out, which are 
already pub-specific. Or maybe we can provide some smarter mechanism, 
configured via the publication.xconf, to reduce the amount of code in 
the individual usecases.


--
Wolfgang

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [1.4] Creator interface (was: Re: [1.4] DocumentManager.add())

[Andreas Hartmann <an...@apache.org>]

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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [1.4] Creator interface (was: Re: [1.4] DocumentManager.add())

[Michael Wechner <mi...@wyona.com>]

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?

Thanks

Michi


-- 
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org