25 Jun
2012
25 Jun
'12
12:39 p.m.
Hi,
On Mon, Jun 25, 2012 at 12:14 PM, Vincent Massol <vincent(a)massol.net> wrote:
Yes, but we don`t currently rush to automatically render any object inside
the page just because they can write wiki syntax/scripts in it, do we? :)
. Even the doc content can be thought as a metadata. It's not because it's
On Jun 25, 2012, at 11:10 AM, Vincent Massol wrote:
Do you consider the current titles "safe"?
Even when they are listed by an external application? Specially when that
application knows that it can have velocity in the titles, so it calls
getRenderedTitle to display a pretty string instead of ugly velocity, but,
at the same time, it can get a $doc.delete() call or whatever boobytrap
that could be lying inside some misguided document title?
On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
> Hi,
>
> On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)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).
BTW I agree about it not being easy to have dynamic title, ie value that
change depending on the context…
But I don't see many other solution and generating title in content is not
so nice IMO.
If you think about it the title is a metadata like any other XObject you
add to a page (and they are dynamic and can contain wiki syntax/scripts) harder for it to be dynamic that we shouldn't do
it (otherwise we'll just
be a static web site generation tool ;)).
That's not the point. My issue with the title is that it is (almost) always
exposed to the outside, having an impact outside of its originating
document. You can`t really say that about a document's content. You're
pretty sure that a document content will be rendered inside the document
itself. If someone decides to render it some other place, then it's bad
practice or it's a sheet, both cases being OK from our POV.
I think we are (already) giving too much credit (and power) to a document's
title, but that's just my opinion.
Thanks,
Eduard
Thanks
-Vincent
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs