On 06/25/2012 09:52 AM, Thomas Mortagne 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.
I don't like this idea at all, not because of the APIs, but because we
already have document name and document title between which users/devs
don't really understand/know how to manage the difference , I don't
think we should have another field (which will be there for quite some
versions and then we'll have issues when we'll want to remove it, etc).
I think I prefer some migration issues than this.
Anca
<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
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
