Template support for Live Data's new row creation

Development
1

Hi everyone,

This proposal is a follow-up to Live Data's entry creation save behavior, focusing on template support (including default values) as mentioned in Loading....

As a reminder, once Loading... is merged, a new row in edit mode stays a draft until it receives an edit, which then creates the entry.

With a template, the draft would simply start pre-filled: the source exposes the template’s values in the addEntry action (as it already does for the location), and the preview action is called with the template parameter. Pre-filled values don’t count as an edit, so “Add entry” keeps having no side effect, and on creation the template is actually applied server-side and merges the values received from the user.

While this behavior is straightforward, there are a few questions left:

1. What should we use as a template?

  1. A template provider, for AWM, we currently have template providers (XWiki.TemplateProviderClass): a provider references a template document, and can also define where to store pages (more on that in section 3).
  2. Default values in the Live Data configuration: a defaultValue parameter on the property descriptors (next to the new mandatory flag), set in the JSON content of the Live Data macro. Unlike templates, it doesn’t depend on the source, so it would work for any Live Data.

I’d go with 1: it reuses an existing mechanism and also works well as a livetable replacement for AWM. Note that the two aren’t mutually exclusive; it’s definitely possible to have the two mechanisms later on.

2. How should the user configure the template?

This only really applies if we go with option 1 of section 1.

  1. Explicit only: a newRowTemplateProvider source parameter, like newRowLocation.
  2. Implicit only: always use the class’s template provider following AWM’s naming convention (the class name with Class replaced by TemplateProvider), without any parameter. AWM applications would get their template without any configuration. However, there would be no way to use another template, or disable it (unless we add a disableTemplateProvider option).
  3. Explicit, with an implicit default: a newRowTemplateProvider source parameter, falling back on the provider from 2 when it isn’t set.

I lean towards 3, which would also allow disabling the template by providing an explicitly empty newRowTemplateProvider parameter.

3. Where should the entries be created?

Again, this only really applies if we go with option 1 of section 1.
Besides the template, the provider’s creationRestrictions may contain a location for new entries. In AWM, the entry is then named after what the user typed, which is also used as its title. On the Live Data side, this is currently the job of the naming strategy (newRowNamingStrategy, with newRowLocation), so the two overlap:

  1. Independent: the template only provides default values, and the naming strategy and newRowLocation stay required and unchanged.
  2. A new template strategy: if used, we basically follow AWM’s convention: location if present in the template, current space if empty, and use the title as page name (so, same as Loading...).
  3. Implicit AWM logic: AWM’s convention applies automatically, without any naming strategy.

I lean towards 2: it adds the most flexibility while still supporting AWM with a simple setting.

What do you think? Don’t hesitate to add anything I might have missed.

Thanks.

2

Thanks for the proposal @pjeanjean

+1 for 1 as long as LD is not tightly coupled to AWM in the implementation.
+0 for 2, I would only implement it later

+1 for 3

+1 for 2 but you confirm that the AWM template strategy will only be used when the template is an AWM one?

3

It depends on what you see as a AWM template, I would expect it to also work with TemplateProviderClass instances created manually for example.

But if we have other kinds of templates later one, the logic would probably need to be tied to the template mechanism. It would not change the strategy name, though: always template, no matter which kind.

4

You mean a new live table source parameter? I see newRowLocation is indeed documented for the live table source https://www.xwiki.org/xwiki/bin/view/documentation/xs/user/livedata/display-data/sources/ . I don’t think we have generic live data source parameters, that any source can implement. This newRowTemplateProvider wouldn’t be generic anyway, as it can be implemented only by live data sources that are backed by a xclass.

I suppose this is fine for now, but I think it would be interesting to think about how new row creation / template can be implemented in a generic way that could be used by any live data source. Option 2 goes in this direction. The code that resolves the live data configuration (based on the source) can fill the defaultValue based on the newRowTemplateProvider specified as source parameter.

If our main focus is the live table (xlcass-based) source, and AWM compatibility, then implementing 1/1, 2/3 and 3/2 makes sense indeed.

Thanks,
Marius

5

Yes, it would be a source parameter here.

6

Thanks for your feedback, while digging into the implementation we noticed a small issue: XWiki.TemplateProviderClass is currently defined in xwiki-platform-administration-ui. The livetable source for Live Data has to rely on it, but it can’t depend
on administration-ui, since administration-ui already depends on xwiki-platform-livedata-livetable.

So I propose to finally implement Loading..., as a separate PR:

  • A new xwiki-platform-templateprovider module:
    • -api: the class, now defined in Java (mandatory class initializer), plus a small @Unstable TemplateProviderManager to read a
      provider (template, terminal, creation restrictions).
    • -ui: TemplateProviderSheet, TemplateProviderMacros, TemplateProviderTemplate and the translations, all keeping their current
      references.
    • -test: the page objects and functional tests that aren’t specific to the administration.
  • The “Templates” administration section stays in administration-ui, which depends on the new -ui.
  • No migration needed: the XAR upgrade doesn’t delete pages handled by a mandatory initializer. We already did the same for
    ResetPasswordRequestClass and PanelClass.
  • Modules that only needed administration-ui for template providers (AWM) depend on the new module instead. Modules that ship providers get
    an explicit dependency on it.
  • The template provider code in oldcore (create action) is unchanged for now.

WDYT?

Thanks.

7

+1 to extract the template provider code in a separate module.