Hi,
For ConfigurableClass, I`m not sure UIXP are a solution, since we would
have to add one UIXP for each thing we want to do (top, bottom, in
between?, etc.). Since ConfigurableClass already defines sections, it would
just be a matter of extending it to also introduce order in those sections.
Additionally, we can have an option that says add this section only if
others already exist (so that it alone will not trigger the entry to be
displayed) and, of course, we can have some flags on how it should be
displayed (if it should include the title or not, i.e. the "Unexpected"
part from
).
Specifically about the users limitations, I believe that it could be
included as a feature of the Users module itself (to display the current
users limit status, if any limit is set).
About generically extending existing administration sections, I believe
that we should keep using ConfigurableClass (and extending it to fit all
our needs) instead of mixing too many concepts.
UIXPs should be used mostly for the skin, IMO, while applications can
define their own, specialized, customization/extensibility mechanisms.
Thanks,
Eduard
On Tue, Jun 28, 2016 at 1:22 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> 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) <valicac(a)gmail.com>om>:
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 <
guillaume.delhumeau(a)xwiki.com> 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/374903eea354db2d25b6541f8fd7…
(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+Applica…
).
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 (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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
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