5 Aug
2013
5 Aug
'13
10:38 p.m.
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