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/xwik... [2] http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core/apidocs/com/xpn/xwi... On Wed, Mar 14, 2012 at 1:36 PM, Denis Gervalle <[email protected]> wrote:

+1

On Wed, Mar 14, 2012 at 08:16, Marius Dumitru Florea < [email protected]> wrote:

...

+1

Thanks, Marius

On Tue, Mar 13, 2012 at 6:35 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

I'd like to propose adding a module named xwiki-platform-component-script in xwiki-platform. It would allow a script to get access to the Component Manager (for now, we can imagine other apis later on).

The idea is to replace the ugly static and "deprecated": com.xpn….Util.getComponentManager()

Of course the script Service will check for Programming Rights before giving back a CM instance.

This follows the strategy of offering script services for each module.

Here's my +1

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Eddy, On Mar 15, 2012, at 1:50 AM, Eduard Moraru wrote:

On Thu, Mar 15, 2012 at 2:27 AM, Eduard Moraru <[email protected]> wrote:

...

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.

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)).

...

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?

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).

...

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.

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.

Since I am not very familiar with Groovy, I assume you are referring to using "services.component.getComponent(x)" instead of "Utils.getComponent(x)" or "Utils.getComponentManager()" in Groovy. That would probably be better, but again, the service will be available to all scripting languages and my initial question remains.

Yes that's the idea (that it's available to all script languages) :) Thanks -Vincent

...

Am I missing something?

Thanks, Eduard

---------- [1] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... [2] http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core/apidocs/com/xpn/xwi...

On Wed, Mar 14, 2012 at 1:36 PM, Denis Gervalle <[email protected]> wrote:

...

+1

On Wed, Mar 14, 2012 at 08:16, Marius Dumitru Florea < [email protected]> wrote:

...

+1

Thanks, Marius

On Tue, Mar 13, 2012 at 6:35 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

I'd like to propose adding a module named xwiki-platform-component-script in xwiki-platform. It would allow a script to get access to the Component Manager (for now, we can imagine other apis later on).

The idea is to replace the ugly static and "deprecated": com.xpn….Util.getComponentManager()

Of course the script Service will check for Programming Rights before giving back a CM instance.

This follows the strategy of offering script services for each module.

Here's my +1

Thanks -Vincent