25 Jun
2012
25 Jun
'12
12:19 p.m.
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)massol.net> wrote:
As Thomas said, there are cases when something else is used (with
velocity code, yes). Now this something else might indeed be only 10% of
the cases, but we should still keep it possible. Not show it in the UI
because 90% of the people don't care about it, but still keep it possible.
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 am not a big fan of seeing code (of any kind) in titles. IMO, it is bad
practice and we should discourage people from doing it. You have lots of
problems when some application lists the titles of pages with code in their
title or, worse, when the application tries to render those titles. You
have all sorts of security issues and generally bad things when the writer
of that title does not assume that it is going to be rendered outside his
page. I know it is a cool feature, but it is causing too much headache to
handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we
need translation keys. We could very well have a filtered wiki syntax, that
allows only calls to the new {{translation}} macro.
An alternative to people that *really* want to generate their title trough
a script is to actually keep the title extraction from the document content
and make them have to generate a <h1> element from the content, not from
the title. This means that they have to leave the actual title empty for
the extraction to be triggered and, if I am not mistaken, applications that
want to list document titles can use
api.Document.gerRenderedTitle(document.syntax.toIdString()) (as they
probably did before) and the first heading (that is either static or
programmatically generated)
No, not programatically generated. Last time I checked, title
extraction tool was not evaluating scripts.
Also this extraction thing is really crap because it's hard to use: it
uses a hack to not display the title twice, which is to search for the
h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not
displayed. This makes it terribly painful to re-use those title and
content somewhere else since you don't know if you'll have 2 titles or
just one (in a pdf export, for example).
Thanks,
Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* 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
* Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support
the old mode, but have it
off by default in 4.2/4.3
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* 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?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs