In your UIX definition you would have an IF putting its content only if the page is XWikiPreference with the Users section.
Thanks, Caty On Tue, Jun 28, 2016 at 1:22 PM, Guillaume Delhumeau < [email protected]> wrote: > This UIXP could be useful, but I think that it is too much for my use-case. > That would be a shame to try to display it in every page when we only need > it in a single one! > > 2016-06-28 12:05 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>: > > > Hi, > > > > I propose you a third solution: > > Implement the "Content Title - After" UIXP, see > > http://jira.xwiki.org/browse/XWIKI-13080 > > > > For your particular use case it's exactly what you need. You can use CSS > > then to make sure you display your content right floated and with the > width > > of your second administration column. > > > > The after title is a generic UIXP that could be used in multiple cases. > > > > Thanks, > > Caty > > > > On Tue, Jun 28, 2016 at 12:45 PM, Guillaume Delhumeau < > > [email protected]> wrote: > > > > > Hello developers. > > > > > > I send this e-mail because I want to talk about the concept of UIX when > > it > > > 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 > > informations > > > 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 > > > > > > > > > https://github.com/xwiki/xwiki-platform/commit/374903eea354db2d25b6541f8fd7106c45fae29f#diff-0 > > > (on a branch), I've introduced a UIX point on the top of the right side > > of > > > 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 > > that > > > 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 > > a > > > kind of duplication with the ConfigurableClass mechanism that we use to > > > display sections in the administration ( > > > > > > > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Application#HMakingyourapplicationconfigurablewithConfigurableClass > > > ). > > > > > > 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 > > them > > > are displayed but we cannot select the order. > > > - one of the 2 xobjects is automatically added in a form, which is not > > what > > > I want. > > > > > > According to the documentation: > > > " codeToExecute is executed before the form is begun, however if you > > have > > > 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 > > about > > > 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 ([email protected]) > > > Research & Development Engineer at XWiki SAS > > > Committer on the XWiki.org project > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
