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?
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
