24 Jan
2013
24 Jan
'13
4:31 p.m.
On 01/24/2013 03:44 AM, Vincent Massol wrote:
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
This looks like a bit of overkill to me.
The way it's been done for ColorThemes, for example, is to pass the
current theme name in the ssx.use call. We could do the same, explicitly
in the AWM generated homepages:
$xwiki.jsx.use('livetable', {'bundle': currentAppBundleName})
Another option is to redesign how JS L10N works. Currently we're
including translations in the JS file, by parsing $msg.get calls in the
JS source. Most of the other libraries use a separate resource file and
dynamic calls to interpolate strings.
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. 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
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu
Thanks,
Marius
>
>>
>> It would be intermediary between page and space scopes.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent