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
