[xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)
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
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'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
Was "I don't have much idea to make the migration easier" but forgot to remove it after the titeContent suggestion.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'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
Was "I don't have much idea to make the migration easier" but forgot to remove it after the titeContent suggestion.
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 Jun 25, 2012, at 10:34 AM, Vincent Massol wrote:
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'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
Was "I don't have much idea to make the migration easier" but forgot to remove it after the titeContent suggestion.
Another idea would be to add a migration script that would wrap current titles with {{velocity}}…{{/velocity}} if we detect $msg for example.
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 10:34 AM, Vincent Massol <[email protected]> wrote:
On Jun 25, 2012, at 9:54 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:52 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I'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
Was "I don't have much idea to make the migration easier" but forgot to remove it after the titeContent suggestion.
Another idea would be to add a migration script that would wrap current titles with {{velocity}}…{{/velocity}} if we detect $msg for example.
It's not only about translations, many applications extract whatever is the current entity name from its object to put it in the title.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06/25/2012 09:52 AM, Thomas Mortagne wrote:
On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity I'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.
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
<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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
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.
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
* 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
On 06/25/2012 11:03 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
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. I really think we need wysiwyg, same as for content because it's wiki syntax.
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.
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
* 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 06/25/2012 12:40 PM, Anca Luca wrote:
On 06/25/2012 11:03 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:
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. I really think we need wysiwyg, same as for content because it's wiki syntax.
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.
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?
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
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
* 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 25, 2012 at 10:51 AM, Anca Luca <[email protected]> wrote:
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
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.
* 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
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 [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
-- Jérôme Velociter Winesquare http://www.winesquare.net/
Hi, On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly. AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro. 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
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). 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
On Jun 25, 2012, at 11:10 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
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). 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
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
Hi, On Mon, Jun 25, 2012 at 12:14 PM, Vincent Massol <[email protected]> wrote:
On Jun 25, 2012, at 11:10 AM, Vincent Massol wrote:
On Jun 25, 2012, at 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]>
wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is
bad
practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
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
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?
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)
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 25, 2012 at 10:59 AM, Eduard Moraru <[email protected]> wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As 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.).
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, On Mon, Jun 25, 2012 at 12:21 PM, Thomas Mortagne <[email protected]
wrote:
On Mon, Jun 25, 2012 at 10:59 AM, Eduard Moraru <[email protected]> wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As I said it's far from being only about translations, most applications insert something coming from an object or generated some other way in the title which identify the current element (blog post title, application name, wiki identifier, etc.).
Would you consider that the programatically added information to the title (by adding stuff like "Edit blog post 'My vacation'", "Edit application 'My App'", etc...) would be of great value to the user? Why not just use a simple "Edit blog post", "Edit application", etc. for title? You can further identify the current item inside the content if you really want to. I don`t see this as vital development resource and see it rather as a "bells and whistles" element that brings more problems than it solved. Thanks, Eduard
An alternative to people that *really* want to generate their title
trough
a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(document.syntax.toIdString()) (as they probably did before) and the first heading (that is either static or programmatically generated) will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line * Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
An alternative to people that *really* want to generate their title trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(document.syntax.toIdString()) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example). Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line * Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
Can you please give me some examples where this feature is essential to the functionality/user experience of an application? (also please see my reply to Thomas' comment). Thanks, Eduard
An alternative to people that *really* want to generate their title trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(**document.syntax.toIdString()) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example).
Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
Can you please give me some examples where this feature is essential to the functionality/user experience of an application? (also please see my reply to Thomas' comment).
2 typical cases: 1/ you have a text in a property in an object in the document and you want that text to be displayed as the document title. For various reasons, this text cannot be in the document title field itself or in the document name (it's not unique, it's not short enough, the text is actually part of the type structure and the structure would be incomplete if you put the data in the title since title is not semantic (it just means document title it doesn't mean "frequently asked question" in a FAQ application, for example ), you don't want to duplicate texts (once in a prop once in the title), in enough cases it's wrongly used by devs that don't think about using titles and re-add a property -- also because http://jira.xwiki.org/browse/XWIKI-7905 --, etc) 2/ indeed you want to decorate the title: e.g. for the search, you want to display the searched word in the title; you have a page with scripted content that lists all documents for a tag, or for some property, you want the title to be different depending on what that tag is or the property Also: 3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we need them to provide nice things and we want these nice things. Not having them will not stop from providing nice things, it will only lead to hacking it: customizing .vms to hide the title and then putting it with hacked html and css from the document content (i've seen it done), or even customizing it directly in the .vm. As I said in one of my previous mails, I think it's only for devs, a lot less for users. So we don't need to show it, for the users the title should stay simple, but all these things need to stay possible since otherwise everybody will customize by its own mean, more or less correct, in 80% of cases (for devs, I repeat). Thanks, Anca
Thanks, Eduard
An alternative to people that *really* want to generate their title trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(**document.syntax.toIdString()) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example).
Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with
velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
Can you please give me some examples where this feature is essential to
the functionality/user experience of an application? (also please see my reply to Thomas' comment).
2 typical cases: 1/ you have a text in a property in an object in the document and you want that text to be displayed as the document title. For various reasons, this text cannot be in the document title field itself or in the document name (it's not unique, it's not short enough, the text is actually part of the type structure and the structure would be incomplete if you put the data in the title since title is not semantic (it just means document title it doesn't mean "frequently asked question" in a FAQ application, for example ), you don't want to duplicate texts (once in a prop once in the title), in enough cases it's wrongly used by devs that don't think about using titles and re-add a property -- also because http://jira.xwiki.org/browse/** XWIKI-7905 <http://jira.xwiki.org/browse/XWIKI-7905> --, etc) 2/ indeed you want to decorate the title: e.g. for the search, you want to display the searched word in the title; you have a page with scripted content that lists all documents for a tag, or for some property, you want the title to be different depending on what that tag is or the property Also: 3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we need them to provide nice things and we want these nice things. Not having them will not stop from providing nice things, it will only lead to hacking it: customizing .vms to hide the title and then putting it with hacked html and css from the document content (i've seen it done), or even customizing it directly in the .vm.
As I said in one of my previous mails, I think it's only for devs, a lot less for users. So we don't need to show it, for the users the title should stay simple, but all these things need to stay possible since otherwise everybody will customize by its own mean, more or less correct, in 80% of cases (for devs, I repeat).
Thanks, Anca
Thanks, Eduard
An alternative to people that *really* want to generate their title
trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(****document.syntax.toIdString()**) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example).
Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________****_________________
devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
On Mon, Jun 25, 2012 at 2:44 PM, Guillaume Lerouge <[email protected]>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/lyreb.... 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 <[email protected]> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content
field)
instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
Can you please give me some examples where this feature is essential to the functionality/user experience of an application? (also please see my reply to Thomas' comment).
2 typical cases: 1/ you have a text in a property in an object in the document and you want that text to be displayed as the document title. For various reasons, this text cannot be in the document title field itself or in the document name (it's not unique, it's not short enough, the text is actually part of the type structure and the structure would be incomplete if you put the data in the title since title is not semantic (it just means document title it doesn't mean "frequently asked question" in a FAQ application, for example ), you don't want to duplicate texts (once in a prop once in the title), in enough cases it's wrongly used by devs that don't think about using titles and re-add a property -- also because http://jira.xwiki.org/browse/** XWIKI-7905 <http://jira.xwiki.org/browse/XWIKI-7905> --, etc) 2/ indeed you want to decorate the title: e.g. for the search, you want to display the searched word in the title; you have a page with scripted content that lists all documents for a tag, or for some property, you want the title to be different depending on what that tag is or the property Also: 3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we need them to provide nice things and we want these nice things. Not having them will not stop from providing nice things, it will only lead to hacking it: customizing .vms to hide the title and then putting it with hacked html and css from the document content (i've seen it done), or even customizing it directly in the .vm.
As I said in one of my previous mails, I think it's only for devs, a lot less for users. So we don't need to show it, for the users the title should stay simple, but all these things need to stay possible since otherwise everybody will customize by its own mean, more or less correct, in 80% of cases (for devs, I repeat).
Thanks, Anca
Thanks, Eduard
An alternative to people that *really* want to generate their title
trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(****document.syntax.toIdString()**) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example).
Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<; http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs> >
______________________________****_________________
devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<; http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<; http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On 06/25/2012 02:44 PM, Guillaume Lerouge wrote:
Hi,
this looks like a lot of complex things to do for an result that will not be user friendly.
First, I don't really thing we want users to put styles, links or wiki macros in titles. The "Title" is just that, a pretty name for the page. I don't know any web application that handles the title as anything else than a simple, one-line-long input field. Handling it differently is going to create a lot of confusion for users.
We could make entering the title mandatory to make sure there's always one, and thus remove the need to compute it from the content of the page. If the title is not given (due to a script creating a page), it could automatically be filled with the page name when the page is created.
Second, applications that need it would be responsible to compute the right title for any page based on data entered by the user and would feed it to the title field upon saving the page.
That's not that easy like that, because it would mean duplicating the data and keeping redundant data in sync. I think being able to reuse a field with some velocity in the title is a good idea, especially now when you can have a "sheet" for the title too (the new sheets mechanism uses the title from the sheet and renders it in the context of the document bound to that sheet). I have seen it (your proposal) done a few times with a listener that is responsible to keep data in sync, and it's not that right (let alone the fact that duplicating data is not a good idea). What is important though is to judge correctly if the title needs to be in a property of the class and reused or if it should be put directly in the display title of the document. This is a relevant issue in this direction http://jira.xwiki.org/browse/XWIKI-7369 as, once fixed, it will show application creators that there already is a pretty name for a document and that they can use it to put data in (along with http://jira.xwiki.org/browse/XWIKI-7905 which will actually allow people to use this title as part of the structured document metadata).
Third, we already have a mechanism to handle internationalized content in wiki pages - the translations of that page in other languages when in multilingual mode.
I think too that the i18n of titles should also be approached from this side: maybe we can do something about i18n in general which will allow easier internationalization of titles, instead of changing the titles to accomodate easier calls to $msg.get() (since we would need to blow a bit the dust off the i18n module as well :) ). Thanks, Anca
Right now, it feels like we're about to try to implement something very complex for the sake of making developer's live a bit easier, while at the same time sacrificing ease-of-use in a very big way. This is not something that I feel will benefit XWiki in the long run, whether for users or for devs.
If we want to change the way the title works, I'd like us to *start with a list of use cases* and see *how the proposed solution impacts them and makes them better.*
Thanks,
Guillaume
On Mon, Jun 25, 2012 at 1:01 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 12:22 PM, Eduard Moraru wrote:
On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote:
On 06/25/2012 10:59 AM, Eduard Moraru wrote:
Hi,
On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> wrote:
Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad practice and we should discourage people from doing it. You have lots of problems when some application lists the titles of pages with code in their title or, worse, when the application tries to render those titles. You have all sorts of security issues and generally bad things when the writer of that title does not assume that it is going to be rendered outside his page. I know it is a cool feature, but it is causing too much headache to handle correctly.
AFAIK, 90% of the times when we need the title to be rendered is because we need translation keys. We could very well have a filtered wiki syntax, that allows only calls to the new {{translation}} macro.
As Thomas said, there are cases when something else is used (with velocity code, yes). Now this something else might indeed be only 10% of the cases, but we should still keep it possible. Not show it in the UI because 90% of the people don't care about it, but still keep it possible.
Can you please give me some examples where this feature is essential to the functionality/user experience of an application? (also please see my reply to Thomas' comment).
2 typical cases: 1/ you have a text in a property in an object in the document and you want that text to be displayed as the document title. For various reasons, this text cannot be in the document title field itself or in the document name (it's not unique, it's not short enough, the text is actually part of the type structure and the structure would be incomplete if you put the data in the title since title is not semantic (it just means document title it doesn't mean "frequently asked question" in a FAQ application, for example ), you don't want to duplicate texts (once in a prop once in the title), in enough cases it's wrongly used by devs that don't think about using titles and re-add a property -- also because http://jira.xwiki.org/browse/** XWIKI-7905 <http://jira.xwiki.org/browse/XWIKI-7905> --, etc) 2/ indeed you want to decorate the title: e.g. for the search, you want to display the searched word in the title; you have a page with scripted content that lists all documents for a tag, or for some property, you want the title to be different depending on what that tag is or the property Also: 3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we need them to provide nice things and we want these nice things. Not having them will not stop from providing nice things, it will only lead to hacking it: customizing .vms to hide the title and then putting it with hacked html and css from the document content (i've seen it done), or even customizing it directly in the .vm.
As I said in one of my previous mails, I think it's only for devs, a lot less for users. So we don't need to show it, for the users the title should stay simple, but all these things need to stay possible since otherwise everybody will customize by its own mean, more or less correct, in 80% of cases (for devs, I repeat).
Thanks, Anca
Thanks, Eduard
An alternative to people that *really* want to generate their title
trough a script is to actually keep the title extraction from the document content and make them have to generate a <h1> element from the content, not from the title. This means that they have to leave the actual title empty for the extraction to be triggered and, if I am not mistaken, applications that want to list document titles can use api.Document.gerRenderedTitle(****document.syntax.toIdString()**) (as they probably did before) and the first heading (that is either static or programmatically generated)
No, not programatically generated. Last time I checked, title extraction tool was not evaluating scripts. Also this extraction thing is really crap because it's hard to use: it uses a hack to not display the title twice, which is to search for the h1 with a regex (aaaaaa!) in a vm to put a hidden class so that it's not displayed. This makes it terribly painful to re-use those title and content somewhere else since you don't know if you'll have 2 titles or just one (in a pdf export, for example).
Thanks, Anca
will be displayed, which sounds good to me.
So I would be +1, considering the comment above (restricted use of macros).
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field * Stop trying to extract title content from the doc content
+1
* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3 <side> * Introduce a {{i18n}} macro (or {{translate}}, or …)
+1
</side>
Advantages: * Same as the content field - More consistency * More power since we use wiki syntax and we can use any script language
More problems for devs, more raised eyebrows from users. :)
* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated * Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it * We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks -Vincent
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs> ______________________________****_________________
devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs> ______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Anca Luca -
Eduard Moraru -
Guillaume Lerouge -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol