That makes sense, thank you for the clarification. Unfortunately, I am using the HTML macro to generate the final output - this is because I need to use <ul>'s with a javascript to make the div's into collapsible trees. Does that mean I'm out of luck? On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne <[email protected]> wrote:

On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications <[email protected]> wrote:

...

One more tonight...

It seems that I am unable to use the built-in TOC macro for wiki content which is generated dynamically from a Class Sheet {{include}}. I assume this is because the TOC macro is rendered before (or simultaneously with) the include macro which actually displays the objects on the page, so as far as the TOC macro knows, there are no wiki headings on the page (yet) to create an outline from.

Actually no, there is a concept of priority in macros and TOC macro priority is very low specifically to support use case like that. But TOC only support (generated or not) real wiki content which mean if you have anything in a html macro it will not support it because html macro produce a RawBlock which is a black box containing html syntax for other macros.

So if you use case is just what you described it should work well.

...

Does anyone have any suggestions on how to parse through the final rendered output of the wiki page to generate a table of contents for dynamically generated wiki content? If I'm missing something with the existing macro, that would be great...

What I am looking to do is write some code (preferably in a panel, I think), which creates a TOC-style index of all the wiki-syntax headings contained on the fully rendered page, after the content has been generated from TextArea properties of a set of attached objects to the page.

I have written custom display code that loops through every object of a custom class attached to a page and then displays some of that objects properties in a series of collapsible div's. Each object contains two TextArea properties - one for WYSIWYG data, and one for plain text, which would be formatted in wiki syntax. The result is a list of each objects name with an expandable <div> full of the wiki-rendered content contained in the TextArea properties. I would like to generate a TOC which "reads through" that content and comes up with a list of only the relevant headings under each displayed "object"

For example, on a page with 3 objects, the custom display code in the Class Sheet results in this (the wiki syntax appears fully rendered, obviously):

Object 1 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 2 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 3 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

I would like the TOC to return:

Object 1  Heading 2  Heading 3 Object 2  Heading 2  Heading 3 Object 3  Heading 2  Heading 3

Even when all the div's are initially collapsed/hidden. It would be ideal if the TOC was clickable and went to the relevant anchor...

Are the divs done using html macro or using wiki syntax ?

...

I can obviously use getValue() with each TextArea property to return a string with that objects wiki syntax - but I don't have an easy way to parse that string to only return the heading levels...

Any guidance would be appreciated.

Thanks,

aaron _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

On Thu, Oct 20, 2011 at 9:52 PM, Thomas Mortagne <[email protected]> wrote:

On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications <[email protected]> wrote:

...

That makes sense, thank you for the clarification. Unfortunately, I am using the HTML macro to generate the final output - this is because I need to use <ul>'s with a javascript to make the div's into collapsible trees.

Does that mean I'm out of luck?

<ul> ? I don't see much lists in your example, did you mean div ?

You can get div with custom parameters in pure wiki syntax the following way:

(% class="somecssclass" %) ((( div content )))

which produces

<div class="somecssclass">div content</div>

It's more <div class="somecssclass"><p>div content</p></div> actually.

And if you really mean list, list most of the wiki elements list support custom parameters too:

(% class="somecssclass" %) * mylist element 1 * mylist element 2

which produces

<ul class="somecssclass"> <li>mylist element 1</li> <li>mylist element 2</li> </ul

You can put anything you want in custom parameters and html renderer will print them as you provided them depending of the element.

Using the html macro should always be the last resort, usually when you get some html you don't really have control on that you need to display or when you need to display elements not supported by the wiki syntax (yet) like <form> related stuff.

...

On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications <[email protected]> wrote:

...

One more tonight...

It seems that I am unable to use the built-in TOC macro for wiki content which is generated dynamically from a Class Sheet {{include}}. I assume this is because the TOC macro is rendered before (or simultaneously with) the include macro which actually displays the objects on the page, so as far as the TOC macro knows, there are no wiki headings on the page (yet) to create an outline from.

Actually no, there is a concept of priority in macros and TOC macro priority is very low specifically to support use case like that. But TOC only support (generated or not) real wiki content which mean if you have anything in a html macro it will not support it because html macro produce a RawBlock which is a black box containing html syntax for other macros.

So if you use case is just what you described it should work well.

...

Does anyone have any suggestions on how to parse through the final rendered output of the wiki page to generate a table of contents for dynamically generated wiki content? If I'm missing something with the existing macro, that would be great...

What I am looking to do is write some code (preferably in a panel, I think), which creates a TOC-style index of all the wiki-syntax headings contained on the fully rendered page, after the content has been generated from TextArea properties of a set of attached objects to the page.

I have written custom display code that loops through every object of a custom class attached to a page and then displays some of that objects properties in a series of collapsible div's. Each object contains two TextArea properties - one for WYSIWYG data, and one for plain text, which would be formatted in wiki syntax. The result is a list of each objects name with an expandable <div> full of the wiki-rendered content contained in the TextArea properties. I would like to generate a TOC which "reads through" that content and comes up with a list of only the relevant headings under each displayed "object"

For example, on a page with 3 objects, the custom display code in the Class Sheet results in this (the wiki syntax appears fully rendered, obviously):

Object 1 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 2 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 3 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

I would like the TOC to return:

Object 1  Heading 2  Heading 3 Object 2  Heading 2  Heading 3 Object 3  Heading 2  Heading 3

Even when all the div's are initially collapsed/hidden. It would be ideal if the TOC was clickable and went to the relevant anchor...

Are the divs done using html macro or using wiki syntax ?

...

I can obviously use getValue() with each TextArea property to return a string with that objects wiki syntax - but I don't have an easy way to parse that string to only return the heading levels...

Any guidance would be appreciated.

Thanks,

aaron _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne

-- Thomas Mortagne

After checking, I suppose I'm not using <div>'s at all - just <ul>'s for each object. On Thu, Oct 20, 2011 at 12:53 PM, Thomas Mortagne <[email protected]> wrote:

On Thu, Oct 20, 2011 at 9:52 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications <[email protected]> wrote:

...

That makes sense, thank you for the clarification. Unfortunately, I am using the HTML macro to generate the final output - this is because I need to use <ul>'s with a javascript to make the div's into collapsible trees.

Does that mean I'm out of luck?

<ul> ? I don't see much lists in your example, did you mean div ?

You can get div with custom parameters in pure wiki syntax the following way:

(% class="somecssclass" %) ((( div content )))

which produces

<div class="somecssclass">div content</div>

It's more <div class="somecssclass"><p>div content</p></div> actually.

...

And if you really mean list, list most of the wiki elements list support custom parameters too:

(% class="somecssclass" %) * mylist element 1 * mylist element 2

which produces

<ul class="somecssclass"> <li>mylist element 1</li> <li>mylist element 2</li> </ul

You can put anything you want in custom parameters and html renderer will print them as you provided them depending of the element.

Using the html macro should always be the last resort, usually when you get some html you don't really have control on that you need to display or when you need to display elements not supported by the wiki syntax (yet) like <form> related stuff.

...

On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications <[email protected]> wrote:

...

One more tonight...

It seems that I am unable to use the built-in TOC macro for wiki content which is generated dynamically from a Class Sheet {{include}}. I assume this is because the TOC macro is rendered before (or simultaneously with) the include macro which actually displays the objects on the page, so as far as the TOC macro knows, there are no wiki headings on the page (yet) to create an outline from.

Actually no, there is a concept of priority in macros and TOC macro priority is very low specifically to support use case like that. But TOC only support (generated or not) real wiki content which mean if you have anything in a html macro it will not support it because html macro produce a RawBlock which is a black box containing html syntax for other macros.

So if you use case is just what you described it should work well.

...

Does anyone have any suggestions on how to parse through the final rendered output of the wiki page to generate a table of contents for dynamically generated wiki content? If I'm missing something with the existing macro, that would be great...

What I am looking to do is write some code (preferably in a panel, I think), which creates a TOC-style index of all the wiki-syntax headings contained on the fully rendered page, after the content has been generated from TextArea properties of a set of attached objects to the page.

I have written custom display code that loops through every object of a custom class attached to a page and then displays some of that objects properties in a series of collapsible div's. Each object contains two TextArea properties - one for WYSIWYG data, and one for plain text, which would be formatted in wiki syntax. The result is a list of each objects name with an expandable <div> full of the wiki-rendered content contained in the TextArea properties. I would like to generate a TOC which "reads through" that content and comes up with a list of only the relevant headings under each displayed "object"

For example, on a page with 3 objects, the custom display code in the Class Sheet results in this (the wiki syntax appears fully rendered, obviously):

Object 1 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 2 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 3 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

I would like the TOC to return:

Object 1  Heading 2  Heading 3 Object 2  Heading 2  Heading 3 Object 3  Heading 2  Heading 3

Even when all the div's are initially collapsed/hidden. It would be ideal if the TOC was clickable and went to the relevant anchor...

Are the divs done using html macro or using wiki syntax ?

...

I can obviously use getValue() with each TextArea property to return a string with that objects wiki syntax - but I don't have an easy way to parse that string to only return the heading levels...

Any guidance would be appreciated.

Thanks,

aaron _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications <[email protected]> wrote:

Thank you for the feedback - I have been playing with passing custom parameters, and have a few additional clarification questions.

It seems that I need to use pure wiki syntax if I want the TOC macro to work right. I am currently relying on the {{html}} macro for two things which I can't figure out how to replace with custom parameters:

1) Nested <ul>'s - I can only get the custom parameter to apply to one line, and can't figure out how to nest another <ul>.

Something like this: (% class="mktree" name="tree" %) * $doc.display("Title", $obj)  <velocity code, including an {{html}} block to create an <input> element> **Additional parts of tree ***Additional parts of tree

Just returns two different <ul>'s, only the first one of which has the custom parameter. Is this because the additional lines of code before continuing the tree forces the rendering engine to close the first <ul>? Any way to override that?

Here is an example of wiki syntax with custom parameters on each ul: (% param=value %) * toto (% param2=value2 %) ** titi but custom parameters on li is not supported yet.

2) Table Sorter - Unfortunately, the whole set of object display code is wrapped in an {{html}} macro because I am using the old Table Sorter extension code. This is because I want to display multiple properties from each object in a single table cell. Looking at the Live Table macro, it seems that it only supports binding a table to a class and then setting a column to display a single property - where I need a single cell to include multiple properties displayed using custom code.

Accomplishing this using the html syntax is simple - I can include an arbitrary amount of code in each <td> tag.

To use wiki syntax for a sortable table, the XWiki Syntax document says I should use this:

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|Cell 12 |Cell 21|Cell 22

This creates the table fine - but I can't figure out how to include additional multi-line code in a single cell. As soon as I put in a new line, etc...it closes the table. Is there any way to accomplish this using wiki syntax? Should I be trying to use LiveTable instead somehow?

You can put as many lines you want without closing the table but it's closed by an empty line. If you need to have several paragraphs you can use "group" syntax (http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HGroups) as in (% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|((( Cell 12 with several paragraphs )))|Cell 21|Cell 22

If the above is confusing, here's what I'm really asking:

I want to use a sortable table to display multiple objects of the same class on the same page. I would like that table to display multiple properties of each object in certain cells in the row. Some of those properties will contain wiki syntax - which I would like to be readable by the TOC macro after the table has been rendered. Is there a way to accomplish this?

Thank you,

Aaron

On Thu, Oct 20, 2011 at 1:18 PM, Ashtar Communications <[email protected]> wrote:

...

Interesting - I had missed the ability to pass custom parameters using wiki syntax. I will play with that and see if I can get it to output the same html I need.

I am in fact using a series of nested <ul> within each <div>, that forms a collapsible javascript tree. The js is touchy about the exact formatting of the UL - if I can't get the tags to nest correctly using wiki syntax then I may be back with additional questions.

A more accurate but simplified version of each object's display code is:

<ul class="tree">  <li>  <h2>some content</h2>  <input />  <input />  </li>  <ul>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>  </ul> </ul>

Thanks much,

aaron

On Thu, Oct 20, 2011 at 12:52 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications <[email protected]> wrote:

...

That makes sense, thank you for the clarification. Unfortunately, I am using the HTML macro to generate the final output - this is because I need to use <ul>'s with a javascript to make the div's into collapsible trees.

Does that mean I'm out of luck?

<ul> ? I don't see much lists in your example, did you mean div ?

You can get div with custom parameters in pure wiki syntax the following way:

(% class="somecssclass" %) ((( div content )))

which produces

<div class="somecssclass">div content</div>

And if you really mean list, list most of the wiki elements list support custom parameters too:

(% class="somecssclass" %) * mylist element 1 * mylist element 2

which produces

<ul class="somecssclass"> <li>mylist element 1</li> <li>mylist element 2</li> </ul

You can put anything you want in custom parameters and html renderer will print them as you provided them depending of the element.

Using the html macro should always be the last resort, usually when you get some html you don't really have control on that you need to display or when you need to display elements not supported by the wiki syntax (yet) like <form> related stuff.

...

On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications <[email protected]> wrote:

...

One more tonight...

It seems that I am unable to use the built-in TOC macro for wiki content which is generated dynamically from a Class Sheet {{include}}. I assume this is because the TOC macro is rendered before (or simultaneously with) the include macro which actually displays the objects on the page, so as far as the TOC macro knows, there are no wiki headings on the page (yet) to create an outline from.

Actually no, there is a concept of priority in macros and TOC macro priority is very low specifically to support use case like that. But TOC only support (generated or not) real wiki content which mean if you have anything in a html macro it will not support it because html macro produce a RawBlock which is a black box containing html syntax for other macros.

So if you use case is just what you described it should work well.

...

Does anyone have any suggestions on how to parse through the final rendered output of the wiki page to generate a table of contents for dynamically generated wiki content? If I'm missing something with the existing macro, that would be great...

What I am looking to do is write some code (preferably in a panel, I think), which creates a TOC-style index of all the wiki-syntax headings contained on the fully rendered page, after the content has been generated from TextArea properties of a set of attached objects to the page.

I have written custom display code that loops through every object of a custom class attached to a page and then displays some of that objects properties in a series of collapsible div's. Each object contains two TextArea properties - one for WYSIWYG data, and one for plain text, which would be formatted in wiki syntax. The result is a list of each objects name with an expandable <div> full of the wiki-rendered content contained in the TextArea properties. I would like to generate a TOC which "reads through" that content and comes up with a list of only the relevant headings under each displayed "object"

For example, on a page with 3 objects, the custom display code in the Class Sheet results in this (the wiki syntax appears fully rendered, obviously):

Object 1 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 2 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

Object 3 Name - Click to expand    ******Hidden until clicked********    ==Heading 2==    ===Heading 3===    Normal text, etc...

I would like the TOC to return:

Object 1  Heading 2  Heading 3 Object 2  Heading 2  Heading 3 Object 3  Heading 2  Heading 3

Even when all the div's are initially collapsed/hidden. It would be ideal if the TOC was clickable and went to the relevant anchor...

Are the divs done using html macro or using wiki syntax ?

...

I can obviously use getValue() with each TextArea property to return a string with that objects wiki syntax - but I don't have an easy way to parse that string to only return the heading levels...

Any guidance would be appreciated.

Thanks,

aaron _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne

Hi Aaron, On Tue, Nov 8, 2011 at 12:08 PM, Ashtar Communications <[email protected]> wrote:

Thomas,

Thank for very much for your suggestion. The group syntax was exactly what I needed.

However, I am still having some trouble with getting the TOC macro to correctly pick up wiki syntax rendered with $doc.display() that is contained in an object's property.

I have also noticed that using wiki syntax instead of html, $doc.display seems to behave differently and overrides the default editor setting.

Here is my example - I am using wiki syntax similar to the following (simplified for example's sake):

************START CODE**************** (% class="grid sortable doOddEven" id="Table" %) (% class="sortHeader" %)|=Field 1|=Field 2 |Data 1|((( (% class="mktree" name="tree" %) * ((( =$doc.display("String", $object)= ))) ** ((( $doc.display("TextArea", $object) ))) )))

{{toc /}} ************END CODE****************

The TextArea property contains a large quantity of text formatted in xwiki syntax. The display works just fine - the contents of the property render correctly and display in the table.

Two problems:

1) The TOC macro only recognizes the String property that I manually enclose in "=" Heading 1 syntax. It doesn't seem to be picking up the wiki syntax contained in the object properties. So if I had 3 objects on the page, I get:

*String 1 *String 2 *String 3

Instead of:

*String 1  **Heading 2 from TextArea**  **Heading 2 from TextArea** *String 2 Etc....

I'm afraid I don't know very much about the order of macro rendering or whether it is even possible to accomplish what I am describing...

2) When I use the Inline editing mode, another TextArea property of the object (not shown in the code above) does not show up with the WYSIWYG editor, even though it is set as the default editor. When using the {{html}} macro and code like this:

<li>$doc.display("TextAreaWYSIWYG", $object)</li>

The property correctly displays in Inline mode with the WYSIWYG editor. Now that I am using only wiki syntax to display the table, all TextArea properties show up in the Plain Text editor, regardless of their default setting. Am I doing something wrong?

Can you paste the code that doesn't work? (i.e. without using the HTML macro). Also, can you print this: $context.getEditorWysiwyg() at the end of your sheet. It will display a comma-separated list of field IDs that require WYSIWYG editing. Are your fields listed there when editing in Inline mode? Hope this helps, Marius

Many thanks for all of the help, I have made very significant progress on my project thanks to this list...

aaron

On Sun, Oct 23, 2011 at 1:50 AM, Thomas Mortagne <[email protected]> wrote:

...

On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications <[email protected]> wrote:

...

Thank you for the feedback - I have been playing with passing custom parameters, and have a few additional clarification questions.

It seems that I need to use pure wiki syntax if I want the TOC macro to work right. I am currently relying on the {{html}} macro for two things which I can't figure out how to replace with custom parameters:

1) Nested <ul>'s - I can only get the custom parameter to apply to one line, and can't figure out how to nest another <ul>.

Something like this: (% class="mktree" name="tree" %) * $doc.display("Title", $obj)  <velocity code, including an {{html}} block to create an <input> element> **Additional parts of tree ***Additional parts of tree

Just returns two different <ul>'s, only the first one of which has the custom parameter. Is this because the additional lines of code before continuing the tree forces the rendering engine to close the first <ul>? Any way to override that?

Here is an example of wiki syntax with custom parameters on each ul:

(% param=value %) * toto (% param2=value2 %) ** titi

but custom parameters on li is not supported yet.

...

2) Table Sorter - Unfortunately, the whole set of object display code is wrapped in an {{html}} macro because I am using the old Table Sorter extension code. This is because I want to display multiple properties from each object in a single table cell. Looking at the Live Table macro, it seems that it only supports binding a table to a class and then setting a column to display a single property - where I need a single cell to include multiple properties displayed using custom code.

Accomplishing this using the html syntax is simple - I can include an arbitrary amount of code in each <td> tag.

To use wiki syntax for a sortable table, the XWiki Syntax document says I should use this:

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|Cell 12 |Cell 21|Cell 22

This creates the table fine - but I can't figure out how to include additional multi-line code in a single cell. As soon as I put in a new line, etc...it closes the table. Is there any way to accomplish this using wiki syntax? Should I be trying to use LiveTable instead somehow?

You can put as many lines you want without closing the table but it's closed by an empty line. If you need to have several paragraphs you can use "group"  syntax (http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HGroups) as in

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|((( Cell 12

with

several

paragraphs )))|Cell 21|Cell 22

...

If the above is confusing, here's what I'm really asking:

I want to use a sortable table to display multiple objects of the same class on the same page. I would like that table to display multiple properties of each object in certain cells in the row. Some of those properties will contain wiki syntax - which I would like to be readable by the TOC macro after the table has been rendered. Is there a way to accomplish this?

Thank you,

Aaron

On Thu, Oct 20, 2011 at 1:18 PM, Ashtar Communications <[email protected]> wrote:

...

Interesting - I had missed the ability to pass custom parameters using wiki syntax. I will play with that and see if I can get it to output the same html I need.

I am in fact using a series of nested <ul> within each <div>, that forms a collapsible javascript tree. The js is touchy about the exact formatting of the UL - if I can't get the tags to nest correctly using wiki syntax then I may be back with additional questions.

A more accurate but simplified version of each object's display code is:

<ul class="tree">  <li>  <h2>some content</h2>  <input />  <input />  </li>  <ul>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>  </ul> </ul>

Thanks much,

aaron

On Thu, Oct 20, 2011 at 12:52 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications <[email protected]> wrote:

...

That makes sense, thank you for the clarification. Unfortunately, I am using the HTML macro to generate the final output - this is because I need to use <ul>'s with a javascript to make the div's into collapsible trees.

Does that mean I'm out of luck?

<ul> ? I don't see much lists in your example, did you mean div ?

You can get div with custom parameters in pure wiki syntax the following way:

(% class="somecssclass" %) ((( div content )))

which produces

<div class="somecssclass">div content</div>

And if you really mean list, list most of the wiki elements list support custom parameters too:

(% class="somecssclass" %) * mylist element 1 * mylist element 2

which produces

<ul class="somecssclass"> <li>mylist element 1</li> <li>mylist element 2</li> </ul

You can put anything you want in custom parameters and html renderer will print them as you provided them depending of the element.

Using the html macro should always be the last resort, usually when you get some html you don't really have control on that you need to display or when you need to display elements not supported by the wiki syntax (yet) like <form> related stuff.

...

On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne <[email protected]> wrote: > On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications > <[email protected]> wrote: >> One more tonight... >> >> It seems that I am unable to use the built-in TOC macro for wiki >> content which is generated dynamically from a Class Sheet {{include}}. >> I assume this is because the TOC macro is rendered before (or >> simultaneously with) the include macro which actually displays the >> objects on the page, so as far as the TOC macro knows, there are no >> wiki headings on the page (yet) to create an outline from. > > Actually no, there is a concept of priority in macros and TOC macro > priority is very low specifically to support use case like that. But > TOC only support (generated or not) real wiki content which mean if > you have anything in a html macro it will not support it because html > macro produce a RawBlock which is a black box containing html syntax > for other macros. > > So if you use case is just what you described it should work well. > >> >> Does anyone have any suggestions on how to parse through the final >> rendered output of the wiki page to generate a table of contents for >> dynamically generated wiki content? If I'm missing something with the >> existing macro, that would be great... >> >> What I am looking to do is write some code (preferably in a panel, I >> think), which creates a TOC-style index of all the wiki-syntax >> headings contained on the fully rendered page, after the content has >> been generated from TextArea properties of a set of attached objects >> to the page. >> >> I have written custom display code that loops through every object of >> a custom class attached to a page and then displays some of that >> objects properties in a series of collapsible div's. Each object >> contains two TextArea properties - one for WYSIWYG data, and one for >> plain text, which would be formatted in wiki syntax. The result is a >> list of each objects name with an expandable <div> full of the >> wiki-rendered content contained in the TextArea properties. I would >> like to generate a TOC which "reads through" that content and comes up >> with a list of only the relevant headings under each displayed >> "object" >> >> For example, on a page with 3 objects, the custom display code in the >> Class Sheet results in this (the wiki syntax appears fully rendered, >> obviously): >> >> Object 1 Name - Click to expand >>    ******Hidden until clicked******** >>    ==Heading 2== >>    ===Heading 3=== >>    Normal text, etc... >> >> Object 2 Name - Click to expand >>    ******Hidden until clicked******** >>    ==Heading 2== >>    ===Heading 3=== >>    Normal text, etc... >> >> Object 3 Name - Click to expand >>    ******Hidden until clicked******** >>    ==Heading 2== >>    ===Heading 3=== >>    Normal text, etc... >> >> >> I would like the TOC to return: >> >> Object 1 >>  Heading 2 >>  Heading 3 >> Object 2 >>  Heading 2 >>  Heading 3 >> Object 3 >>  Heading 2 >>  Heading 3 >> >> Even when all the div's are initially collapsed/hidden. It would be >> ideal if the TOC was clickable and went to the relevant anchor... > > Are the divs done using html macro or using wiki syntax ? > >> >> I can obviously use getValue() with each TextArea property to return a >> string with that objects wiki syntax - but I don't have an easy way to >> parse that string to only return the heading levels... >> >> Any guidance would be appreciated. >> >> Thanks, >> >> aaron >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Thomas Mortagne > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Hi Aaron, I did the following test with XWiki Enterprise 3.2 and it worked: 1. I created a class Sandbox.TestClass with just one field of type TextArea, setting the "Editor" property to "Wysiwyg" (from class edit mode). 2. I added an object of type Sandbox.TestClass to the same page and put some text in the text area (from object edit mode). 3. I set the content of the Sandbox.TestClass page to (from wiki edit mode) ----------8<---------- {{velocity}} $doc.display('description') $context.getEditorWysiwyg() {{/velocity}} ---------->8---------- 4. I edited Sandbox.TestClass in "Inline form" edit mode (/xwiki/bin/edit/Sandbox/TestClass?editor=inline). The WYSIWYG editor was loaded and below it I could see "Sandbox.TestClass_0_description". As you can see I didn't use the HTML macro, just the Velocity one. I don't understand why it works in your case with the HTML macro and not without it. Are you sure you're using the "Inline form" edit mode? Note that $doc.display method call outputs the same thing, a plain HTML text area, no matter what editor you set in the class field definition or in your user preferences. The difference comes from the fact that when the editor is set to "Wysiwyg" the field identifier (e.g. "Sandbox.TestClass_0_description") is added (by $doc.display) to a list that can be retrieved with $context.getEditorWysiwyg(). The code that actually loads the WYSIWYG editor is in textarea_wysiwyg.vm template (included in editinline.vm template used by "Inline form" edit mode), which iterates the list returned by $context.getEditorWysiwyg() and replaces the specified fields with the WYSIWYG editor. If in your case $context.getEditorWysiwyg() is not evaluated (you put it inside the Velocity macro right? and after all $doc.display calls) then it's not surprising that no WYSIWYG editor is loaded. Hope this helps, Marius On Tue, Nov 8, 2011 at 2:26 PM, Ashtar Communications <[email protected]> wrote:

Thomas,

Putting the line: $context.getEditorWysiwyg() in my sheet just results in that text being displayed on the page. Do I need to do something else to have that picked up by velocity? I'm sure I'm missing some obvious syntax ...it's late...:)

The WYSIWYGText property has the default editor set to WYSIWYG, the PlainText property has it set to the plain text editor (obviously). Using the HTML macro, the WYSIWYG editor appears for that property - using wiki syntax, both show up as the Plain Text editor.

The code I am using is below:

{{velocity}} ##Includes for mktree$xwiki.jsfx.use('js/mktree/mktree.js')$xwiki.ssfx.use('js/mktree/mktree.css', true) ##Includes for table sort$xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js")$xwiki.ssfx.use("js/xwiki/table/table.css") ##Include for Entry Class CSS$xwiki.ssfx.use('css/entryclass.css', true)

#set($objs = $doc.getObjects('Admin.EntryClass')) #set($action = $xcontext.getAction())

(% class="grid sortable doOddEven" id="Entry Table" %) (% class="sortHeader" %)|=#|=Entry|=Entry Date #foreach($entry in $objs) |$doc.display("SortOrder", $entry)|((( (% class="mktree" name="tree" %) * ((( (% class="title" %) =$doc.display("Title", $entry)= ))) ** (((  #if($action != "view")    WYSIWYG:  #end

 $doc.display("WYSIWYGText", $entry) ))) ** (((  #if($action != "view")    Plain Text:  #end

 $doc.display("PlainText", $entry) ))) )))|$doc.display("EntryDate", $entry) #end

{{toc /}}

{{/velocity}}

thanks,

aaron

On Tue, Nov 8, 2011 at 2:37 AM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

On Tue, Nov 8, 2011 at 12:08 PM, Ashtar Communications <[email protected]> wrote:

...

Thomas,

Thank for very much for your suggestion. The group syntax was exactly what I needed.

However, I am still having some trouble with getting the TOC macro to correctly pick up wiki syntax rendered with $doc.display() that is contained in an object's property.

I have also noticed that using wiki syntax instead of html, $doc.display seems to behave differently and overrides the default editor setting.

Here is my example - I am using wiki syntax similar to the following (simplified for example's sake):

************START CODE**************** (% class="grid sortable doOddEven" id="Table" %) (% class="sortHeader" %)|=Field 1|=Field 2 |Data 1|((( (% class="mktree" name="tree" %) * ((( =$doc.display("String", $object)= ))) ** ((( $doc.display("TextArea", $object) ))) )))

{{toc /}} ************END CODE****************

The TextArea property contains a large quantity of text formatted in xwiki syntax. The display works just fine - the contents of the property render correctly and display in the table.

Two problems:

1) The TOC macro only recognizes the String property that I manually enclose in "=" Heading 1 syntax. It doesn't seem to be picking up the wiki syntax contained in the object properties. So if I had 3 objects on the page, I get:

*String 1 *String 2 *String 3

Instead of:

*String 1  **Heading 2 from TextArea**  **Heading 2 from TextArea** *String 2 Etc....

I'm afraid I don't know very much about the order of macro rendering or whether it is even possible to accomplish what I am describing...

2) When I use the Inline editing mode, another TextArea property of the object (not shown in the code above) does not show up with the WYSIWYG editor, even though it is set as the default editor. When using the {{html}} macro and code like this:

<li>$doc.display("TextAreaWYSIWYG", $object)</li>

The property correctly displays in Inline mode with the WYSIWYG editor. Now that I am using only wiki syntax to display the table, all TextArea properties show up in the Plain Text editor, regardless of their default setting. Am I doing something wrong?

Can you paste the code that doesn't work? (i.e. without using the HTML macro). Also, can you print this:

$context.getEditorWysiwyg()

at the end of your sheet. It will display a comma-separated list of field IDs that require WYSIWYG editing. Are your fields listed there when editing in Inline mode?

Hope this helps, Marius

...

Many thanks for all of the help, I have made very significant progress on my project thanks to this list...

aaron

On Sun, Oct 23, 2011 at 1:50 AM, Thomas Mortagne <[email protected]> wrote:

...

On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications <[email protected]> wrote:

...

Thank you for the feedback - I have been playing with passing custom parameters, and have a few additional clarification questions.

It seems that I need to use pure wiki syntax if I want the TOC macro to work right. I am currently relying on the {{html}} macro for two things which I can't figure out how to replace with custom parameters:

1) Nested <ul>'s - I can only get the custom parameter to apply to one line, and can't figure out how to nest another <ul>.

Something like this: (% class="mktree" name="tree" %) * $doc.display("Title", $obj)  <velocity code, including an {{html}} block to create an <input> element> **Additional parts of tree ***Additional parts of tree

Just returns two different <ul>'s, only the first one of which has the custom parameter. Is this because the additional lines of code before continuing the tree forces the rendering engine to close the first <ul>? Any way to override that?

Here is an example of wiki syntax with custom parameters on each ul:

(% param=value %) * toto (% param2=value2 %) ** titi

but custom parameters on li is not supported yet.

...

2) Table Sorter - Unfortunately, the whole set of object display code is wrapped in an {{html}} macro because I am using the old Table Sorter extension code. This is because I want to display multiple properties from each object in a single table cell. Looking at the Live Table macro, it seems that it only supports binding a table to a class and then setting a column to display a single property - where I need a single cell to include multiple properties displayed using custom code.

Accomplishing this using the html syntax is simple - I can include an arbitrary amount of code in each <td> tag.

To use wiki syntax for a sortable table, the XWiki Syntax document says I should use this:

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|Cell 12 |Cell 21|Cell 22

This creates the table fine - but I can't figure out how to include additional multi-line code in a single cell. As soon as I put in a new line, etc...it closes the table. Is there any way to accomplish this using wiki syntax? Should I be trying to use LiveTable instead somehow?

You can put as many lines you want without closing the table but it's closed by an empty line. If you need to have several paragraphs you can use "group"  syntax (http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HGroups) as in

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|((( Cell 12

with

several

paragraphs )))|Cell 21|Cell 22

...

If the above is confusing, here's what I'm really asking:

I want to use a sortable table to display multiple objects of the same class on the same page. I would like that table to display multiple properties of each object in certain cells in the row. Some of those properties will contain wiki syntax - which I would like to be readable by the TOC macro after the table has been rendered. Is there a way to accomplish this?

Thank you,

Aaron

On Thu, Oct 20, 2011 at 1:18 PM, Ashtar Communications <[email protected]> wrote:

...

Interesting - I had missed the ability to pass custom parameters using wiki syntax. I will play with that and see if I can get it to output the same html I need.

I am in fact using a series of nested <ul> within each <div>, that forms a collapsible javascript tree. The js is touchy about the exact formatting of the UL - if I can't get the tags to nest correctly using wiki syntax then I may be back with additional questions.

A more accurate but simplified version of each object's display code is:

<ul class="tree">  <li>  <h2>some content</h2>  <input />  <input />  </li>  <ul>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>      <li>Some velocity code, returns wiki syntax with headings</li>  </ul> </ul>

Thanks much,

aaron

On Thu, Oct 20, 2011 at 12:52 PM, Thomas Mortagne <[email protected]> wrote: > On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications > <[email protected]> wrote: >> That makes sense, thank you for the clarification. Unfortunately, I am >> using the HTML macro to generate the final output - this is because I >> need to use <ul>'s with a javascript to make the div's into >> collapsible trees. >> >> Does that mean I'm out of luck? > > <ul> ? I don't see much lists in your example, did you mean div ? > > You can get div with custom parameters in pure wiki syntax the following way: > > (% class="somecssclass" %) > ((( > div content > ))) > > which produces > > <div class="somecssclass">div content</div> > > And if you really mean list, list most of the wiki elements list > support custom parameters too: > > (% class="somecssclass" %) > * mylist element 1 > * mylist element 2 > > which produces > > <ul class="somecssclass"> > <li>mylist element 1</li> > <li>mylist element 2</li> > </ul > > You can put anything you want in custom parameters and html renderer > will print them as you provided them depending of the element. > > Using the html macro should always be the last resort, usually when > you get some html you don't really have control on that you need to > display or when you need to display elements not supported by the wiki > syntax (yet) like <form> related stuff. > >> >> On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne >> <[email protected]> wrote: >>> On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications >>> <[email protected]> wrote: >>>> One more tonight... >>>> >>>> It seems that I am unable to use the built-in TOC macro for wiki >>>> content which is generated dynamically from a Class Sheet {{include}}. >>>> I assume this is because the TOC macro is rendered before (or >>>> simultaneously with) the include macro which actually displays the >>>> objects on the page, so as far as the TOC macro knows, there are no >>>> wiki headings on the page (yet) to create an outline from. >>> >>> Actually no, there is a concept of priority in macros and TOC macro >>> priority is very low specifically to support use case like that. But >>> TOC only support (generated or not) real wiki content which mean if >>> you have anything in a html macro it will not support it because html >>> macro produce a RawBlock which is a black box containing html syntax >>> for other macros. >>> >>> So if you use case is just what you described it should work well. >>> >>>> >>>> Does anyone have any suggestions on how to parse through the final >>>> rendered output of the wiki page to generate a table of contents for >>>> dynamically generated wiki content? If I'm missing something with the >>>> existing macro, that would be great... >>>> >>>> What I am looking to do is write some code (preferably in a panel, I >>>> think), which creates a TOC-style index of all the wiki-syntax >>>> headings contained on the fully rendered page, after the content has >>>> been generated from TextArea properties of a set of attached objects >>>> to the page. >>>> >>>> I have written custom display code that loops through every object of >>>> a custom class attached to a page and then displays some of that >>>> objects properties in a series of collapsible div's. Each object >>>> contains two TextArea properties - one for WYSIWYG data, and one for >>>> plain text, which would be formatted in wiki syntax. The result is a >>>> list of each objects name with an expandable <div> full of the >>>> wiki-rendered content contained in the TextArea properties. I would >>>> like to generate a TOC which "reads through" that content and comes up >>>> with a list of only the relevant headings under each displayed >>>> "object" >>>> >>>> For example, on a page with 3 objects, the custom display code in the >>>> Class Sheet results in this (the wiki syntax appears fully rendered, >>>> obviously): >>>> >>>> Object 1 Name - Click to expand >>>>    ******Hidden until clicked******** >>>>    ==Heading 2== >>>>    ===Heading 3=== >>>>    Normal text, etc... >>>> >>>> Object 2 Name - Click to expand >>>>    ******Hidden until clicked******** >>>>    ==Heading 2== >>>>    ===Heading 3=== >>>>    Normal text, etc... >>>> >>>> Object 3 Name - Click to expand >>>>    ******Hidden until clicked******** >>>>    ==Heading 2== >>>>    ===Heading 3=== >>>>    Normal text, etc... >>>> >>>> >>>> I would like the TOC to return: >>>> >>>> Object 1 >>>>  Heading 2 >>>>  Heading 3 >>>> Object 2 >>>>  Heading 2 >>>>  Heading 3 >>>> Object 3 >>>>  Heading 2 >>>>  Heading 3 >>>> >>>> Even when all the div's are initially collapsed/hidden. It would be >>>> ideal if the TOC was clickable and went to the relevant anchor... >>> >>> Are the divs done using html macro or using wiki syntax ? >>> >>>> >>>> I can obviously use getValue() with each TextArea property to return a >>>> string with that objects wiki syntax - but I don't have an easy way to >>>> parse that string to only return the heading levels... >>>> >>>> Any guidance would be appreciated. >>>> >>>> Thanks, >>>> >>>> aaron >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/users >>>> >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/users >>> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Thomas Mortagne > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users >

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Hi Aaron, See my comments below, On Sat, Nov 12, 2011 at 7:58 PM, Ashtar Communications <[email protected]> wrote:

Marius,

I successfully reproduced the steps you followed on XEM 3.1 - $context.getEditorWysiwyg() is being correctly evaluated while in inline mode. However, when the textbox is displayed as part of the non-html table, it still does not render as WYSIWYG.

When I follow your steps here, viewing the page as normal just prints the text $context.getEditorWysiwyg() on the page. However, when I switch to inline mode, this changes to: Sandbox.TestClass_0_description

This is the expected behavior.

On the test Sandbox page, the text box then displays correctly as WYSIWYG.

However, when I try this same thing on the page with the table, it doesn't work. When in Inline mode, $context.getEditorWysiwyg() still displays:

Sandbox.TestClass_0_description,Sandbox.TestClass_1_description,Sandbox.TestClass_2_description

So you added multiple objects of type Sandbox.TestClass to your page.

etc...

However, the box being displayed in the table still appears as plain text. Try the following code on the same Sandbox page with the TestClass.

{{velocity}} $xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js") $xwiki.ssfx.use("js/xwiki/table/table.css")

{{html}} <table id="Table1" class="grid sortable doOddEven">  <tr class="sortHeader"><th>Header</th></tr>  <tr><td>$doc.display('description')</td></tr> {{/html}}

You forgot the closing </table> tag which makes the HTML invalid. By default HTML macro cleans its content and if the content is not valid then the result is sometimes unexpected. Also, the $doc.display call outputs wiki syntax (an HTML macro) so you have to add wiki="true" to the outer HTML macro in order for it to be rendered properly.

(% class="grid sortable doOddEven" id="Table2" %)(% class="sortHeader" %)|=Header|$doc.display('description') {{toc /}}

This needs to be formated properly. ToC macro can't be displayed inline.

$context.getEditorWysiwyg(){{/velocity}}

For me, this produces two tables. The top table displays a WYSIWG box (two, actually, which is strange). The bottom table displays a PlainText box.

The reason is simple: you display the same property of the same object twice, which means you'll have two text areas with the same ID in your page which (1) makes your page HTML-invalid and (2) makes the WYSIWYG editor enhance twice the first text area. I changed your code to: ----------8<---------- {{velocity}} $xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js") $xwiki.ssfx.use("js/xwiki/table/table.css") {{html wiki="true"}} <table id="Table1" class="grid sortable doOddEven"> <tr class="sortHeader"><th>Header</th></tr> <tr><td>$doc.display('description', $doc.getObject('Sandbox.TestClass', 0))</td></tr> </table> {{/html}} (% class="grid sortable doOddEven" id="Table2" %)(% class="sortHeader"%) |=Header |$doc.display('description', $doc.getObject('Sandbox.TestClass', 1)) {{toc /}} $context.getEditorWysiwyg() {{/velocity}} ---------->8---------- and the WYSIWYG editor is loaded for both text areas.

Additionally, when there's wiki syntax in the content of the TextBox, it is not being picked up by the TOC macro.

I don't think the ToC macro looks for headings inside tables. I think it picks only the headings that are direct children of the xwikicontent DIV (in view mode). Hope this helps, Marius

So, it appears that this is somehow related to the table?

aaron

On Thu, Nov 10, 2011 at 11:39 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

I did the following test with XWiki Enterprise 3.2 and it worked:

1. I created a class Sandbox.TestClass with just one field of type TextArea, setting the "Editor" property to "Wysiwyg" (from class edit mode). 2. I added an object of type Sandbox.TestClass to the same page and put some text in the text area (from object edit mode). 3. I set the content of the Sandbox.TestClass page to (from wiki edit mode)

----------8<---------- {{velocity}} $doc.display('description')

$context.getEditorWysiwyg() {{/velocity}} ---------->8----------

4. I edited Sandbox.TestClass in "Inline form" edit mode (/xwiki/bin/edit/Sandbox/TestClass?editor=inline). The WYSIWYG editor was loaded and below it I could see "Sandbox.TestClass_0_description".

As you can see I didn't use the HTML macro, just the Velocity one. I don't understand why it works in your case with the HTML macro and not without it. Are you sure you're using the "Inline form" edit mode?

Note that $doc.display method call outputs the same thing, a plain HTML text area, no matter what editor you set in the class field definition or in your user preferences. The difference comes from the fact that when the editor is set to "Wysiwyg" the field identifier (e.g. "Sandbox.TestClass_0_description") is added (by $doc.display) to a list that can be retrieved with $context.getEditorWysiwyg(). The code that actually loads the WYSIWYG editor is in textarea_wysiwyg.vm template (included in editinline.vm template used by "Inline form" edit mode), which iterates the list returned by $context.getEditorWysiwyg() and replaces the specified fields with the WYSIWYG editor.

If in your case $context.getEditorWysiwyg() is not evaluated (you put it inside the Velocity macro right? and after all $doc.display calls) then it's not surprising that no WYSIWYG editor is loaded.

Hope this helps, Marius

On Tue, Nov 8, 2011 at 2:26 PM, Ashtar Communications <[email protected]> wrote:

...

Thomas,

Putting the line: $context.getEditorWysiwyg() in my sheet just results in that text being displayed on the page. Do I need to do something else to have that picked up by velocity? I'm sure I'm missing some obvious syntax ...it's late...:)

The WYSIWYGText property has the default editor set to WYSIWYG, the PlainText property has it set to the plain text editor (obviously). Using the HTML macro, the WYSIWYG editor appears for that property - using wiki syntax, both show up as the Plain Text editor.

The code I am using is below:

{{velocity}} ##Includes for mktree$xwiki.jsfx.use('js/mktree/mktree.js')$xwiki.ssfx.use('js/mktree/mktree.css', true) ##Includes for table sort$xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js")$xwiki.ssfx.use("js/xwiki/table/table.css") ##Include for Entry Class CSS$xwiki.ssfx.use('css/entryclass.css', true)

#set($objs = $doc.getObjects('Admin.EntryClass')) #set($action = $xcontext.getAction())

(% class="grid sortable doOddEven" id="Entry Table" %) (% class="sortHeader" %)|=#|=Entry|=Entry Date #foreach($entry in $objs) |$doc.display("SortOrder", $entry)|((( (% class="mktree" name="tree" %) * ((( (% class="title" %) =$doc.display("Title", $entry)= ))) ** (((  #if($action != "view")    WYSIWYG:  #end

 $doc.display("WYSIWYGText", $entry) ))) ** (((  #if($action != "view")    Plain Text:  #end

 $doc.display("PlainText", $entry) ))) )))|$doc.display("EntryDate", $entry) #end

{{toc /}}

{{/velocity}}

thanks,

aaron

On Tue, Nov 8, 2011 at 2:37 AM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

On Tue, Nov 8, 2011 at 12:08 PM, Ashtar Communications <[email protected]> wrote:

...

Thomas,

Thank for very much for your suggestion. The group syntax was exactly what I needed.

However, I am still having some trouble with getting the TOC macro to correctly pick up wiki syntax rendered with $doc.display() that is contained in an object's property.

I have also noticed that using wiki syntax instead of html, $doc.display seems to behave differently and overrides the default editor setting.

Here is my example - I am using wiki syntax similar to the following (simplified for example's sake):

************START CODE**************** (% class="grid sortable doOddEven" id="Table" %) (% class="sortHeader" %)|=Field 1|=Field 2 |Data 1|((( (% class="mktree" name="tree" %) * ((( =$doc.display("String", $object)= ))) ** ((( $doc.display("TextArea", $object) ))) )))

{{toc /}} ************END CODE****************

The TextArea property contains a large quantity of text formatted in xwiki syntax. The display works just fine - the contents of the property render correctly and display in the table.

Two problems:

1) The TOC macro only recognizes the String property that I manually enclose in "=" Heading 1 syntax. It doesn't seem to be picking up the wiki syntax contained in the object properties. So if I had 3 objects on the page, I get:

*String 1 *String 2 *String 3

Instead of:

*String 1  **Heading 2 from TextArea**  **Heading 2 from TextArea** *String 2 Etc....

I'm afraid I don't know very much about the order of macro rendering or whether it is even possible to accomplish what I am describing...

2) When I use the Inline editing mode, another TextArea property of the object (not shown in the code above) does not show up with the WYSIWYG editor, even though it is set as the default editor. When using the {{html}} macro and code like this:

<li>$doc.display("TextAreaWYSIWYG", $object)</li>

The property correctly displays in Inline mode with the WYSIWYG editor. Now that I am using only wiki syntax to display the table, all TextArea properties show up in the Plain Text editor, regardless of their default setting. Am I doing something wrong?

Can you paste the code that doesn't work? (i.e. without using the HTML macro). Also, can you print this:

$context.getEditorWysiwyg()

at the end of your sheet. It will display a comma-separated list of field IDs that require WYSIWYG editing. Are your fields listed there when editing in Inline mode?

Hope this helps, Marius

...

Many thanks for all of the help, I have made very significant progress on my project thanks to this list...

aaron

On Sun, Oct 23, 2011 at 1:50 AM, Thomas Mortagne <[email protected]> wrote:

...

On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications <[email protected]> wrote: > Thank you for the feedback - I have been playing with passing custom > parameters, and have a few additional clarification questions. > > It seems that I need to use pure wiki syntax if I want the TOC macro > to work right. I am currently relying on the {{html}} macro for two > things which I can't figure out how to replace with custom parameters: > > 1) Nested <ul>'s - I can only get the custom parameter to apply to one > line, and can't figure out how to nest another <ul>. > > Something like this: > (% class="mktree" name="tree" %) > * $doc.display("Title", $obj) >  <velocity code, including an {{html}} block to create an <input> element> > **Additional parts of tree > ***Additional parts of tree > > Just returns two different <ul>'s, only the first one of which has the > custom parameter. Is this because the additional lines of code before > continuing the tree forces the rendering engine to close the first > <ul>? Any way to override that?

Here is an example of wiki syntax with custom parameters on each ul:

(% param=value %) * toto (% param2=value2 %) ** titi

but custom parameters on li is not supported yet.

> > 2) Table Sorter - Unfortunately, the whole set of object display code > is wrapped in an {{html}} macro because I am using the old Table > Sorter extension code. This is because I want to display multiple > properties from each object in a single table cell. Looking at the > Live Table macro, it seems that it only supports binding a table to a > class and then setting a column to display a single property - where I > need a single cell to include multiple properties displayed using > custom code. > > Accomplishing this using the html syntax is simple - I can include an > arbitrary amount of code in each <td> tag. > > To use wiki syntax for a sortable table, the XWiki Syntax document > says I should use this: > > (% class="grid sortable filterable doOddEven" id="tableid" %) > (% class="sortHeader" %)|=Title 1|=Title 2 > |Cell 11|Cell 12 > |Cell 21|Cell 22 > > This creates the table fine - but I can't figure out how to include > additional multi-line code in a single cell. As soon as I put in a new > line, etc...it closes the table. Is there any way to accomplish this > using wiki syntax? Should I be trying to use LiveTable instead > somehow?

You can put as many lines you want without closing the table but it's closed by an empty line. If you need to have several paragraphs you can use "group"  syntax (http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HGroups) as in

(% class="grid sortable filterable doOddEven" id="tableid" %) (% class="sortHeader" %)|=Title 1|=Title 2 |Cell 11|((( Cell 12

with

several

paragraphs )))|Cell 21|Cell 22

> > If the above is confusing, here's what I'm really asking: > > I want to use a sortable table to display multiple objects of the same > class on the same page. I would like that table to display multiple > properties of each object in certain cells in the row. Some of those > properties will contain wiki syntax - which I would like to be > readable by the TOC macro after the table has been rendered. Is there > a way to accomplish this? > > Thank you, > > Aaron > > On Thu, Oct 20, 2011 at 1:18 PM, Ashtar Communications > <[email protected]> wrote: >> Interesting - I had missed the ability to pass custom parameters using >> wiki syntax. I will play with that and see if I can get it to output >> the same html I need. >> >> I am in fact using a series of nested <ul> within each <div>, that >> forms a collapsible javascript tree. The js is touchy about the exact >> formatting of the UL - if I can't get the tags to nest correctly using >> wiki syntax then I may be back with additional questions. >> >> A more accurate but simplified version of each object's display code is: >> >> <ul class="tree"> >>  <li> >>  <h2>some content</h2> >>  <input /> >>  <input /> >>  </li> >>  <ul> >>      <li>Some velocity code, returns wiki syntax with headings</li> >>      <li>Some velocity code, returns wiki syntax with headings</li> >>      <li>Some velocity code, returns wiki syntax with headings</li> >>  </ul> >> </ul> >> >> Thanks much, >> >> aaron >> >> On Thu, Oct 20, 2011 at 12:52 PM, Thomas Mortagne >> <[email protected]> wrote: >>> On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications >>> <[email protected]> wrote: >>>> That makes sense, thank you for the clarification. Unfortunately, I am >>>> using the HTML macro to generate the final output - this is because I >>>> need to use <ul>'s with a javascript to make the div's into >>>> collapsible trees. >>>> >>>> Does that mean I'm out of luck? >>> >>> <ul> ? I don't see much lists in your example, did you mean div ? >>> >>> You can get div with custom parameters in pure wiki syntax the following way: >>> >>> (% class="somecssclass" %) >>> ((( >>> div content >>> ))) >>> >>> which produces >>> >>> <div class="somecssclass">div content</div> >>> >>> And if you really mean list, list most of the wiki elements list >>> support custom parameters too: >>> >>> (% class="somecssclass" %) >>> * mylist element 1 >>> * mylist element 2 >>> >>> which produces >>> >>> <ul class="somecssclass"> >>> <li>mylist element 1</li> >>> <li>mylist element 2</li> >>> </ul >>> >>> You can put anything you want in custom parameters and html renderer >>> will print them as you provided them depending of the element. >>> >>> Using the html macro should always be the last resort, usually when >>> you get some html you don't really have control on that you need to >>> display or when you need to display elements not supported by the wiki >>> syntax (yet) like <form> related stuff. >>> >>>> >>>> On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications >>>>> <[email protected]> wrote: >>>>>> One more tonight... >>>>>> >>>>>> It seems that I am unable to use the built-in TOC macro for wiki >>>>>> content which is generated dynamically from a Class Sheet {{include}}. >>>>>> I assume this is because the TOC macro is rendered before (or >>>>>> simultaneously with) the include macro which actually displays the >>>>>> objects on the page, so as far as the TOC macro knows, there are no >>>>>> wiki headings on the page (yet) to create an outline from. >>>>> >>>>> Actually no, there is a concept of priority in macros and TOC macro >>>>> priority is very low specifically to support use case like that. But >>>>> TOC only support (generated or not) real wiki content which mean if >>>>> you have anything in a html macro it will not support it because html >>>>> macro produce a RawBlock which is a black box containing html syntax >>>>> for other macros. >>>>> >>>>> So if you use case is just what you described it should work well. >>>>> >>>>>> >>>>>> Does anyone have any suggestions on how to parse through the final >>>>>> rendered output of the wiki page to generate a table of contents for >>>>>> dynamically generated wiki content? If I'm missing something with the >>>>>> existing macro, that would be great... >>>>>> >>>>>> What I am looking to do is write some code (preferably in a panel, I >>>>>> think), which creates a TOC-style index of all the wiki-syntax >>>>>> headings contained on the fully rendered page, after the content has >>>>>> been generated from TextArea properties of a set of attached objects >>>>>> to the page. >>>>>> >>>>>> I have written custom display code that loops through every object of >>>>>> a custom class attached to a page and then displays some of that >>>>>> objects properties in a series of collapsible div's. Each object >>>>>> contains two TextArea properties - one for WYSIWYG data, and one for >>>>>> plain text, which would be formatted in wiki syntax. The result is a >>>>>> list of each objects name with an expandable <div> full of the >>>>>> wiki-rendered content contained in the TextArea properties. I would >>>>>> like to generate a TOC which "reads through" that content and comes up >>>>>> with a list of only the relevant headings under each displayed >>>>>> "object" >>>>>> >>>>>> For example, on a page with 3 objects, the custom display code in the >>>>>> Class Sheet results in this (the wiki syntax appears fully rendered, >>>>>> obviously): >>>>>> >>>>>> Object 1 Name - Click to expand >>>>>>    ******Hidden until clicked******** >>>>>>    ==Heading 2== >>>>>>    ===Heading 3=== >>>>>>    Normal text, etc... >>>>>> >>>>>> Object 2 Name - Click to expand >>>>>>    ******Hidden until clicked******** >>>>>>    ==Heading 2== >>>>>>    ===Heading 3=== >>>>>>    Normal text, etc... >>>>>> >>>>>> Object 3 Name - Click to expand >>>>>>    ******Hidden until clicked******** >>>>>>    ==Heading 2== >>>>>>    ===Heading 3=== >>>>>>    Normal text, etc... >>>>>> >>>>>> >>>>>> I would like the TOC to return: >>>>>> >>>>>> Object 1 >>>>>>  Heading 2 >>>>>>  Heading 3 >>>>>> Object 2 >>>>>>  Heading 2 >>>>>>  Heading 3 >>>>>> Object 3 >>>>>>  Heading 2 >>>>>>  Heading 3 >>>>>> >>>>>> Even when all the div's are initially collapsed/hidden. It would be >>>>>> ideal if the TOC was clickable and went to the relevant anchor... >>>>> >>>>> Are the divs done using html macro or using wiki syntax ? >>>>> >>>>>> >>>>>> I can obviously use getValue() with each TextArea property to return a >>>>>> string with that objects wiki syntax - but I don't have an easy way to >>>>>> parse that string to only return the heading levels... >>>>>> >>>>>> Any guidance would be appreciated. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> aaron >>>>>> _______________________________________________ >>>>>> users mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/users >>>> >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/users >>> >> > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users >

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

On Thu, Nov 17, 2011 at 1:11 PM, Ashtar Communications <[email protected]> wrote:

Marius,

Thank you for the syntax fixes. Your changes work perfectly - I forgot that each item would have the same HTML id if displayed twice.

The only problem I am now having is that the TOC macro still seems to not pick up the wiki headings contained in the objects property when using $doc.display. If I add an object with a TextArea property containing wiki syntax, like: =Heading1= ==Heading2== ===Heading3===

Then:

{{velocity}}

$doc.display('textarea', $doc.getObject('Sandbox.TestClass', 0))

{{toc /}}

{{/velocity}}

The wiki syntax displays just fine, but the TOC macro doesn't display anything. Is this expected behavior, or am I missing a way to have the TOC macro pick up these headings?

Problem is that $doc.display produce html macro which is a black box for toc macro.

Thank you,

aaron

On Wed, Nov 16, 2011 at 12:51 AM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

See my comments below,

On Sat, Nov 12, 2011 at 7:58 PM, Ashtar Communications <[email protected]> wrote:

...

Marius,

I successfully reproduced the steps you followed on XEM 3.1 - $context.getEditorWysiwyg() is being correctly evaluated while in inline mode. However, when the textbox is displayed as part of the non-html table, it still does not render as WYSIWYG.

...

When I follow your steps here, viewing the page as normal just prints the text $context.getEditorWysiwyg() on the page. However, when I switch to inline mode, this changes to: Sandbox.TestClass_0_description

This is the expected behavior.

...

On the test Sandbox page, the text box then displays correctly as WYSIWYG.

However, when I try this same thing on the page with the table, it doesn't work. When in Inline mode, $context.getEditorWysiwyg() still displays:

...

Sandbox.TestClass_0_description,Sandbox.TestClass_1_description,Sandbox.TestClass_2_description

So you added multiple objects of type Sandbox.TestClass to your page.

...

etc...

However, the box being displayed in the table still appears as plain text. Try the following code on the same Sandbox page with the TestClass.

{{velocity}} $xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js") $xwiki.ssfx.use("js/xwiki/table/table.css")

{{html}} <table id="Table1" class="grid sortable doOddEven">  <tr class="sortHeader"><th>Header</th></tr>  <tr><td>$doc.display('description')</td></tr> {{/html}}

You forgot the closing </table> tag which makes the HTML invalid. By default HTML macro cleans its content and if the content is not valid then the result is sometimes unexpected. Also, the $doc.display call outputs wiki syntax (an HTML macro) so you have to add wiki="true" to the outer HTML macro in order for it to be rendered properly.

...

(% class="grid sortable doOddEven" id="Table2" %)(% class="sortHeader" %)|=Header|$doc.display('description') {{toc /}}

This needs to be formated properly. ToC macro can't be displayed inline.

...

$context.getEditorWysiwyg(){{/velocity}}

For me, this produces two tables. The top table displays a WYSIWG box (two, actually, which is strange). The bottom table displays a PlainText box.

The reason is simple: you display the same property of the same object twice, which means you'll have two text areas with the same ID in your page which (1) makes your page HTML-invalid and (2) makes the WYSIWYG editor enhance twice the first text area.

I changed your code to:

----------8<---------- {{velocity}} $xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js") $xwiki.ssfx.use("js/xwiki/table/table.css")

{{html wiki="true"}} <table id="Table1" class="grid sortable doOddEven">  <tr class="sortHeader"><th>Header</th></tr>  <tr><td>$doc.display('description', $doc.getObject('Sandbox.TestClass', 0))</td></tr> </table> {{/html}}

(% class="grid sortable doOddEven" id="Table2" %)(% class="sortHeader"%) |=Header |$doc.display('description', $doc.getObject('Sandbox.TestClass', 1))

{{toc /}}

$context.getEditorWysiwyg() {{/velocity}} ---------->8----------

and the WYSIWYG editor is loaded for both text areas.

...

...

Additionally, when there's wiki syntax in the content of the TextBox, it is not being picked up by the TOC macro.

I don't think the ToC macro looks for headings inside tables. I think it picks only the headings that are direct children of the xwikicontent DIV (in view mode).

Hope this helps, Marius

...

So, it appears that this is somehow related to the table?

aaron

On Thu, Nov 10, 2011 at 11:39 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

I did the following test with XWiki Enterprise 3.2 and it worked:

1. I created a class Sandbox.TestClass with just one field of type TextArea, setting the "Editor" property to "Wysiwyg" (from class edit mode). 2. I added an object of type Sandbox.TestClass to the same page and put some text in the text area (from object edit mode). 3. I set the content of the Sandbox.TestClass page to (from wiki edit mode)

----------8<---------- {{velocity}} $doc.display('description')

$context.getEditorWysiwyg() {{/velocity}} ---------->8----------

4. I edited Sandbox.TestClass in "Inline form" edit mode (/xwiki/bin/edit/Sandbox/TestClass?editor=inline). The WYSIWYG editor was loaded and below it I could see "Sandbox.TestClass_0_description".

As you can see I didn't use the HTML macro, just the Velocity one. I don't understand why it works in your case with the HTML macro and not without it. Are you sure you're using the "Inline form" edit mode?

Note that $doc.display method call outputs the same thing, a plain HTML text area, no matter what editor you set in the class field definition or in your user preferences. The difference comes from the fact that when the editor is set to "Wysiwyg" the field identifier (e.g. "Sandbox.TestClass_0_description") is added (by $doc.display) to a list that can be retrieved with $context.getEditorWysiwyg(). The code that actually loads the WYSIWYG editor is in textarea_wysiwyg.vm template (included in editinline.vm template used by "Inline form" edit mode), which iterates the list returned by $context.getEditorWysiwyg() and replaces the specified fields with the WYSIWYG editor.

If in your case $context.getEditorWysiwyg() is not evaluated (you put it inside the Velocity macro right? and after all $doc.display calls) then it's not surprising that no WYSIWYG editor is loaded.

Hope this helps, Marius

On Tue, Nov 8, 2011 at 2:26 PM, Ashtar Communications <[email protected]> wrote:

...

Thomas,

Putting the line: $context.getEditorWysiwyg() in my sheet just results in that text being displayed on the page. Do I need to do something else to have that picked up by velocity? I'm sure I'm missing some obvious syntax ...it's late...:)

The WYSIWYGText property has the default editor set to WYSIWYG, the PlainText property has it set to the plain text editor (obviously). Using the HTML macro, the WYSIWYG editor appears for that property - using wiki syntax, both show up as the Plain Text editor.

The code I am using is below:

{{velocity}} ##Includes for mktree$xwiki.jsfx.use('js/mktree/mktree.js')$xwiki.ssfx.use('js/mktree/mktree.css', true) ##Includes for table sort$xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js")$xwiki.ssfx.use("js/xwiki/table/table.css") ##Include for Entry Class CSS$xwiki.ssfx.use('css/entryclass.css', true)

#set($objs = $doc.getObjects('Admin.EntryClass')) #set($action = $xcontext.getAction())

(% class="grid sortable doOddEven" id="Entry Table" %) (% class="sortHeader" %)|=#|=Entry|=Entry Date #foreach($entry in $objs) |$doc.display("SortOrder", $entry)|((( (% class="mktree" name="tree" %) * ((( (% class="title" %) =$doc.display("Title", $entry)= ))) ** (((  #if($action != "view")    WYSIWYG:  #end

 $doc.display("WYSIWYGText", $entry) ))) ** (((  #if($action != "view")    Plain Text:  #end

 $doc.display("PlainText", $entry) ))) )))|$doc.display("EntryDate", $entry) #end

{{toc /}}

{{/velocity}}

thanks,

aaron

On Tue, Nov 8, 2011 at 2:37 AM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi Aaron,

On Tue, Nov 8, 2011 at 12:08 PM, Ashtar Communications <[email protected]> wrote: > Thomas, > > Thank for very much for your suggestion. The group syntax was exactly > what I needed. > > However, I am still having some trouble with getting the TOC macro to > correctly pick up wiki syntax rendered with $doc.display() that is > contained in an object's property. > > I have also noticed that using wiki syntax instead of html, > $doc.display seems to behave differently and overrides the default > editor setting. > > Here is my example - I am using wiki syntax similar to the following > (simplified for example's sake): > > ************START CODE**************** > (% class="grid sortable doOddEven" id="Table" %) > (% class="sortHeader" %)|=Field 1|=Field 2 > |Data 1|((( > (% class="mktree" name="tree" %) > * ((( > =$doc.display("String", $object)= > ))) > ** ((( > $doc.display("TextArea", $object) > ))) > ))) > > {{toc /}} > ************END CODE**************** > > The TextArea property contains a large quantity of text formatted in > xwiki syntax. The display works just fine - the contents of the > property render correctly and display in the table. > > Two problems: > > 1) The TOC macro only recognizes the String property that I manually > enclose in "=" Heading 1 syntax. It doesn't seem to be picking up the > wiki syntax contained in the object properties. So if I had 3 objects > on the page, I get: > > *String 1 > *String 2 > *String 3 > > Instead of: > > *String 1 >  **Heading 2 from TextArea** >  **Heading 2 from TextArea** > *String 2 > Etc.... > > I'm afraid I don't know very much about the order of macro rendering > or whether it is even possible to accomplish what I am describing... > > 2) When I use the Inline editing mode, another TextArea property of > the object (not shown in the code above) does not show up with the > WYSIWYG editor, even though it is set as the default editor. When > using the {{html}} macro and code like this: > > <li>$doc.display("TextAreaWYSIWYG", $object)</li> > > The property correctly displays in Inline mode with the WYSIWYG > editor. Now that I am using only wiki syntax to display the table, all > TextArea properties show up in the Plain Text editor, regardless of > their default setting. Am I doing something wrong?

Can you paste the code that doesn't work? (i.e. without using the HTML macro). Also, can you print this:

$context.getEditorWysiwyg()

at the end of your sheet. It will display a comma-separated list of field IDs that require WYSIWYG editing. Are your fields listed there when editing in Inline mode?

Hope this helps, Marius

> > Many thanks for all of the help, I have made very significant progress > on my project thanks to this list... > > aaron > > On Sun, Oct 23, 2011 at 1:50 AM, Thomas Mortagne > <[email protected]> wrote: >> On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications >> <[email protected]> wrote: >>> Thank you for the feedback - I have been playing with passing custom >>> parameters, and have a few additional clarification questions. >>> >>> It seems that I need to use pure wiki syntax if I want the TOC macro >>> to work right. I am currently relying on the {{html}} macro for two >>> things which I can't figure out how to replace with custom parameters: >>> >>> 1) Nested <ul>'s - I can only get the custom parameter to apply to one >>> line, and can't figure out how to nest another <ul>. >>> >>> Something like this: >>> (% class="mktree" name="tree" %) >>> * $doc.display("Title", $obj) >>>  <velocity code, including an {{html}} block to create an <input> element> >>> **Additional parts of tree >>> ***Additional parts of tree >>> >>> Just returns two different <ul>'s, only the first one of which has the >>> custom parameter. Is this because the additional lines of code before >>> continuing the tree forces the rendering engine to close the first >>> <ul>? Any way to override that? >> >> Here is an example of wiki syntax with custom parameters on each ul: >> >> (% param=value %) >> * toto >> (% param2=value2 %) >> ** titi >> >> but custom parameters on li is not supported yet. >> >>> >>> 2) Table Sorter - Unfortunately, the whole set of object display code >>> is wrapped in an {{html}} macro because I am using the old Table >>> Sorter extension code. This is because I want to display multiple >>> properties from each object in a single table cell. Looking at the >>> Live Table macro, it seems that it only supports binding a table to a >>> class and then setting a column to display a single property - where I >>> need a single cell to include multiple properties displayed using >>> custom code. >>> >>> Accomplishing this using the html syntax is simple - I can include an >>> arbitrary amount of code in each <td> tag. >>> >>> To use wiki syntax for a sortable table, the XWiki Syntax document >>> says I should use this: >>> >>> (% class="grid sortable filterable doOddEven" id="tableid" %) >>> (% class="sortHeader" %)|=Title 1|=Title 2 >>> |Cell 11|Cell 12 >>> |Cell 21|Cell 22 >>> >>> This creates the table fine - but I can't figure out how to include >>> additional multi-line code in a single cell. As soon as I put in a new >>> line, etc...it closes the table. Is there any way to accomplish this >>> using wiki syntax? Should I be trying to use LiveTable instead >>> somehow? >> >> You can put as many lines you want without closing the table but it's >> closed by an empty line. If you need to have several paragraphs you >> can use "group"  syntax >> (http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HGroups) as >> in >> >> (% class="grid sortable filterable doOddEven" id="tableid" %) >> (% class="sortHeader" %)|=Title 1|=Title 2 >> |Cell 11|((( >> Cell 12 >> >> with >> >> several >> >> paragraphs >> )))|Cell 21|Cell 22 >> >>> >>> If the above is confusing, here's what I'm really asking: >>> >>> I want to use a sortable table to display multiple objects of the same >>> class on the same page. I would like that table to display multiple >>> properties of each object in certain cells in the row. Some of those >>> properties will contain wiki syntax - which I would like to be >>> readable by the TOC macro after the table has been rendered. Is there >>> a way to accomplish this? >>> >>> Thank you, >>> >>> Aaron >>> >>> On Thu, Oct 20, 2011 at 1:18 PM, Ashtar Communications >>> <[email protected]> wrote: >>>> Interesting - I had missed the ability to pass custom parameters using >>>> wiki syntax. I will play with that and see if I can get it to output >>>> the same html I need. >>>> >>>> I am in fact using a series of nested <ul> within each <div>, that >>>> forms a collapsible javascript tree. The js is touchy about the exact >>>> formatting of the UL - if I can't get the tags to nest correctly using >>>> wiki syntax then I may be back with additional questions. >>>> >>>> A more accurate but simplified version of each object's display code is: >>>> >>>> <ul class="tree"> >>>>  <li> >>>>  <h2>some content</h2> >>>>  <input /> >>>>  <input /> >>>>  </li> >>>>  <ul> >>>>      <li>Some velocity code, returns wiki syntax with headings</li> >>>>      <li>Some velocity code, returns wiki syntax with headings</li> >>>>      <li>Some velocity code, returns wiki syntax with headings</li> >>>>  </ul> >>>> </ul> >>>> >>>> Thanks much, >>>> >>>> aaron >>>> >>>> On Thu, Oct 20, 2011 at 12:52 PM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications >>>>> <[email protected]> wrote: >>>>>> That makes sense, thank you for the clarification. Unfortunately, I am >>>>>> using the HTML macro to generate the final output - this is because I >>>>>> need to use <ul>'s with a javascript to make the div's into >>>>>> collapsible trees. >>>>>> >>>>>> Does that mean I'm out of luck? >>>>> >>>>> <ul> ? I don't see much lists in your example, did you mean div ? >>>>> >>>>> You can get div with custom parameters in pure wiki syntax the following way: >>>>> >>>>> (% class="somecssclass" %) >>>>> ((( >>>>> div content >>>>> ))) >>>>> >>>>> which produces >>>>> >>>>> <div class="somecssclass">div content</div> >>>>> >>>>> And if you really mean list, list most of the wiki elements list >>>>> support custom parameters too: >>>>> >>>>> (% class="somecssclass" %) >>>>> * mylist element 1 >>>>> * mylist element 2 >>>>> >>>>> which produces >>>>> >>>>> <ul class="somecssclass"> >>>>> <li>mylist element 1</li> >>>>> <li>mylist element 2</li> >>>>> </ul >>>>> >>>>> You can put anything you want in custom parameters and html renderer >>>>> will print them as you provided them depending of the element. >>>>> >>>>> Using the html macro should always be the last resort, usually when >>>>> you get some html you don't really have control on that you need to >>>>> display or when you need to display elements not supported by the wiki >>>>> syntax (yet) like <form> related stuff. >>>>> >>>>>> >>>>>> On Thu, Oct 20, 2011 at 12:45 AM, Thomas Mortagne >>>>>> <[email protected]> wrote: >>>>>>> On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications >>>>>>> <[email protected]> wrote: >>>>>>>> One more tonight... >>>>>>>> >>>>>>>> It seems that I am unable to use the built-in TOC macro for wiki >>>>>>>> content which is generated dynamically from a Class Sheet {{include}}. >>>>>>>> I assume this is because the TOC macro is rendered before (or >>>>>>>> simultaneously with) the include macro which actually displays the >>>>>>>> objects on the page, so as far as the TOC macro knows, there are no >>>>>>>> wiki headings on the page (yet) to create an outline from. >>>>>>> >>>>>>> Actually no, there is a concept of priority in macros and TOC macro >>>>>>> priority is very low specifically to support use case like that. But >>>>>>> TOC only support (generated or not) real wiki content which mean if >>>>>>> you have anything in a html macro it will not support it because html >>>>>>> macro produce a RawBlock which is a black box containing html syntax >>>>>>> for other macros. >>>>>>> >>>>>>> So if you use case is just what you described it should work well. >>>>>>> >>>>>>>> >>>>>>>> Does anyone have any suggestions on how to parse through the final >>>>>>>> rendered output of the wiki page to generate a table of contents for >>>>>>>> dynamically generated wiki content? If I'm missing something with the >>>>>>>> existing macro, that would be great... >>>>>>>> >>>>>>>> What I am looking to do is write some code (preferably in a panel, I >>>>>>>> think), which creates a TOC-style index of all the wiki-syntax >>>>>>>> headings contained on the fully rendered page, after the content has >>>>>>>> been generated from TextArea properties of a set of attached objects >>>>>>>> to the page. >>>>>>>> >>>>>>>> I have written custom display code that loops through every object of >>>>>>>> a custom class attached to a page and then displays some of that >>>>>>>> objects properties in a series of collapsible div's. Each object >>>>>>>> contains two TextArea properties - one for WYSIWYG data, and one for >>>>>>>> plain text, which would be formatted in wiki syntax. The result is a >>>>>>>> list of each objects name with an expandable <div> full of the >>>>>>>> wiki-rendered content contained in the TextArea properties. I would >>>>>>>> like to generate a TOC which "reads through" that content and comes up >>>>>>>> with a list of only the relevant headings under each displayed >>>>>>>> "object" >>>>>>>> >>>>>>>> For example, on a page with 3 objects, the custom display code in the >>>>>>>> Class Sheet results in this (the wiki syntax appears fully rendered, >>>>>>>> obviously): >>>>>>>> >>>>>>>> Object 1 Name - Click to expand >>>>>>>>    ******Hidden until clicked******** >>>>>>>>    ==Heading 2== >>>>>>>>    ===Heading 3=== >>>>>>>>    Normal text, etc... >>>>>>>> >>>>>>>> Object 2 Name - Click to expand >>>>>>>>    ******Hidden until clicked******** >>>>>>>>    ==Heading 2== >>>>>>>>    ===Heading 3=== >>>>>>>>    Normal text, etc... >>>>>>>> >>>>>>>> Object 3 Name - Click to expand >>>>>>>>    ******Hidden until clicked******** >>>>>>>>    ==Heading 2== >>>>>>>>    ===Heading 3=== >>>>>>>>    Normal text, etc... >>>>>>>> >>>>>>>> >>>>>>>> I would like the TOC to return: >>>>>>>> >>>>>>>> Object 1 >>>>>>>>  Heading 2 >>>>>>>>  Heading 3 >>>>>>>> Object 2 >>>>>>>>  Heading 2 >>>>>>>>  Heading 3 >>>>>>>> Object 3 >>>>>>>>  Heading 2 >>>>>>>>  Heading 3 >>>>>>>> >>>>>>>> Even when all the div's are initially collapsed/hidden. It would be >>>>>>>> ideal if the TOC was clickable and went to the relevant anchor... >>>>>>> >>>>>>> Are the divs done using html macro or using wiki syntax ? >>>>>>> >>>>>>>> >>>>>>>> I can obviously use getValue() with each TextArea property to return a >>>>>>>> string with that objects wiki syntax - but I don't have an easy way to >>>>>>>> parse that string to only return the heading levels... >>>>>>>> >>>>>>>> Any guidance would be appreciated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> aaron >>>>>>>> _______________________________________________ >>>>>>>> users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Mortagne >>>>>>> _______________________________________________ >>>>>>> users mailing list >>>>>>> [email protected] >>>>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>>>> >>>>>> _______________________________________________ >>>>>> users mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/users >>>>> >>>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/users >>> >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/users >> > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne