On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'm generally +1 for wiki content everywhere possible. Note that this is not going to be a smooth migration since a lot of titles contains velocity in XE for example and in most application in general.
* Make the title field a textarea so that we can have more than 1 line * Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field
Would be nice to support that for object fields too.
* Stop trying to extract title content from the doc content
Big +1 as I always been. But not sure it's the same subject. We can do that whatever is the decision for the rest especially since we already voted it once...
* Have a backward compat param to still support the old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk about compat param. It's going to be more a switch since you can't really have both old velocity based content and generic wiki content at the same time. That makes this parameter pretty much unsuable IMO (either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that could produce but worth mentioning) could be to add a new field (something like "titleContent") which would be wiki based and deprecated "title" field which keep working the same way. When the compatibility parameter is enabled, fallback on "title" when "titleContent" is empty. We could enable it by default in 4.2 and disable it in 4.3. At least this system makes easier to have both modes working together.
<side> * Introduce a {{i18n}} macro (or {{translate}}, or …) </side>
Not critical but yes we are using $msg.get a lot in our applications titles at least so would be nice to have a pure wiki replacement since it's a bit more painful to have to write {{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language * Removes the WTF symptom when a user edits a page having velocity script in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
+1 to do this change when possible but I don't have much idea to make
Was "I don't have much idea to make the migration easier" but forgot to remove it after the titeContent suggestion.
Another idea would be to add a migration script that would wrap current titles with {{velocity}}…{{/velocity}} if we detect $msg for example. Thanks -Vincent