On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
> On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne
> <thomas.morta...@xwiki.com> wrote:
>> On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <vinc...@massol.net> 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
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
