24 Jan
2013
24 Jan
'13
9:44 a.m.
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
ah ok, got it!
So what we would need ideally is a Session scope which would be explicitly
started/stopped. It would mean storing the CM data either in the application context or in
the HTTP Session (probably better since it can expire even if the code forgets to close
the session explicitly).
I'd say both are valid, the Session is a little bit cleaner I feel but possibly
slightly more complex to use for a small advantage.
Thanks
-Vincent
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol
<vincent(a)massol.net> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to
choose between using the document translation bundle on demand (only
when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a
custom live table results page just to demand the translation bundle
when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special
rights to register a document translation bundle on the entire wiki. A
simple user creating an application with AWM won't have the
application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space'
scope. Space (application) scope makes a lot of sense in my case and
I'm wondering if it's hard to implement it. Note that I already make
the application creator an admin of the application space, so
requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live
table results page or
(2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now
for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All
you need is to have translations available for the generate application's home page
(where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a
full request. I guess it should not be that hard to implement either. We could just save
the list of components registered for that request in the execution context. You are just describing what on demand means and
it's what Marius is using.
And which doesn't work for live tables because the live table rows are
retrieved in separate (AJAX) requests and thus you need a custom live
table results page if you need to "demand" the document translation
bundle on those requests too. Thanks,
Marius
>
>>
>> It would be intermediary between page and space scopes.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent