On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
> On 06/25/2012 10:59 AM, Eduard Moraru wrote:
>
>> Hi,
>>
>> On Mon, Jun 25, 2012 at 10: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 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.
>>
>
> 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.
>
>
Can you please give me some examples where this feature is essential to the
functionality/user experience of an application? (also please see my reply
to Thomas' comment).
Thanks,
Eduard
>
>
>> 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
>>> [email protected]
>>> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>>>
>>> ______________________________**_________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>>
>
>
> ______________________________**_________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
