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

[Guillaume Delhumeau]

I go with Option A.

Thanks,

2016-11-17 16:24 GMT+01:00 Sergiu Dumitriu :

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



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Sergiu Dumitriu]

+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

[xwiki-devs] Evolution of the Blog Application

[Guillaume Delhumeau]

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

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs