Re: [xwiki-devs] UI extensions points VS ConfigurableClass (or any XObjects mechanism)

Hello developers. I send this e-mail because I want to talk about the concept of UIX when

comes to inject content in a application that has already a mechanism to append content. Use-case: being able to inject some content in an administration page. Example: I would like to write an extension that display some

on the "users" section of the administration. See the image: http://jira.xwiki.org/secure/attachment/32664/32664_example.png Currently, the only solution that I have is to overwrite XWiki.AdminUsersSheet which generate 2 problems: - it's a mess to maintain when XWiki is upgraded. - 2 different extensions cannot inject content in the same page (one will overwrite the other). Generally, we implement UI extension for this kind of problems, and that was my first intention. In the commit

(on a branch), I've introduced a UIX point on the top of the right side

the administration. It can display several ordered extensions. And it can be displayed in a particular section, or in all of them. The UI extension has the following benefits: - we can easily create extensions to inject content anywhere. - if the UIX is supposed to be injected in a particular section and if

section does not actually exists (for example: if it has a part of an optional application that is not installed), the UIX is simply not displayed. - the mechanism is already used in a lot of places and is well-known. But in this particular context, this solution has a drawback: it creates

kind of duplication with the ConfigurableClass mechanism that we use to display sections in the administration (

). So I've tried to create a ConfigurableClass object to implement my use-case. However, it has several issues: - if 2 XObjects define the same section in the administration, both of

are displayed but we cannot select the order. - one of the 2 xobjects is automatically added in a form, which is not

I want. According to the documentation: " codeToExecute is executed before the form is begun, however if you

multiple ConfigurableClass objects in the same application which are also shown in the same section of the administration application (perhaps with different headers) then codeToExecute of any ConfigurableClass object after the first will be executed inside of the form. " There is one image to show this: http://jira.xwiki.org/secure/attachment/32665/32665_problems.png The mechanism has also the following limitations: - there is no way to inject content in ALL the sections of the administration. - if you want to inject content in a section only if that section exists, you cannot. Because of the presence of your object, the section will be displayed all the time. This is bad if you want to inject some content in an optional application that might be or not installed. So I'm front of 2 possible implementations: - introduce the UIX anyway, with all it benefits. - improve the ConfigurableClass mechanism, with special attention to not break the backward compatibility (I think about the "codeToExecute" parameter). The first solution have my preference. Not only because it's easier to implement (see my patch), but also because of its benefits. Moreover, the use-case is NOT to create a section in the administration. It is only

INJECTING content on an existing section, and this is exactly the purpose of UIXs. I believe this debate exceeds this particular use-case, and that we might have the same question for any application that define some custom way to be modular. So I propose this rule: - it's OK to create a custom mechanism to *structure* a modular application. - it's OK to add some UIX points in it too when the goal is to be able to inject content in an existing section. But I find this definition quite imprecise. What do you think about this? For the record, this is the JIRA issue about this topic: http://jira.xwiki.org/browse/XWIKI-13494 Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs