On 06/25/2012 02:44 PM, Guillaume Lerouge wrote:
Hi,
this looks like a lot of complex things to do for an result that will not
be user friendly.
First, I don't really thing we want users to put styles, links or wiki
macros in titles. The "Title" is just that, a pretty name for the page. I
don't know any web application that handles the title as anything else than
a simple, one-line-long input field. Handling it differently is going to
create a lot of confusion for users.
We could make entering the title mandatory to make sure there's always one,
and thus remove the need to compute it from the content of the page. If the
title is not given (due to a script creating a page), it could
automatically be filled with the page name when the page is created.
Second, applications that need it would be responsible to compute the right
title for any page based on data entered by the user and would feed it to
the title field upon saving the page.
That's not that easy like that, because it would mean duplicating the
data and keeping redundant data in sync. I think being able to reuse a
field with some velocity in the title is a good idea, especially now
when you can have a "sheet" for the title too (the new sheets mechanism
uses the title from the sheet and renders it in the context of the
document bound to that sheet).
I have seen it (your proposal) done a few times with a listener that is
responsible to keep data in sync, and it's not that right (let alone the
fact that duplicating data is not a good idea). What is important though
is to judge correctly if the title needs to be in a property of the
class and reused or if it should be put directly in the display title of
the document. This is a relevant issue in this direction
http://jira.xwiki.org/browse/XWIKI-7369 as, once fixed, it will show
application creators that there already is a pretty name for a document
and that they can use it to put data in (along with
http://jira.xwiki.org/browse/XWIKI-7905 which will actually allow people
to use this title as part of the structured document metadata).
Third, we already have a mechanism to handle internationalized content in
wiki pages - the translations of that page in other languages when in
multilingual mode.
I think too that the i18n of titles should also be approached from this
side: maybe we can do something about i18n in general which will allow
easier internationalization of titles, instead of changing the titles to
accomodate easier calls to $msg.get() (since we would need to blow a bit
the dust off the i18n module as well :) ).
Thanks,
Anca
Right now, it feels like we're about to try to implement something very
complex for the sake of making developer's live a bit easier, while at the
same time sacrificing ease-of-use in a very big way. This is not something
that I feel will benefit XWiki in the long run, whether for users or for
devs.
If we want to change the way the title works, I'd like us to *start with a
list of use cases* and see *how the proposed solution impacts them and
makes them better.*
Thanks,
Guillaume
On Mon, Jun 25, 2012 at 1:01 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
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).
2 typical cases:
1/ you have a text in a property in an object in the document and you want
that text to be displayed as the document title. For various reasons, this
text cannot be in the document title field itself or in the document name
(it's not unique, it's not short enough, the text is actually part of the
type structure and the structure would be incomplete if you put the data in
the title since title is not semantic (it just means document title it
doesn't mean "frequently asked question" in a FAQ application, for example
), you don't want to duplicate texts (once in a prop once in the title), in
enough cases it's wrongly used by devs that don't think about using titles
and re-add a property -- also because http://jira.xwiki.org/browse/**
XWIKI-7905 <http://jira.xwiki.org/browse/XWIKI-7905> --, etc)
2/ indeed you want to decorate the title: e.g. for the search, you want to
display the searched word in the title; you have a page with scripted
content that lists all documents for a tag, or for some property, you want
the title to be different depending on what that tag is or the property
Also:
3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we
need them to provide nice things and we want these nice things. Not having
them will not stop from providing nice things, it will only lead to hacking
it: customizing .vms to hide the title and then putting it with hacked html
and css from the document content (i've seen it done), or even customizing
it directly in the .vm.
As I said in one of my previous mails, I think it's only for devs, a lot
less for users. So we don't need to show it, for the users the title should
stay simple, but all these things need to stay possible since otherwise
everybody will customize by its own mean, more or less correct, in 80% of
cases (for devs, I repeat).
Thanks,
Anca
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>
<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>
<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>
<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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
