On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
> Hi,
>
> On Mon, Jun 25, 2012 at 10: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 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) will be displayed, which sounds good to me.
>
> So I would be +1, considering the comment above (restricted use of macros).
Consistency *is* simplicity:
* No new concept to learn for users (same tools, same concept to edit title and
content)
* Same security model so that's safe. Which isn't the case when you start doing
custom stuff as you suggest
Being a web dev platform, the title really must be programmable too (which it
is already but in a custom way, not using the same code than the content is
using hence maintenance and security issues).
Thanks
-Vincent
>> * 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@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
