On Sep 11, 2008, at 9:23 AM, Ludovic Dubost wrote:
The big issue I see is that we want to maintain compatibility of the
current core apis:
Document.getComments()
CommentAddAction
These are the only two places where we have calls to comments in the
core, and except for comment delete, the standard comment features
only
use these two APIs (my prototype works the way I did it currently).
It would be great if somebody could look at the XWiki core patch
http://svn.xwiki.org/svnroot/xwiki/sandbox/plugins/comments/src/main/java/c…
Here is a piece of code for example using the plugin mecanism
+ public Vector<BaseObject> getComments(boolean asc, XWikiContext
context) throws CommentsException
+ {
+ CommentsPlugin commentsPlugin = (CommentsPlugin)
context.getWiki().getPlugin("comments", context);
+ if (commentsPlugin!=null) {
+ List<Comment> commentList =
commentsPlugin.getComments(this, asc, context);
+ if (commentList==null)
+ return null;
+ Vector<BaseObject> commentVector = new
Vector<BaseObject>();
+ for (int i=0;i<commentList.size();i++) {
+ Comment comment = (Comment) commentList.get(0);
+ BaseObject object = new BaseObject();
+ object.setNumber(i);
+ object.setClassName("XWiki.XWikiComments");
+ object.setStringValue("author", comment.getAuthor());
+ object.setLargeStringValue("content",
comment.getContent());
+ object.setName(getFullName());
+ object.setDateValue("date", comment.getDate());
+ commentVector.add(object);
+ }
+ return commentVector;
But I have the feeling it should be directly a component and not the
plugin.
But either way I cannot call the getComments from the plugin or the
component if I don't have an interface to it in the core.
You have an interface to it available since the comment module jar
would be in the classpath and thus the xwiki-core jar will be able to
"see" the interface and use it.
Basically instead of getPlugin, you'd use
Utils.getComponent(CommentManager.ROLE) where CommentManager is an
interface located in the comment jar.
That's unless you want to do it in 2 steps and have the comments
module in the core for now and move it to an application module later
on when we have this notion of Interface Extensions and super-XAR. It
might be easier and better for now since the component modules we have
now are all "clean" 'i.e. no direct dependencies on xwiki-core except
through the xwiki-bridge module. So if you go the route of using xwiki-
bridge then it's fine, otherwise you could put it in core in a
separate comment package for now.
Thanks
-Vincent
Vincent Massol wrote:
> Hi Ludovic,
>
> On Sep 10, 2008, at 11:45 AM, Ludovic Dubost wrote:
>
>
>> Hi devs,
>>
>> I'm working currently on the new comments and ratings plugins. The
>> objective is to allow to separate the comment code from the core to
>> allow different implementation which can be:
>>
>> - comments as objects to the page (the current implementation)
>> - comments as separate pages
>> - ratings separated from comments
>> - comments and ratings merged
>>
>> We have code in the sandbox
>>
http://svn.xwiki.org/svnroot/xwiki/sandbox/plugins/comments/src/main/java/c…
>>
>> There is a patch for the core to call the comments code in the
>> sandbox also.
>>
>> Now we have currently used a plugin oriented entry point which calls
>> a CommentsManager which is a separate module. It does not seem very
>> practical to call the plugin from the core. I've been thinking that
>> it would be better to make the CommentsManager a component, with the
>> interface in the core, and separate the implementations in a
>> comments component in the xwiki-core-comments. The approach would be
>> similar to Artem's approach on the query plugin.
>>
>
> I haven't reviewed yet but if the interface is located in the core
> then there's a problem I think.
>
>
>> Then we would use a velocity bridge to expose the comments to the
>> velocity scripting.
>>
>> Is that the right approach ?
>>
>
> Here's the vision:
> * This feature should be in a separate "application", i.e. a separate
> build module
> * It should use interface extension to plugin into the UI
> * In the further future, it would be a single XAR containing both
> xwiki pages and jars. Right now it probably means splitting this
> "application" module into 2 modules: one for the UI and one for
> business logic
> * The business logic should be implemented using components
> * The component interfaces must be located in the the business logic
> module (and not in the core core).
> * The component should use the xwiki-bridge module to bridge between
> the old architecture and the new one.
> * The Velocity bridge mechanism we have discussed and agree on in
> some
> other thread should be used (
http://tinyurl.com/5c4wa2). Note that
> it's not available yet. Sergiu was working on making this possible by
> making components of the velocity module uberspectors but he's had to
> spend some time on some research project with StephaneL so this has
> been delayed a bit. It should be there in the coming 2-3 weeks. Right
> now if you really need it in Velocity you can put the component in
> the
> Velocity context directly in the DefaultVelocityManager.java class
>
>
>> Is there documentation to help me achieve this ?
>>
>
> For components:
> *
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HCompone…
> * and existing code
>
>
>> Can some of our core devs looks at the comments code and provide
>> some feedback to improve this. I think we can improve it
>> significantly.
>> We need comments and ratings as separate pages pretty quickly so we
>> need feedback very soon to be able to take it into account.
>>
>
> Can someone do that. I don't have time right now. I'm on a very very
> tight schedule for the new rendering.
>
> Thanks
> -Vincent