25 Jun
2012
25 Jun
'12
10:55 a.m.
On 06/25/2012 09:52 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
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
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
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs