24 Jan
2013
24 Jan
'13
6:47 p.m.
On 01/24/2013 12:39 PM, Marius Dumitru Florea wrote:
On Thu, Jan 24, 2013 at 5:31 PM, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
OK, I see, I thought it's the JS that processes the JSON returned by the
results.
Still, can't we append &bundle=xyz in the URL fetched? This means that
the l10n manager also enables bundles specified in the request.
The smelly part is that we have to manually push the bundle name around,
but I think it's not that bad, since it allows to decide when bundles
must be pushed, and doesn't add the requirement that users of the API
must remember to start and close sessions.
I dislike session-wide bundles since they can affect unrelated
resources, since they practically become globally enabled, so why not
just make them globally available from the start? Plus, when the
parallelism of AJAX comes into play, it gets hard to properly find the
end of the "session".
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:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> 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.
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. 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.
OK, let's explain for the third time :)
It's not about JavaScript code. It could be a problem in the future
but it's not a problem now. My problem is with the live table results
page (XWiki.LiveTableResults). The live table results need to be
translated sometimes, so I need the application document bundle to be
enabled when the live table requests its rows. The way to do this it
to either (1) have the document translation bundle enabled for a scope
(space, wiki, etc.) that includes the live table results page or (2)
demand the document translation bundle in the live table results page
(thus have a custom results page!). Thanks,
Marius
>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Marius
>>>
>>>>
>>>>>
>>>>> It would be intermediary between page and space scopes.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>
>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu