Actually, the warning message is a bit misleading (my bad).. It would only give the #else if you don't have an assigned app or topic querystring (you may need to add checks to ensure they're non-empty as well). You could change the #else to show an index of existing help pages, this way you have an easy index to return to (and would be linked to the help topic in question). In terms of automatic topic creating options (if the user has permissions on the space used), this is already taken care of based on how xwiki works (when you try and access a document and/or space that does not exist, you will get an xwiki page warning you that the document does not exist and the option to create it). Either way, a change would be added to the script like so (to prevent blank document+blank space): Example code for the "launch.help" page #if(($request.app && "" != $request.app) && ($request.topic && "" != $request.topic)) #set($helpApp=$request.app) #set($helpTopic=$request.topic) #set($openDocName="${helpApp}.${helpTopic}") #set($newDoc=$xwiki.getDocument($openDocName)) $response.sendRedirect($xwiki.getURL($newDoc.fullName)) #else #warning("An invalid topic and/or application was selected.") #end -----Original Message----- From: RonaldH [mailto:email@ronaldharing.com] Sent: 12 April 2007 16:19 To: xwiki-users@objectweb.org Subject: [xwiki-users] RE: xwiki as help system and external mappings Hmm I think I understand what you mean, or hope I do. The only question that now remains is that you state that I should create a new page per help item. If you mean by this that I should know all the urls in advance and create those pages for it, thats the route I dont want to go, since I dont know all the urls yet in advance and I dont want to maintain all the urls and mappings to the xwiki. I would rather feed xwiki a parameter for a specific topic/url and if that does not exist ask the user to create a help page for this (if allowed to create help that is of course). Regards Ronald Esbach, Brandon wrote:

Create a new page "launch.help". Create a new page per help item and application, eg: "mynewapp.createusers" "mynewapp.creategroups"

-- View this message in context: http://www.nabble.com/xwiki-as-help-system-and-external-mappings-tf35656 07.html#a9961571 Sent from the XWiki- Users mailing list archive at Nabble.com.

A good beginning, to be sure; actually, though, the launch page you propose doesn't accomplish much more than just composing the link as the application could do for itself. However, it is probably a good idea to use such a facility, because it could present a page that included the help page if it existed, with options (subject to permissions) to create or edit it, where the "create" option would invoke the editor with a template which would - like most help systems I'm familiar with today - give the user options to view a topical index or search for a topic. The benefit here would be that the index could contain more general help not specific to one page's context, but of course, you could also put code in the template to search for and display relevant topics. Also, if you can put code into the application's context menu, you can make each help-enabled field on the form set a fragment identifier (#anchor) within the help page, to go directly to help text specific to that field. It would probably be better to handle that as a parameter, though, because it would be harder for XWiki to determine whether the field-specific help actually existed and offer to create it. Of course, all that could also be accomplished by means of skinning the space, where the view template did all of the above when referencing a specific application page's help text. And needless to say, automating the page and field naming is a must... brain[sic]

-----Original Message----- From: Esbach, Brandon [mailto:Esbachb@tycoelectronics.com] Sent: Thursday, April 12, 2007 10:36 AM To: xwiki-users@objectweb.org Subject: RE: [xwiki-users] RE: xwiki as help system and external mappings

Actually, the warning message is a bit misleading (my bad).. It would only give the #else if you don't have an assigned app or topic querystring (you may need to add checks to ensure they're non-empty as well). You could change the #else to show an index of existing help pages, this way you have an easy index to return to (and would be linked to the help topic in question).

Either way, a change would be added to the script like so (to prevent blank document+blank space): Example code for the "launch.help" page #if(($request.app && "" != $request.app) && ($request.topic && "" != $request.topic)) #set($helpApp=$request.app) #set($helpTopic=$request.topic) #set($openDocName="${helpApp}.${helpTopic}") #set($newDoc=$xwiki.getDocument($openDocName)) $response.sendRedirect($xwiki.getURL($newDoc.fullName)) #else #warning("An invalid topic and/or application was selected.") #end

-----Original Message----- From: RonaldH [mailto:email@ronaldharing.com] Sent: 12 April 2007 16:19 To: xwiki-users@objectweb.org Subject: [xwiki-users] RE: xwiki as help system and external mappings

Hmm

I think I understand what you mean, or hope I do. The only question that now remains is that you state that I should create a new page per help item. If you mean by this that I should know all the urls in advance and create those pages for it, thats the route I dont want to go, since I dont know all the urls yet in advance and I dont want to maintain all the urls and mappings to the xwiki. I would rather feed xwiki a parameter for a specific topic/url and if that does not exist ask the user to create a help page for this (if allowed to create help that is of course).

Regards Ronald

Esbach, Brandon wrote:

...

Create a new page "launch.help". Create a new page per help item and application, eg: "mynewapp.createusers" "mynewapp.creategroups"

-- View this message in context: http://www.nabble.com/xwiki-as-help-system-and-external-mappin gs-tf35656 07.html#a9961571 Sent from the XWiki- Users mailing list archive at Nabble.com.

Sorry, I didn't intend to send this message to group already. I hope you don't mind.

Since I was out of the office on Friday, and the group could almost always better answer any questions than I could alone, I think it would be in bad taste for me to object (and just in case there's any chance of cross-cultural confusion as to the import of that answer, I'll state it directly: No, I certainly don't mind, but thanks for your consideration).

I have some dummy questions for you:

We'll see...

- How do I remove an entire space? (in the GUI)

If that's a dummy question, you can call me a dummy. There is no direct GUI command to do it, but you can create a document that will do it. First, get the space name from the request parameters. For example, if you name the parameter "space", then the reference $request.space will contain its value: #set($spacename=$request.space) ## Velocity maps this reference to $request.getParameter("space") Next, use the XWiki API to get the list of documents in that space: #set($docNamelist = $xwiki.getSpaceDocsName($spacename)) Because the method needed to delete a document uses the raw XWiki, XWikiDocument, and XWikiContext classes directly, instead of through the com.xpn.xwiki.api classes XWiki, Document, and Context, getting these objects is a privileged operation that requires that the last author of the document have the "programming" right on the document (to understand why, think of the set-user- and set-group-ID bits on a Unix file; writing a document that has these bits set clears them if the writer is not the owner). So, we have: #set($rawWiki = $xwiki.xWiki) #set($ctx = $context.context) Then, loop through the list: #foreach($docName in $docNamelist) #set($rawDoc = $xwiki.getDocument($docName).document) $rawWiki.deleteDocument($rawDoc, $ctx) #end Then, if you wish to make the document easier to use, create a form that allows the user to select the space, with an "action" attribute that is empty, which will submit the form to the current URL. In the example above, the input field would be named "space", and it wouldn't matter whether the form used GET or POST, since XWiki makes either avaliable through $request. Note, of course, that by creating the document in this way, your initial view of the document would do nothing, since the "space" parameter was empty, so the list will also be empty. And, of course, the power of this document means that it should check $xwiki.getDocument("${space}.WebHome").hasAdminRights() if $space is non-null and non-empty before executing the deletion loop. The rest of your questions are mostly beyond my ability, so I'm glad you forwarded to the group as well - with the exception of whether I looked at your LDAP module, which I did not, since your attachment was detached and destroyed by our network watchdogs because of its "suspicious" content. I resolved to look at the JIRA attachment, but have been too busy as yet to get to it. Probably, though, the only parts I could really help with that I haven't already given you pointers to would be adding a group membership. You can find the way to do that inside your code by looking at the XWiki code invoked by the group sheet when adding a new group member. brain[sic]