On Thu, Nov 17, 2011 at 1:11 PM, Ashtar Communications
<ashtarcommunicati...@gmail.com> 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
> <mariusdumitru.flo...@xwiki.com> wrote:
>> Hi Aaron,
>>
>> See my comments below,
>>
>> On Sat, Nov 12, 2011 at 7:58 PM, Ashtar Communications
>> <ashtarcommunicati...@gmail.com> 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
>>> <mariusdumitru.flo...@xwiki.com> 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
>>>> <ashtarcommunicati...@gmail.com> 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
>>>>> <mariusdumitru.flo...@xwiki.com> wrote:
>>>>>> Hi Aaron,
>>>>>>
>>>>>> On Tue, Nov 8, 2011 at 12:08 PM, Ashtar Communications
>>>>>> <ashtarcommunicati...@gmail.com> 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
>>>>>>> <thomas.morta...@xwiki.com> wrote:
>>>>>>>> On Sun, Oct 23, 2011 at 12:27 AM, Ashtar Communications
>>>>>>>> <ashtarcommunicati...@gmail.com> 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
>>>>>>>>> <ashtarcommunicati...@gmail.com> 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
>>>>>>>>>> <thomas.morta...@xwiki.com> wrote:
>>>>>>>>>>> On Thu, Oct 20, 2011 at 7:10 PM, Ashtar Communications
>>>>>>>>>>> <ashtarcommunicati...@gmail.com> 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
>>>>>>>>>>>> <thomas.morta...@xwiki.com> wrote:
>>>>>>>>>>>>> On Thu, Oct 20, 2011 at 8:02 AM, Ashtar Communications
>>>>>>>>>>>>> <ashtarcommunicati...@gmail.com> 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
>>>>>>>>>>>>>> users@xwiki.org
>>>>>>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Thomas Mortagne
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>> users@xwiki.org
>>>>>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> users mailing list
>>>>>>>>>>>> users@xwiki.org
>>>>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thomas Mortagne
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> users mailing list
>>>>>>>>>>> users@xwiki.org
>>>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> users mailing list
>>>>>>>>> users@xwiki.org
>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thomas Mortagne
>>>>>>>> _______________________________________________
>>>>>>>> users mailing list
>>>>>>>> users@xwiki.org
>>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> users mailing list
>>>>>>> users@xwiki.org
>>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> users@xwiki.org
>>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>>
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users@xwiki.org
>>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users@xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/users
>>>>
>>> _______________________________________________
>>> users mailing list
>>> users@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Thomas Mortagne
_______________________________________________
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
