+1 for moving even more of the functionality in Java, not just this listener.
On 11/17/2016 07:00 AM, Guillaume Delhumeau wrote: > 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 > -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
