Vincent Massol wrote:
> On Mar 9, 2009, at 12:26 PM, Dan Miron wrote:
>
>> Sergiu Dumitriu wrote:
>>> Vincent Massol wrote:
>>>
>>>> Hi,
>>>>
>>>> Some time ago we agreed that component implementations should be
>>>> located in the internal package. I now believe it's wrong if we want
>>>> to allow users to use our modules separately from the rest of
>>>> XWiki as
>>>> standard java beans. I think it's a good property to have that users
>>>> can integrate our modules into their own code without taking the
>>>> whole
>>>> of XWiki. This is what I'm trying to do with the rendering module.
>>>>
>>>> Thus I'm proposing to move the components out of the internal module
>>>> *only* for the rendering module for now even though I suspect that
>>>> we'll want to do that for all modules eventually.
>>>>
>>>> Here's my +1
>>>>
>>>>
>>> What's the advantage? Or, what's wrong with keeping the internal
>>> package? Apart from a longer package name, there's no bound
>>> semantics on
>>> such a package. IMO it even has the advantage that it clearly
>>> delimits
>>> interfaces and abstract base classes from implementations.
>>>
>>>
>> I agree to Sergiu. Keeping the implementation and the specifications
>> separately provides more accuracy to our api.
>
> The only possibility to keep our "component" implementation classes
> non user-public is to add user-public factory classes.
>
> ParserFactory parserFactory = new DefaultParserFactory();
> Parser parser = parserFactory.createParser(new
> XWikiSyntax(SyntaxType.XWIKI, "2.0"));
> parser.parse(new StringReader("**whatever**");
> ...
>
> instead of:
>
> Parser parser = new WikiModelXWikiParser(...);
> parser.parse(new StringReader("**whatever**");
> ...
>
> Note that these factory classes will need to have user-public
> implementations of course so this is swapping one problem for another
> (albeit smaller). Also, it means that we have an extra class that is
> useless when using components.
>
> Now while this works quite well for parsers since there are different
> implementations for them, it's going to be a real pita for most other
> components which have only a default implementation. For example, I
> don't see us writing:
>
> TransformationManagerFactory transformationManagerFactory = new
> DefaultTransformationManagerFactory();
> TransformationManager transformationManager =
> transformationManagerFactory.createTransformationManager();
> transformationManager.performTransformations(...);
>
> instead of:
>
> TransformationManager transformationManager = new
> DefaultTransformationManager();
> transformationManager.performTransformations(...);
>
> Now the first one to suggest using singleton pattern and statics gets
> a blame... :)
>
> WDYT?
Vincent, I don't understand what's the problem with keeping the package
name as it is now? There's nothing that prevents users (API users) to
instantiate classes in the internal package. The only thing that changes
is the import statement, the same constructor can be used. And with
modern development tools the package is transparent.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
