[xwiki-users] TOC Macro question
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.
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...
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
[xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] TOC Macro question
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
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Hi Eugen, Thanks for taking the time to share this. I definitely agree with issues 1 and 2. They're really important. I also agree about issue 3 although it's slightly less important than the other 2. Listing tested DBs in the Release notes is a good idea. Actually what I would have liked to do is to go further than this and have various agents on jenkins running on various DBs (HSQLDB, PostgreSQL, MySQL and Oracle) to ensure that all our tests run fine on these DBs all the time. I've been wanting to have this for a long time now but it's not happened yet :( Of course patches (even better: github pull requests!) are more welcome to help us fixing these issues. Thanks -Vincent On Oct 20, 2011, at 9:21 AM, Eugen Colesnicov wrote: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921,XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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
Re: [xwiki-users] Troubles with XWiki3.2 / Workspace Application
Hi Guillaume, On Wed, Oct 19, 2011 at 7:13 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi Edy, you might want to make it more visible on http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Applicationthat the WikiManager plugin has to be installed for the Workspace application to work fine. WDYT? I think we need to update the Wiki Manager documentation since it's a bit confusing, mostly because half of it is on extensions.xwiki.org and the other half is on manager.xwiki.org. I`ve updated the extension page of the Workspace Application and slightly emphasized the fact that it requires a functional multi-wiki environment before starting the install process. Thanks, Eduard Guillaume On Wed, Oct 19, 2011 at 6:01 PM, Eduard Moraru enygma2...@gmail.com wrote: Hi Jerem, First, thanks for the interest in the Workspace Application. Now, as Ludovic and Thomas have already said, it's most likely a configuration problem that comes from installing the required WikiManager plugin over your non-virtual XE instance, practically transforming it into a XEM instance. Please make sure you allow the xwiki database user to create databases freely [1] and that you choose a wiki access mode [2] convenient to your usecase. Workspaces needs a multi-wiki environment and that`s where all of this comes from. Once the WikiManager plugin installation is completed and the multi-wiki environment is set up, you can proceed with the final steps of the Workspaces installation (visiting WorkspaceManager.Install and attaching the workspace-template.xar). Please let us know how it goes. Thanks, Eduard - References: [1] http://manager.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HConvertanexistingXWikiEnterpriseinstance [2] http://manager.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki On Wed, Oct 19, 2011 at 6:42 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: See http://manager.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki for more details. On Wed, Oct 19, 2011 at 4:53 PM, Ludovic Dubost ludo...@xwiki.com wrote: Try also to access by IP. Normally using the IP should consider you on the default wiki for sure. 2011/10/19 Ludovic Dubost ludo...@xwiki.com Either you work with usepath=1 and you have rewritten URLs or you use usepath=0 and you will need DNS configuration. Now the default URL will still work, but you might need a entry for the default wiki. This entry might come with the wiki manager xar. Ludovic 2011/10/19 jerem jeremie.bousq...@gmail.com I'll retry that asap and let you know. For rewritten urls, is it normal behaviour when activating workspaces ? I'd need to change my proxy conf in this case (to rewrite /xwiki/bin to /xwiki/wiki/xwiki). -- View this message in context: http://xwiki.475771.n2.nabble.com/Troubles-with-XWiki3-2-Workspace-Application-tp6908844p6909001.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ 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
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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
Re: [xwiki-users] Upgrade to 3.2 minor issues
I had the same issue, the workaround I used was solution 3 : move back table activitystream_events_params to use MyISAM ;) Switching to InnoDb is not without consequences : in my case I perform full online backups with mysqlhotcopy command, with InnoDb it won't be possible anymore. And to perform online backups I will have to switch to mysqldump's (what I was using to start with, and I stopped because I found it really not easy to restore backups, and really far longer than with hot copy of tables files - hours instead of minutes on slow FS). mysqlbackup is not part of the community edition of mysql ... :( -- View this message in context: http://xwiki.475771.n2.nabble.com/Upgrade-to-3-2-minor-issues-tp6883965p6912812.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
2011/10/20 Thomas Mortagne thomas.morta...@xwiki.com: On Thu, Oct 20, 2011 at 2:13 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) That's weird, do you have an account on jira ? Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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 Just my two pennyworth as a confluence convert Although the installation instructions will not change much with each release, if they were specific to each release it might encourage more relevant comments and updates from other users. At present if you look on the installation notes, the comments start years ago... If there was a new page for each release, then the comments would (hopefully) be relevant to that release. making them a much more usable
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Hi, sorry about the Oracle issue, it really seems to be affecting a lot of users. Also, I would love to get your feedback about Confluence and what made you switch to XWiki instead :-) Guillaume 2011/10/20 shouldbe q931 shouldbeq...@gmail.com Just my two pennyworth as a confluence convert Although the installation instructions will not change much with each release, if they were specific to each release it might encourage more relevant comments and updates from other users. At present if you look on the installation notes, the comments start years ago... If there was a new page for each release, then the comments would (hopefully) be relevant to that release. making them a much more usable resource. This could be done by just creating a copy of the page (without comments but with all relevant changes) for each new release in just the same way as the release notes are updated for each release. I am also affected by the Oracle issue, and am now having to rethink what we will use as a database back end. Cheers ___ 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
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Yes I do have JIRA account, just try to vote for your own issues, I don't think you will succeed. Have a look at file attached. :-) Dmitry 20 октября 2011, 16:47 от Thomas Mortagne thomas.morta...@xwiki.com: On Thu, Oct 20, 2011 at 2:13 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) That's weird, do you have an account on jira ? Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
On Thu, Oct 20, 2011 at 6:07 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Yes I do have JIRA account, just try to vote for your own issues, I don't think you will succeed. Have a look at file attached. :-) Indeed did not seen it was you own issue. Dmitry 20 октября 2011, 16:47 от Thomas Mortagne thomas.morta...@xwiki.com: On Thu, Oct 20, 2011 at 2:13 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) That's weird, do you have an account on jira ? Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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
Re: [xwiki-users] TOC Macro question
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
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
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921,XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 Heh, I was just implementing XWIKI-6921, finishing it in a few hours. So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicovecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
vmassol wrote: ... Listing tested DBs in the Release notes is a good idea. Actually what I would have liked to do is to go further than this and have various agents on jenkins running on various DBs (HSQLDB, PostgreSQL, MySQL and Oracle) to ensure that all our tests run fine on these DBs all the time. I've been wanting to have this for a long time now but it's not happened yet :( Of course patches (even better: github pull requests!) are more welcome to help us fixing these issues. ... Excuse me, but I am totally not a developer or a programmer ... for this reason, I don't know what is it jenkins and github more, that I can read in a wikipedia ... I am not understanding process at all. I have some experience as a admin, also knows Oracle, SQL. If you can give me some directions - what I should do for helping XWiki project in a testing process (how I need to use jenkins github for testing Oracle) - I will do it. I have possibility to test XWiki with OracleXE 10.2 Oracle 11G. In any case, for the future, I am taking responsibility - to test XWiki BEFORE release. In the past - I didn't have possibility, but now I prepared some virtual machines and I can easy testing different variants. -- Best Regards Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6914517.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] TOC Macro question
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=somecssclassdiv 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
limylist element 1/li
limylist 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
Re: [xwiki-users] TOC Macro question
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
h2some content/h2
input /
input /
/li
ul
liSome velocity code, returns wiki syntax with headings/li
liSome velocity code, returns wiki syntax with headings/li
liSome 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=somecssclassdiv 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
limylist element 1/li
limylist 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
Re: [xwiki-users] TOC Macro question
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
thomas.morta...@xwiki.com wrote:
On Thu, Oct 20, 2011 at 9: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=somecssclassdiv content/div
It's more div class=somecssclasspdiv 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
limylist element 1/li
limylist 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
