Hi,
On Mon, Jun 25, 2012 at 12:21 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
wrote:
> On Mon, Jun 25, 2012 at 10:59 AM, Eduard Moraru <enygma2002(a)gmail.com>
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.
>
> As I said it's far from being only about translations, most
> applications insert something coming from an object or generated some
> other way in the title which identify the current element (blog post
> title, application name, wiki identifier, etc.).
>
Would you consider that the programatically added information to the title
(by adding stuff like "Edit blog post 'My vacation'", "Edit
application 'My
App'", etc...) would be of great value to the user? Why not just use a
simple "Edit blog post", "Edit application", etc. for title? You can
further identify the current item inside the content if you really want to.
I don`t see this as vital development resource and see it rather as a
"bells and whistles" element that brings more problems than it solved.
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) 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs