25 Jun
2012
25 Jun
'12
9:24 a.m.
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
* 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
* 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 …)
</side>
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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
25 Jun
25 Jun
9:52 a.m.
On Mon, Jun 25, 2012 at 9: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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice to support that for object fields too.
* Stop trying to extract title content from the doc
content
Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support the
old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9:54 a.m.
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Was "I don't have much idea to make the migration easier" but forgot
to remove it after the titeContent suggestion.
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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice to support that for object fields too.
* Stop trying to extract title content from the
doc content
Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support
the old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:34 a.m.
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Another idea would be to add a migration script that would wrap current titles with
{{velocity}}…{{/velocity}} if we detect $msg for example.
Thanks
-Vincent
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Was "I don't have much idea to make the migration easier" but forgot
to remove it after the titeContent suggestion. 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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice to support that for object fields too.
* Stop trying to extract title content from the
doc content
Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support
the old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
10:36 a.m.
On Jun 25, 2012, at 10:34 AM, Vincent Massol wrote:
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
Another option is to write a script that would get the title rendered and the title raw
content and compare them for each page. If they are different wrap the raw title content
in {{velocity}}…{{/velocity}}.
Thanks
-Vincent
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Another idea would be to add a migration script that would wrap current titles with
{{velocity}}…{{/velocity}} if we detect $msg for example. On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Was "I don't have much idea to make the migration easier" but forgot
to remove it after the titeContent suggestion. 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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice to support that for object fields too.
* Stop trying to extract title content from the
doc content
Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support
the old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
10:39 a.m.
On Mon, Jun 25, 2012 at 10:34 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
It's not only about translations, many applications extract whatever
is the current entity name from its object to put it in the title.
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Another idea would be to add a migration script that would wrap current titles with
{{velocity}}…{{/velocity}} if we detect $msg for example. On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Was "I don't have much idea to make the migration easier" but forgot
to remove it after the titeContent suggestion. 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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice to support that for object fields too.
* Stop trying to extract title content from the
doc content
Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support
the old mode, but have it off by default in 4.2/4.3
If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:55 a.m.
On 06/25/2012 09:52 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't like this idea at all, not because of the APIs, but because we
already have document name and document title between which users/devs
don't really understand/know how to manage the difference , I don't
think we should have another field (which will be there for quite some
versions and then we'll have issues when we'll want to remove it, etc).
I think I prefer some migration issues than this.
Anca
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'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.
* 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
Would be nice
to support that for object fields too.
* Stop trying to extract title content from the
doc content
Big +1 as I always been. But not sure it's the same subject. We can
do
that whatever is the decision for the rest especially since we already
voted it once...
* Have a backward compat param to still support
the old mode, but have it off by default in 4.2/4.3
If by old mode you mean
velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).
Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like "titleContent") which would be wiki based and
deprecated "title" field which keep working the same way. When the
compatibility parameter is enabled, fallback on "title" when
"titleContent" is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together. <side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Not critical but yes we are using $msg.get a lot in our
applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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?
+1 to do this change when possible but I don't have much idea to make
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:51 a.m.
On 06/25/2012 09:24 AM, Vincent Massol 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
it's interesting if we have an i18n macro... for the rest of the
formatting I'm not sure... I don't know if formatting in titles is used
that often
* Make the title field a textarea so that we can have
more than 1 line
big +1, not for the lines, but for the size (255 becomes quickly
too small)
* 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
more or less, I think we should keep it simple for the titles: no
wysiwyg editor, no textarea, just as it was until now, except that longer.
* Stop trying to extract title content from the doc
content
* Have a backward compat param to still support the old mode, but have it off by default
in 4.2/4.3
This is interesting too, but I don't have a strong opinion, although
not
extracting titles anymore would be wonderful :) .
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
+1
I think we should also have a discussion about the purpose of the title
(now that we can put anything in document name) and how titles should be
used by default by the platform, but I need to clear the ideas a bit in
my head before starting it.
Thanks,
Anca
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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
11:03 a.m.
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
On 06/25/2012 09:24 AM, Vincent Massol wrote:
I really think we need wysiwyg, same as for content because it's wiki syntax. Could
you explain your rationale for not having wiki syntax in the title field?
Also not having wysiwyg will not remove the WTF effect we currently have, see
http://markmail.org/thread/jwbbz4ypjqcpwral
Thanks
-Vincent
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
it's interesting if we have an i18n macro... for the rest of the
formatting I'm not sure... I don't know if formatting in titles is used that
often
* Make the title field a textarea so that we can
have more than 1 line
big +1, not for the lines, but for the size (255 becomes
quickly too small)
* 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
more or less, I think we should keep it simple for the
titles: no wysiwyg editor, no textarea, just as it was until now, except that longer.
* Stop trying
to extract title content from the doc content
* Have a backward compat param to still support the old mode, but have it off by default
in 4.2/4.3
This is interesting too, but I don't have a strong opinion, although
not extracting titles anymore would be wonderful :) .
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
+1
I think we should also have a discussion about the purpose of the title (now that we can
put anything in document name) and how titles should be used by default by the platform,
but I need to clear the ideas a bit in my head before starting it.
Thanks,
Anca
>
> Advantages:
> * Same as the content field - More consistency
> * More power since we use wiki syntax and we can use any script language
> * 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
12:40 p.m.
On 06/25/2012 11:03 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
This is a technical argument. If 80% of the people in 80% of the cases
don't need / care about formatting titles (putting bold, italic, wiki
macros, links, images and other stuff in the titles) then we should not
put it only because it's possible (and yes, sure, consistent with the
implementation!). 80% (*) of the people will want to set a text and will
see this whole sofisticated thing with links, images, macros which will
generate a WTF and a feeling of overdone.
(*) I might be wrong on the numbers, my feeling is that 80% expect
simple text for the title, but we can research, if you want.
On 06/25/2012 09:24 AM, Vincent Massol wrote:
I really think we need wysiwyg, same as for content because it's wiki syntax.
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
it's interesting if we have an i18n macro... for the rest of the
formatting I'm not sure... I don't know if formatting in titles is used that
often
* Make the title field a textarea so that we can
have more than 1 line
big +1, not for the lines, but for the size (255 becomes
quickly too small)
* 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
more or less, I think we should keep it simple for the
titles: no wysiwyg editor, no textarea, just as it was until now, except that longer.
Could you explain your rationale for not having wiki
syntax in the title field?
? have I ever said that?
We can have it, but we should not show it because people don't use it
and can create confusion. Now, the problem if we don't show it is that
people will put ** and other wiki syntax which will get interpreted and
they won't understand why.
Also not having wysiwyg will not remove the WTF effect we currently have, see
http://markmail.org/thread/jwbbz4ypjqcpwral
We could have another solution for that besides a fully fledged wysiwyg.
Note that I am only against about a fully fledged wysiwyg. If we find
some other visual solution (e.g. as Jerome suggested) I have nothing
against, I'm just saying that title should stay simple and the wysiwyg
is not simple (if only for the fact that it has 2 rows of buttons!).
For translations though, if a wiki is put in multilanguage mode and you
make a translation of the document, you can translate the title, IIRC.
So aren't only the application developers concerned about the
translations of the titles? (because they script the pages and they
don't want to make 3 translations only to provide the title in a
different language). Because if it's the case, it's also the situation
for the velocity titles, so there is no need to show these "features" to
regular users, we just need to make a better (easier to customize)
default xar. Maybe distribute language by language instead of all in one
pack?
Actually, this is another interesting question: do users actually use
translations for document titles, or the pb is only when they want to
customize the default xar?
Thanks,
Anca
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
* Stop
trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but have it off by default
in 4.2/4.3
This is interesting too, but I don't have a strong opinion, although
not extracting titles anymore would be wonderful :) .
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
+1
I think we should also have a discussion about the purpose of the title (now that we can
put anything in document name) and how titles should be used by default by the platform,
but I need to clear the ideas a bit in my head before starting it.
Thanks,
Anca
> Advantages:
> * Same as the content field - More consistency
> * More power since we use wiki syntax and we can use any script language
> * 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
3:20 p.m.
On 06/25/2012 12:40 PM, Anca Luca wrote:
On 06/25/2012 11:03 AM, Vincent Massol wrote:
Another idea I just had is to modify the import/xar install tool to
allow to choose the languages to import. Thus each document will contain
text where it has to contain text (instead of msg.get) and users can
choose on import which languages they want to import, depending on their
wikis.
Anca
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
This is a technical argument. If 80% of the people in 80% of the cases
don't need / care about formatting titles (putting bold, italic, wiki
macros, links, images and other stuff in the titles) then we should
not put it only because it's possible (and yes, sure, consistent with
the implementation!). 80% (*) of the people will want to set a text
and will see this whole sofisticated thing with links, images, macros
which will generate a WTF and a feeling of overdone.
(*) I might be wrong on the numbers, my feeling is that 80% expect
simple text for the title, but we can research, if you want.
On 06/25/2012 09:24 AM, Vincent Massol wrote:
I really think we need wysiwyg, same as for content because it's wiki
syntax. 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
it's interesting if we have an i18n macro...
for the rest of the
formatting I'm not sure... I don't know if formatting in titles is
used that often
* Make the title field a textarea so that we can
have more than 1 line
big +1, not for the lines, but for the size (255 becomes
quickly too
small)
* 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
more or less, I think we should keep it simple for the
titles: no
wysiwyg editor, no textarea, just as it was until now, except that
longer. Could you explain your rationale for not having
wiki syntax in the
title field?
? have I ever said that?
We can have it, but we should not show it because people don't use it
and can create confusion. Now, the problem if we don't show it is that
people will put ** and other wiki syntax which will get interpreted
and they won't understand why.
Also not having wysiwyg will not remove the WTF effect we currently
have, see http://markmail.org/thread/jwbbz4ypjqcpwral
We could have another solution for that besides a fully fledged
wysiwyg. Note that I am only against about a fully fledged wysiwyg. If
we find some other visual solution (e.g. as Jerome suggested) I have
nothing against, I'm just saying that title should stay simple and the
wysiwyg is not simple (if only for the fact that it has 2 rows of
buttons!).
For translations though, if a wiki is put in multilanguage mode and
you make a translation of the document, you can translate the title,
IIRC. So aren't only the application developers concerned about the
translations of the titles? (because they script the pages and they
don't want to make 3 translations only to provide the title in a
different language). Because if it's the case, it's also the situation
for the velocity titles, so there is no need to show these "features"
to regular users, we just need to make a better (easier to customize)
default xar. Maybe distribute language by language instead of all in
one pack?
Actually, this is another interesting question: do users actually use
translations for document titles, or the pb is only when they want to
customize the default xar?
Thanks,
Anca
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
* Stop
trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but
have it off by default in 4.2/4.3
This is interesting too, but I don't have a
strong opinion, although
not extracting titles anymore would be wonderful :) .
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
+1
I think we should also have a discussion about the purpose of the
title (now that we can put anything in document name) and how titles
should be used by default by the platform, but I need to clear the
ideas a bit in my head before starting it.
Thanks,
Anca
> Advantages:
> * Same as the content field - More consistency
> * More power since we use wiki syntax and we can use any script
> language
> * 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 
11:24 a.m.
On Mon, Jun 25, 2012 at 10:51 AM, Anca Luca <lucaa(a)xwiki.com> wrote:
On 06/25/2012 09:24 AM, Vincent Massol wrote:
Yes. IMHO should we put a WYSIWYG here it should be very minimalist. For
example I wouldn't put a "macro" dialog, but a specialized i18n macro
button. And probably just this button.
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
it's interesting if we have an i18n macro... for the rest of the
formatting I'm not sure... I don't know if formatting in titles is used
that often
* Make the title field a textarea so that we can have more than 1 line
big +1, not for the lines, but for the
size (255 becomes quickly too small)
* 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
more or less, I think we should keep it
simple for the titles: no wysiwyg
editor, no textarea, just as it was until now, except that longer.
* Stop trying to extract title content from the doc content
> * Have a backward compat param to still support the old mode, but have it
> off by default in 4.2/4.3
This is interesting too, but I don't
have a strong opinion, although not
extracting titles anymore would be wonderful :) .
<side > * Introduce a {{i18n}} macro
(or {{translate}}, or …)
> </side
+1
I think we should also have a discussion about the purpose of the title
(now that we can put anything in document name) and how titles should be
used by default by the platform, but I need to clear the ideas a bit in my
head before starting it.
I gave some thoughts to this question lately, and in the end I came to
think wikimedia/wikipedia really nailed the document name/document title
mix. Only they don't have to handle i18n nor dynamic titles.
Jerome
Thanks,
Anca
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* 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<http://lists.xwiki.org/ma…
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
10:59 a.m.
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).
* 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
11:10 a.m.
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:
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
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). * 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
11:14 a.m.
On Jun 25, 2012, at 11:10 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
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). Even the doc content can be
thought as a metadata. It's not because it's harder for it to be dynamic that we
shouldn't do it (otherwise we'll just be a static web site generation tool ;)).
Thanks
-Vincent
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)massol.net> wrote:
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). 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). 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
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
11:21 a.m.
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:
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.).
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).
--
Thomas Mortagne
* 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
12:21 p.m.
Hi,
On Mon, Jun 25, 2012 at 12:21 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
it
script
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 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 > 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
12:19 p.m.
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)massol.net> wrote:
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.
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)
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
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
12:22 p.m.
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
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
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)massol.net>
wrote:
Hi guys,
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.
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)
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
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
* 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<http://lists.xwiki.org/ma…
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
1:01 p.m.
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca
<lucaa(a)xwiki.com> wrote:
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 --, 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
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
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). Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <vincent(a)massol.net>
wrote:
Hi guys,
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.
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.
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
* 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<http://lists.xwiki.org/ma…
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
2:44 p.m.
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.
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.
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 <lucaa(a)xwiki.com> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca
<lucaa(a)xwiki.com> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
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
Hi,
the
functionality/user experience of an application? (also please see my reply
to Thomas' comment).
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 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 Thanks,
Eduard
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
An alternative to people that *really* want to
generate their title
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
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
> devs(a)xwiki.org
>
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
>
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
> >
> ______________________________****_________________
>
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________****_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
3:13 p.m.
On Mon, Jun 25, 2012 at 2:44 PM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;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.
I happened to stumble upon one use case where I wanted markup in my titles
: for "sub-titles". See for example headings at
http://twitter.github.com/bootstrap/base-css.html ; where they wrap
sub-titles in <small> tag. But I agree there aren't many legitimate use
case for markup in titles.
Though it doesn't mean it cannot be exposed through a stripped down
WYSIWYG, in my opinion. I like the idea Vincent presented of a one-line
textarea that expand when you type enter, same way the facebook message box
works. But one thing is certain, should we go for the WYSIWYG it HAS to be
a stripped down WYSIWYG, with just the a very minimal set of buttons. One
idea could be to have the "Source" button only for advanced 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.
Yes ideally when creating a page, the title should be copied from what the
user typed in to create the page in the "page name" box, this whatever the
rule is to create the final page name.
This is what wordpress and many other tools do. I think a corollary for
clarity and ease of use would be to introduce the "page name" as the
"permalink" notion, which users are often familiar with ; this in the
rename dialog for example. See also what I've experimented with in Lyrebird
:
http://extensions.xwiki.org/xwiki/bin/download/Extension/Lyrebird+Skin/lyre….
An other idea for the rename dialog in future versions could be to have
options for generating 3xx redirect aliases.
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.
Yes this is often the right solution for such applications. It has the
advantage to make the title searchable, filterable in livetables, etc.
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.
Yes, although this mechanism is awkward and personally I've never seen any
real use of it, besides our packaging of translated Main.WebHome and
Sandbox space...
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.*
I agree it's a touchy subject and we have to make it right.
Jérôme
Thanks,
Guillaume
On Mon, Jun 25, 2012 at 1:01 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
want
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<
http://lists.xwiki.org/mailman/listinfo/devs>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
> On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
>
> On 06/25/2012 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.
>>>
>>> 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 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
>>>> devs(a)xwiki.org
>>>> 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
>>> devs(a)xwiki.org
>>> 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
>> devs(a)xwiki.org
>> 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
> devs(a)xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/devs<
http://lists.xwiki.org/mailman/listinfo/devs>
3:16 p.m.
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 <lucaa(a)xwiki.com> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca
<lucaa(a)xwiki.com> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
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
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 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
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
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
>> devs(a)xwiki.org
>>
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
>>
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>> ______________________________****_________________
>>
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
>
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>
______________________________****_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
4470
days inactive
4470
days old
23 comments
6 participants
participants (6)
-
Anca Luca -
Eduard Moraru -
Guillaume Lerouge -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol