Re: [xwiki-devs] Evolution of the Blog Application

Hi. The Blog Application is one of our main applications. It has been fully written in Velocity, so that even users who don't have programing rights can install it on their wiki. However, I am currently working on XWIKI-13861 [1]. It is about marking the blog documents as hidden when they are not "published" so that visitors won't find them by mistake with the search engine. To accomplish it, I've created a listener that change the document visibility when a blog post is saved. To implement this listener, we have 2 options, with both benefits and drawbacks: A: Write the listener with Java and introduce an xwiki-platform-blog-api module. =========================================================== Pros: * It follows our Best Practices. * We use a nice and powerful language: Java. Cons: * It make the Blog Application dependent to a Java Module, so the wiki administrator needs the PR to install it if the JAR is not already installed in the WAR. * Note that this JAR would be bundled in the XE's WAR while the Blog Application is part of the main wiki flavor, so XE users won't see the change right now. B: Write the listener with Groovy directly on a wiki page. ========================================== Pros: * Blog Application remains a full XAR extension that you can install without PR, as it has always been. Cons: * We need to use the groovy macro, which is not consistent with our Best Practices. * We need a bit of plumbing to register the listener (what we really need is to be able to write listeners easily with an XObject). * If the user has not the PR, the listener will not be registered, so the new behavior introduced by XWIKI-13861 won't be applied. It's a kind of nice degradation but we need to explain it to the user, which will be technical and not user-friendly (we already have lacks on this domain). C: Don't write a listener, but make all changes in Velocity ========================================= Pros: * It remains a full XAR extension. * No degradation Cons: * We need to make the business logic of hiding the blog document in a velocity service and in the blog post sheet. * It is less safe than the listener because a user can still change the "hidden" and the "published" values of the XObjects and bypass the synchronization. * We cannot write an automatic migrator that would be executed only on wiki events. Conclusion ======== My preference goes to A, because: * I don't really like the degradation principle for technical reasons that the user might not understand. * It's simple & safe. * If I would have written the Blog App myself, I would have made a Script Service in Java to put the business logic away from Velocity. * We have plenty of extensions having Java modules. A better approach would be to authorize the installation of approved and/or signed modules even when the admin has not the programming right. Since we need a collegial decision, I am asking you your opinion :) Thanks, [1] http://jira.xwiki.org/browse/XWIKI-13861