While I would be tempted to say +1 for easier access to components, I tend to also notice that this would invite people (including us) in avoiding to write the heavy code in Java and use Velocity instead. There would be almost no motivation to write a script service and the core/component code that we`ll end up executing from velocity will no longer have the checks that the *.api/script service methods had, knowing that they were called from userspace. So this would respect the strategy of offering a script service for the component module, but since the component module is the gateway to all the others, there will no longer be an incentive to respect this strategy for all other (future) modules. While I know that anyone can write a script service that just exposes the component manager, I think my questions is whether or not it is ethical for us to do so by default. Also, if it *is* ethical, then why haven't we done this before? Regarding the old com.xpn.xwiki.web.Utils.getComponentManager() method [1] (which targets non-componentized Java code), I don`t understand what is its relation with the issue at hand, namely Velocity a the proposed new component script service. As far as I know, you can not currently access components from Velocity and the current $util [2] velocity tool points to com.xpn.xwiki.api.Util (not com.xpn.xwiki.web.Utils) which has no such method. Am I missing something? Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… [2] http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core/apidocs/com/xpn/xw… On Wed, Mar 14, 2012 at 1:36 PM, Denis Gervalle <dgl(a)softec.lu> wrote:

Hi Eddy, On Mar 15, 2012, at 1:50 AM, Eduard Moraru wrote: Yes you're right. But there are 2 separate aspects: 1) The programming platform 2) Best practices I agree that in general it's not a best practice. But similarly it's not a general good practice to use the velocity macro (or any scripting macro) to put code in wiki pages, especially if the code has business logic in it. However XWiki is a generic development platform and we must absolutely provide this. And it's very useful when you do some proof of concept dev or if you do throwaway dev. The only case when it's not a best practice is when code something that has to be maintained and supported on a long period. So we need it for 1) and we should ourselves avoid using it (that's 2)). We have :) It's Utils.getComponentManager and Utils.getComponent()... And we do use this from time to time. I know I've used it several times. One of them was when I wrote the IRCBot application fully in wiki pages (no java code). Point 1: - The idea is that all our apis should be available from *all* script languages. It's a bug when something isn't accessible from a given script language. We must give users the freedom to choose the language they prefer to use. - The only consideration we should take into account is security. We shouldn't introduce something that is dangerous security-wise which is why we need to check PR in this case. Point 2: - Scripts should only use Script Services to access backend APIs and using a static variable is a very bad practice and something temporary that we had to do to bridge old code that are not using components with component code. One day we will remove this static since it's bad and won't be needed anymore. We definitely don't want scripts to be using that static access because it makes it a de facto API and thus makes it hard to remove. We need ASAP to have wiki pages use a proper Script Service instead. Yes that's the idea (that it's available to all script languages) :) Thanks -Vincent