2 Aug
2013
2 Aug
'13
8:22 p.m.
Hello,
This is no particular issue I'm addressing here, just wanted to get
possibly some feedbacks on the app I'm developing, considering virtual
mode. Also not from a technical point of view (though it's impacting of
course), more on best way to make use of XWiki.
It's for the Mail Archive :)
Currently I provide components and 1 UI, to administrate, operate (email
loading) and navigate (livetables, stats) a Mail Archive.
Focusing on UI, the whole app is inside xwiki-contrib-mailarchive-ui.
The use-case I would like to allow/improve, is of someone wanting to create
"isolate" different mail archives / mailing-lists in different subwikis.
The first thing I did (and that works), is duplicate the whole app in each
sub-wiki (after fixing some issues caused by being in a sub-wiki).
My next move would be to separate the administration:
xwiki-contrib-mailarchive-admin-ui
xwiki-contrib-mailarchive-ui
The idea would be to install admin/operate part once for all, and install
the "navigation" app in each needed sub-wiki.
To allow that, "navigation" xar cannot depend on "admin" (or it would
install "admin" everywhere), and "admin" could depend on
"navigation", for
the unique wiki use-case.
Means that it's the admin that should be installed in mono-wiki mode, and
this is a bit weird I think for users. Or I could say that both should be
installed, up to you to decide where you install what (but logically you
install "admin" in main wiki and "navigation" in main or sub-
wiki(s)).
Of course the concept is that the "administration" UI takes into account
the possibility of wanting to use multiple sub-wikis, and allows the user
defining what is the destination of created mails pages for each
mailing-list (ie, the main wiki, or a specific sub-wiki).
Then there's the case of all the XClass pages.
Because they are needed for the "navigation" (along with Sheets and so on),
but to restrict number of pages created, it would seem good to create those
once for all in the main wiki, and just "use" them from the sub-wikis mail
archive pages (home, topic, mail, ...).
Doing that, the "navigation" app would be very minimal (not much more than
a home page in fact).
To simplify I could add them to the "admin" app, but what I do not like is
that logically they are not part of the admin. In fact they could be seen
as a third UI, a technical one, dedicated to "wiki-storage-mapping" (sorry
for that name, hope you get the point, if you're still reading this).
Logically both "admin" and "navigation" should have a dependency on
"storage", but to follow primary optimization purpose only "admin"
should
mark this dependency.
So:
"admin" --> "navigation"
"admin" --> "storage"
WDYT ? (apart from, "this mail is way too long").
I'm asking, because I'm not sure I'm taking it the right way. I'm also
not
sure, if following this I'm not going to create some coding hell :)
(another topic for me would be to plug my admin part into the xwiki admin
UI, but I'm also afraid of the amount of work...)
Thanks,
Jeremie
3 Aug
3 Aug
5:17 p.m.
New subject: [xwiki-devs] Considerations on application development in multi-wiki mode
Hi Jeremie,
On Fri, Aug 2, 2013 at 9:22 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com
wrote:
Hello,
This is no particular issue I'm addressing here, just wanted to get
possibly some feedbacks on the app I'm developing, considering virtual
mode. Also not from a technical point of view (though it's impacting of
course), more on best way to make use of XWiki.
It's for the Mail Archive :)
Currently I provide components and 1 UI, to administrate, operate (email
loading) and navigate (livetables, stats) a Mail Archive.
Focusing on UI, the whole app is inside xwiki-contrib-mailarchive-ui.
The use-case I would like to allow/improve, is of someone wanting to create
"isolate" different mail archives / mailing-lists in different subwikis.
The first thing I did (and that works), is duplicate the whole app in each
sub-wiki (after fixing some issues caused by being in a sub-wiki).
My next move would be to separate the administration:
xwiki-contrib-mailarchive-admin-ui
xwiki-contrib-mailarchive-ui
The idea would be to install admin/operate part once for all, and install
the "navigation" app in each needed sub-wiki.
To allow that, "navigation" xar cannot depend on "admin" (or it
would
install "admin" everywhere), and "admin" could depend on
"navigation", for
the unique wiki use-case.
Means that it's the admin that should be installed in mono-wiki mode, and
this is a bit weird I think for users. Or I could say that both should be
installed, up to you to decide where you install what (but logically you
install "admin" in main wiki and "navigation" in main or sub-
wiki(s)).
Of course the concept is that the "administration" UI takes into account
the possibility of wanting to use multiple sub-wikis, and allows the user
defining what is the destination of created mails pages for each
mailing-list (ie, the main wiki, or a specific sub-wiki).
Then there's the case of all the XClass pages.
Because they are needed for the "navigation" (along with Sheets and so on),
but to restrict number of pages created, it would seem good to create those
once for all in the main wiki, and just "use" them from the sub-wikis mail
archive pages (home, topic, mail, ...).
Doing that, the "navigation" app would be very minimal (not much more than
a home page in fact).
Some time ago, I also felt like doing what you describe here. However,
there are 2 things to consider:
1) AFAIK, you are not able to instantiate XClasses cross-wiki. In other
words, objects are only allowed to use classes that are located in the
current wiki and not in a separate one. Trying to pass (programmatically,
because AFAIK there is no UI for this) an XClass reference that comes from
a different wiki will result in the attempt to use the class from the
current wiki (the wiki prefix is trimmed). You can also see this in the
code [1].
2) For cases where it matters if the application runs in a subwiki or in
the main wiki, you generally write one single UI that does a couple of IFs
to check if it's the main wiki or a subwiki and display the corresponding
UI. You install the entire application on *each* wiki. There is no need to
separate your app into 2 UIs just for this.
[1]
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
To simplify I could add them to the "admin"
app, but what I do not like is
that logically they are not part of the admin. In fact they could be seen
as a third UI, a technical one, dedicated to "wiki-storage-mapping" (sorry
for that name, hope you get the point, if you're still reading this).
Logically both "admin" and "navigation" should have a dependency on
"storage", but to follow primary optimization purpose only "admin"
should
mark this dependency.
So:
"admin" --> "navigation"
"admin" --> "storage"
WDYT ? (apart from, "this mail is way too long").
I'm asking, because I'm not sure I'm taking it the right way. I'm also
not
sure, if following this I'm not going to create some coding hell :)
(another topic for me would be to plug my admin part into the xwiki admin
UI, but I'm also afraid of the amount of work...
Use the ConfigurableClass so that you app shows up in the "Applications"
section in Administration. Generally this should be preffered instead of
forking (and maintaining the form later on) the Admin UI.
Hope this helps,
Eduard
)
Thanks,
Jeremie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Aug
5 Aug
9:56 a.m.
On Aug 3, 2013, at 5:17 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi Jeremie,
On Fri, Aug 2, 2013 at 9:22 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com
Correct.
wrote:
Hello,
This is no particular issue I'm addressing here, just wanted to get
possibly some feedbacks on the app I'm developing, considering virtual
mode. Also not from a technical point of view (though it's impacting of
course), more on best way to make use of XWiki.
It's for the Mail Archive :)
Currently I provide components and 1 UI, to administrate, operate (email
loading) and navigate (livetables, stats) a Mail Archive.
Focusing on UI, the whole app is inside xwiki-contrib-mailarchive-ui.
The use-case I would like to allow/improve, is of someone wanting to create
"isolate" different mail archives / mailing-lists in different subwikis.
The first thing I did (and that works), is duplicate the whole app in each
sub-wiki (after fixing some issues caused by being in a sub-wiki).
My next move would be to separate the administration:
xwiki-contrib-mailarchive-admin-ui
xwiki-contrib-mailarchive-ui
The idea would be to install admin/operate part once for all, and install
the "navigation" app in each needed sub-wiki.
To allow that, "navigation" xar cannot depend on "admin" (or it
would
install "admin" everywhere), and "admin" could depend on
"navigation", for
the unique wiki use-case.
Means that it's the admin that should be installed in mono-wiki mode, and
this is a bit weird I think for users. Or I could say that both should be
installed, up to you to decide where you install what (but logically you
install "admin" in main wiki and "navigation" in main or sub-
wiki(s)).
Of course the concept is that the "administration" UI takes into account
the possibility of wanting to use multiple sub-wikis, and allows the user
defining what is the destination of created mails pages for each
mailing-list (ie, the main wiki, or a specific sub-wiki).
Then there's the case of all the XClass pages.
Because they are needed for the "navigation" (along with Sheets and so on),
but to restrict number of pages created, it would seem good to create those
once for all in the main wiki, and just "use" them from the sub-wikis mail
archive pages (home, topic, mail, ...).
Doing that, the "navigation" app would be very minimal (not much more than
a home page in fact).
Some time ago, I also felt like doing what you describe here. However,
there are 2 things to consider:
1) AFAIK, you are not able to instantiate XClasses cross-wiki. In other
words, objects are only allowed to use classes that are located in the
current wiki and not in a separate one. Trying to pass (programmatically,
because AFAIK there is no UI for this) an XClass reference that comes from
a different wiki will result in the attempt to use the class from the
current wiki (the wiki prefix is trimmed). You can also see this in the
code [1].
2) For cases where it matters if the application runs in a subwiki or in
the main wiki, you generally write one single UI that does a couple of IFs
to check if it's the main wiki or a subwiki and display the corresponding
UI. You install the entire application on *each* wiki. There is no need to
separate your app into 2 UIs just for this.
I agree too.
[1]
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
Yup, that's pretty simple (just know that you won't have PR there).
Thanks
-Vincent
To simplify I could add them to the
"admin" app, but what I do not like is
that logically they are not part of the admin. In fact they could be seen
as a third UI, a technical one, dedicated to "wiki-storage-mapping" (sorry
for that name, hope you get the point, if you're still reading this).
Logically both "admin" and "navigation" should have a dependency on
"storage", but to follow primary optimization purpose only "admin"
should
mark this dependency.
So:
"admin" --> "navigation"
"admin" --> "storage"
WDYT ? (apart from, "this mail is way too long").
I'm asking, because I'm not sure I'm taking it the right way. I'm also
not
sure, if following this I'm not going to create some coding hell :)
(another topic for me would be to plug my admin part into the xwiki admin
UI, but I'm also afraid of the amount of work...
Use the ConfigurableClass so that you app shows up in the "Applications"
section in Administration. Generally this should be preffered instead of
forking (and maintaining the form later on) the Admin UI. Hope this helps,
Eduard
> )
>
> Thanks,
> Jeremie
10:15 a.m.
New subject: [xwiki-devs] Considerations on application development in multi-wiki mode
Le 5 août 2013 09:56, "Vincent Massol" <vincent(a)massol.net> a écrit :
Correct.
> In other
> words, objects are only allowed to use classes that are located in the
> current wiki and not in a separate one. Trying to pass (programmatically,
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
Yup, that's pretty simple (just know that you won't have PR there).
That's exactly what I just realized... And was about to ask, so thanks for
anticipation ;)
Unfortunately I currently use PR in the admin (some full form queries),
I'll have to check if I can remove that need.
BTW a way to workaround PR is to use display macro - in my case it doesn't
help.
On Aug 3, 2013, at 5:17 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
> Hi Jeremie,
>
> On Fri, Aug 2, 2013 at 9:22 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com
>> wrote:
>
>> Hello,
>>
>> This is no particular issue I'm addressing here, just wanted to get
>> possibly some feedbacks on the app I'm developing, considering virtual
>> mode. Also not from a technical point of view (though it's impacting of
>> course), more on best way to make use of XWiki.
>>
>> It's for the Mail Archive :)
>>
>> Currently I provide components and 1 UI, to administrate, operate
(email
>> loading) and navigate (livetables, stats) a
Mail Archive.
>> Focusing on UI, the whole app is inside xwiki-contrib-mailarchive-ui.
>>
>> The use-case I would like to allow/improve, is of someone wanting to
create
>> "isolate" different mail archives /
mailing-lists in different
subwikis.
>> The first thing I did (and that works), is
duplicate the whole app in
each
>> sub-wiki (after fixing some issues caused by
being in a sub-wiki).
>>
>> My next move would be to separate the administration:
>> xwiki-contrib-mailarchive-admin-ui
>> xwiki-contrib-mailarchive-ui
>>
>> The idea would be to install admin/operate part once for all, and
install
>> the "navigation" app in each needed
sub-wiki.
>> To allow that, "navigation" xar cannot depend on "admin" (or
it would
>> install "admin" everywhere), and "admin" could depend on
"navigation",
for
>> the unique wiki use-case.
>> Means that it's the admin that should be installed in mono-wiki mode,
and
>> this is a bit weird I think for users. Or I
could say that both should
be
>> installed, up to you to decide where you
install what (but logically
you
>> install "admin" in main wiki and
"navigation" in main or sub- wiki(s)).
>>
>> Of course the concept is that the "administration" UI takes into
account
>> the possibility of wanting to use multiple
sub-wikis, and allows the
user
>> defining what is the destination of created
mails pages for each
>> mailing-list (ie, the main wiki, or a specific sub-wiki).
>>
>> Then there's the case of all the XClass pages.
>> Because they are needed for the "navigation" (along with Sheets and so
on),
>> but to restrict number of pages created, it
would seem good to create
those
>> once for all in the main wiki, and just
"use" them from the sub-wikis
mail
>> archive pages (home, topic, mail, ...).
>> Doing that, the "navigation" app would be very minimal (not much more
than
a home page in fact).
Some time ago, I also felt like doing what you describe here. However,
there are 2 things to consider:
1) AFAIK, you are not able to instantiate XClasses cross-wiki. > because AFAIK there is no UI for this) an XClass
reference that comes
from
> a different wiki will result in the attempt to
use the class from the
> current wiki (the wiki prefix is trimmed). You can also see this in the
> code [1].
> 2) For cases where it matters if the application runs in a subwiki or in
> the main wiki, you generally write one single UI that does a couple of
IFs
> to check if it's the main wiki or a subwiki
and display the
corresponding
> UI. You install the entire application on *each*
wiki. There is no need
to
separate your
app into 2 UIs just for this.
I agree too.
> [1]
>
>
>
>> To simplify I could add them to the "admin" app, but what I do not
like is
>> that logically they are not part of the
admin. In fact they could be
seen
>> as a third UI, a technical one, dedicated to
"wiki-storage-mapping"
(sorry
>> for that name, hope you get the point, if
you're still reading this).
>> Logically both "admin" and "navigation" should have a
dependency on
>> "storage", but to follow primary optimization purpose only
"admin"
should
>> mark this dependency.
>> So:
>> "admin" --> "navigation"
>> "admin" --> "storage"
>>
>>
>> WDYT ? (apart from, "this mail is way too long").
>>
>> I'm asking, because I'm not sure I'm taking it the right way.
I'm also
not
>> sure, if following this I'm not going to
create some coding hell :)
>> (another topic for me would be to plug my admin part into the xwiki
admin
UI, but I'm also afraid of the amount of work...
Use the ConfigurableClass so that you app shows up in the "Applications"
section in Administration. Generally this should be preffered instead of
forking (and maintaining the form later on) the Admin UI.
Thanks
-Vincent
Hope this helps,
Eduard
> )
>
> Thanks,
> Jeremie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:35 p.m.
New subject: [xwiki-devs] Considerations on application development in multi-wiki mode
On Mon, Aug 5, 2013 at 11:15 AM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
Le 5 août 2013 09:56, "Vincent Massol"
<vincent(a)massol.net> a écrit :
Correct.
> In other
> words, objects are only allowed to use classes that are located in the
> current wiki and not in a separate one. Trying to pass (programmatically,
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
That's exactly what I just realized... And was about to ask, so thanks for
anticipation ;)
Unfortunately I currently use PR in the admin (some full form queries),
I'll have to check if I can remove that need.
BTW a way to workaround PR is to use display macro - in my case it doesn't
help.
Why not? Why do you need the current $doc?
If you need XWikiPreferences you can just call it explicitly. The display
macro (actually include macro with context='new') is what I used for the
Search application (XWiki.SearchAdmin) and it worked like a charm.
Thanks,
Eduard
On Aug 3, 2013, at 5:17 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
> Hi Jeremie,
>
> On Fri, Aug 2, 2013 at 9:22 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com
>> wrote:
>
>> Hello,
>>
>> This is no particular issue I'm addressing here, just wanted to get
>> possibly some feedbacks on the app I'm developing, considering virtual
>> mode. Also not from a technical point of view (though it's impacting
of
>> course), more on best way to make use of
XWiki.
>>
>> It's for the Mail Archive :)
>>
>> Currently I provide components and 1 UI, to administrate, operate
(email
>> loading) and navigate (livetables,
stats) a Mail Archive.
>> Focusing on UI, the whole app is inside xwiki-contrib-mailarchive-ui.
>>
>> The use-case I would like to allow/improve, is of someone wanting to
create
>> "isolate" different mail
archives / mailing-lists in different
subwikis.
>> The first thing I did (and that works),
is duplicate the whole app in
each
>> sub-wiki (after fixing some issues
caused by being in a sub-wiki).
>>
>> My next move would be to separate the administration:
>> xwiki-contrib-mailarchive-admin-ui
>> xwiki-contrib-mailarchive-ui
>>
>> The idea would be to install admin/operate part once for all, and
install
>> the "navigation" app in each
needed sub-wiki.
>> To allow that, "navigation" xar cannot depend on "admin" (or
it would
>> install "admin" everywhere), and "admin" could depend on
"navigation",
for
>> the unique wiki use-case.
>> Means that it's the admin that should be installed in mono-wiki mode,
and
>> this is a bit weird I think for users.
Or I could say that both should
be
>> installed, up to you to decide where you
install what (but logically
you
>> install "admin" in main wiki
and "navigation" in main or sub-
wiki(s)).
>>
>> Of course the concept is that the "administration" UI takes into
account
>> the possibility of wanting to use
multiple sub-wikis, and allows the
user
>> defining what is the destination of
created mails pages for each
>> mailing-list (ie, the main wiki, or a specific sub-wiki).
>>
>> Then there's the case of all the XClass pages.
>> Because they are needed for the "navigation" (along with Sheets and so
on),
>> but to restrict number of pages created,
it would seem good to create
those
>> once for all in the main wiki, and just
"use" them from the sub-wikis
mail
>> archive pages (home, topic, mail, ...).
>> Doing that, the "navigation" app would be very minimal (not much more
than
a home page in fact).
Some time ago, I also felt like doing what you describe here. However,
there are 2 things to consider:
1) AFAIK, you are not able to instantiate XClasses cross-wiki. > because AFAIK there is no UI for this) an
XClass reference that comes
from
> a different wiki will result in the attempt
to use the class from the
> current wiki (the wiki prefix is trimmed). You can also see this in the
> code [1].
> 2) For cases where it matters if the application runs in a subwiki or
in
> the main wiki, you generally write one
single UI that does a couple of
IFs
> to check if it's the main wiki or a
subwiki and display the
corresponding
> UI. You install the entire application on
*each* wiki. There is no need
to
separate
your app into 2 UIs just for this.
I agree too.
> [1]
> >
>
>> To simplify I could add them to the "admin" app, but what I do not
like is
>> that logically they are not part of the
admin. In fact they could be
seen
>> as a third UI, a technical one,
dedicated to "wiki-storage-mapping"
(sorry
>> for that name, hope you get the point,
if you're still reading this).
>> Logically both "admin" and "navigation" should have a
dependency on
>> "storage", but to follow primary optimization purpose only
"admin"
should
>> mark this dependency.
>> So:
>> "admin" --> "navigation"
>> "admin" --> "storage"
>>
>>
>> WDYT ? (apart from, "this mail is way too long").
>>
>> I'm asking, because I'm not sure I'm taking it the right way.
I'm also
not
>> sure, if following this I'm not
going to create some coding hell :)
>> (another topic for me would be to plug my admin part into the xwiki
admin
>> UI, but I'm also afraid of the
amount of work...
>
>
> Use the ConfigurableClass so that you app shows up in the
"Applications"
> section in Administration. Generally this
should be preffered instead
of
forking
(and maintaining the form later on) the Admin UI.
Yup, that's pretty simple (just know that you won't have PR there).
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hope this helps,
Eduard
> )
>
> Thanks,
> Jeremie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:38 p.m.
New subject: [xwiki-devs] Considerations on application development in multi-wiki mode
Le 5 août 2013 20:35, "Eduard Moraru" <enygma2002(a)gmail.com> a écrit :
Because I show some Modal windows that I want to redirect to the admin page
- but you're right I could have done like you say.
Eventually I easily changed my code so I don't need PR, so well I'll leave
it like that unless I need PR for good :)
So it's quite nice now with its own section in admin UI :)
On Mon, Aug 5, 2013 at 11:15 AM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
> Le 5 août 2013 09:56, "Vincent Massol" <vincent(a)massol.net> a écrit
:
> >
> >
> > On Aug 3, 2013, at 5:17 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
> >
> > > Hi Jeremie,
> > >
> > > On Fri, Aug 2, 2013 at 9:22 PM, Jeremie BOUSQUET <
> jeremie.bousquet(a)gmail.com
> > >> wrote:
> > >
> > >> Hello,
> > >>
> > >> This is no particular issue I'm addressing here, just wanted to
get
> > >> possibly some feedbacks on the app I'm developing, considering
virtual
> > >> mode. Also not from a technical
point of view (though it's
impacting
> of
> > >> course), more on best way to make use of XWiki.
> > >>
> > >> It's for the Mail Archive :)
> > >>
> > >> Currently I provide components and 1 UI, to administrate, operate
> (email
> > >> loading) and navigate (livetables, stats) a Mail Archive.
> > >> Focusing on UI, the whole app is inside
xwiki-contrib-mailarchive-ui.
> > >>
> > >> The use-case I would like to allow/improve, is of someone wanting
to
> create
> > >> "isolate" different mail archives / mailing-lists in
different
> subwikis.
> > >> The first thing I did (and that works), is duplicate the whole app
in
> each
> > >> sub-wiki (after fixing some issues caused by being in a sub-wiki).
> > >>
> > >> My next move would be to separate the administration:
> > >> xwiki-contrib-mailarchive-admin-ui
> > >> xwiki-contrib-mailarchive-ui
> > >>
> > >> The idea would be to install admin/operate part once for all, and
> install
> > >> the "navigation" app in each needed sub-wiki.
> > >> To allow that, "navigation" xar cannot depend on
"admin" (or it
would
> > >> install "admin"
everywhere), and "admin" could depend on
"navigation",
> for
> > >> the unique wiki use-case.
> > >> Means that it's the admin that should be installed in mono-wiki
mode,
> and
> > >> this is a bit weird I think for users. Or I could say that both
should
> be
> > >> installed, up to you to decide where you install what (but
logically
> you
> > >> install "admin" in main wiki and "navigation" in
main or sub-
> wiki(s)).
> > >>
> > >> Of course the concept is that the "administration" UI takes
into
> account
> > >> the possibility of wanting to use multiple sub-wikis, and allows
the
> user
> > >> defining what is the destination of created mails pages for each
> > >> mailing-list (ie, the main wiki, or a specific sub-wiki).
> > >>
> > >> Then there's the case of all the XClass pages.
> > >> Because they are needed for the "navigation" (along with
Sheets
and so
> on),
> > >> but to restrict number of pages created, it would seem good to
create
> those
> > >> once for all in the main wiki, and just "use" them from the
sub-wikis
> mail
> > >> archive pages (home, topic, mail, ...).
> > >> Doing that, the "navigation" app would be very minimal (not
much
more
> than
> > >> a home page in fact).
> > >>
> > >
> > > Some time ago, I also felt like doing what you describe here.
However,
> > > there are 2 things to consider:
> > > 1) AFAIK, you are not able to instantiate XClasses cross-wiki.
> >
> > Correct.
> >
> > > In other
> > > words, objects are only allowed to use classes that are located in
the
> > > current wiki and not in a separate one.
Trying to pass
> (programmatically,
> > > because AFAIK there is no UI for this) an XClass reference that
comes
> from
> > > a different wiki will result in the attempt to use the class from
the
> > > current wiki (the wiki prefix is
trimmed). You can also see this in
the
> > > code [1].
> > > 2) For cases where it matters if the application runs in a subwiki
or
> in
> > > the main wiki, you generally write one single UI that does a couple
of
> IFs
> > > to check if it's the main wiki or a subwiki and display the
> corresponding
> > > UI. You install the entire application on *each* wiki. There is no
need
> to
> > > separate your app into 2 UIs just for this.
> >
> > I agree too.
> >
> > > [1]
> > >
>
>
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
> > >
> > >
> > >> To simplify I could add them to the "admin" app, but what I
do not
> like is
> > >> that logically they are not part of the admin. In fact they could
be
> seen
> > >> as a third UI, a technical one, dedicated to
"wiki-storage-mapping"
> (sorry
> > >> for that name, hope you get the point, if you're still reading
this).
> > >> Logically both "admin"
and "navigation" should have a dependency on
> > >> "storage", but to follow primary optimization purpose only
"admin"
> should
> > >> mark this dependency.
> > >> So:
> > >> "admin" --> "navigation"
> > >> "admin" --> "storage"
> > >>
> > >>
> > >> WDYT ? (apart from, "this mail is way too long").
> > >>
> > >> I'm asking, because I'm not sure I'm taking it the right
way. I'm
also
> not
> > >> sure, if following this I'm not going to create some coding hell
:)
> > >> (another topic for me would be to plug my admin part into the xwiki
> admin
> > >> UI, but I'm also afraid of the amount of work...
> > >
> > >
> > > Use the ConfigurableClass so that you app shows up in the
> "Applications"
> > > section in Administration. Generally this should be preffered
instead
> of
> > > forking (and maintaining the form later on) the Admin UI.
> >
> > Yup, that's pretty simple (just know that you won't have PR there).
>
> That's exactly what I just realized... And was about to ask, so thanks
for
> anticipation ;)
> Unfortunately I currently use PR in the admin (some full form queries),
> I'll have to check if I can remove that need.
> BTW a way to workaround PR is to use display macro - in my case it
doesn't
help.
Why not? Why do you need the current $doc?
If you need XWikiPreferences you can just call it explicitly. The display
macro (actually include macro with context='new') is what I used for the
Search application (XWiki.SearchAdmin) and it worked like a charm.
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hope this helps,
Eduard
> )
>
> Thanks,
> Jeremie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4060
days inactive
4063
days old
5 comments
3 participants
participants (3)
-
Eduard Moraru -
Jeremie BOUSQUET -
Vincent Massol