[xwiki-devs] Applications: MultiPage Export, Recruitment, Todo Macro
Hi, I've published a few applications we have been using for a little while: - Multi page export application: http://code.xwiki.org/xwiki/bin/view/Applications/MultiPageExportApplication It's an application allowing to generate PDFs or XARs from multiple page. In conjunction with the collection plugin it allows to create full reports from multiple wiki pages. - Recruitment application: http://code.xwiki.org/xwiki/bin/view/Applications/RecruitmentManagementAppli... It's a new version of the already published application. It now included user evaluations of candidates. - Todo Macro http://code.xwiki.org/xwiki/bin/view/Macros/TodoMacro A cool todo macro using the Wiki Macro feature of XWiki 2.0. You can add todos using the Wysiwyg editor and then manage them directly in view mode. The source code for these different applications is here: http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/ Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Thank you for these apps! Ludovic Dubost
Since the apps now appear to all be serialized wiki-documents saved with extension ".xml" in subversion, what about having a simple app-installer which avoids the entire XAR process and allows more fine-grained subversion updating of apps. In other words, as both the application "code" and "document" reside in subversion, installing a new Xwiki app would be as simple as loading a single-document containing "meta" information about the app like it's subversion repo URL, app name&description, and a manifest listing any files that need saving with special permissions. The app would then consult the subversion URL and reconstruct documents in the appropriate space(s) and permissions (per manifest). E.g. documents for the "recruitment" app would be build directly from these: - Loading.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/Loading.xml> - Settings.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/Settings.xml> - WebHome.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/WebHome.xml> - CandidateClass.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClass.xml> - CandidateClassSheet.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClassSheet.xml> - CandidateClassTemplate.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClassTemplate.xml> - ... Eventually,such a mechanism could entail some form of dependency-control on updating apps, e.g. app-branches for different underlying xwiki versions; when you upgrade to a new version of xwiki, any apps installed this way would automatically update changed documents to their new version. Of course, application authors would want to be able to "go the other way", saving out whole spaces/collections of documents into an external subversion repository... The app would, in groovy, via HTTP, read each subversion document into a "pipe", capturing a single document as XML "in memory" (groovy->java) and write it to the database with set-content and save/save-with-prog-rights Xwiki API's. As this would be done one XML file at a time, the maximum "memory explosion" would be the size of the largest XML document (e.g. translations doc) in the app, as opposed to the current situation. (Seems like it would be easier to sidestep large xar export/import issues this way, rather than trying to make XAR import export work via streaming). And of course, if you ended up customizing an application-document on your server, subversion would be used to merge any non-conflicting upgrades to the document that might occur as the application is improved.... Niels http://nielsmayer.com
Hi Niels, On Wed, Oct 21, 2009 at 3:36 PM, Niels Mayer <[email protected]> wrote:
Thank you for these apps!
Ludovic Dubost
Since the apps now appear to all be serialized wiki-documents saved with extension ".xml" in subversion, what about having a simple app-installer which avoids the entire XAR process and allows more fine-grained subversion updating of apps. In other words, as both the application "code" and "document" reside in subversion, installing a new Xwiki app would be as simple as loading a single-document containing "meta" information about the app like it's subversion repo URL, app name&description, and a manifest listing any files that need saving with special permissions. The app would then consult the subversion URL and reconstruct documents in the appropriate space(s) and permissions (per manifest). E.g. documents for the "recruitment" app would be build directly from these:
- Loading.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- Settings.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- WebHome.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- CandidateClass.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- CandidateClassSheet.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- CandidateClassTemplate.xml< http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-re...
- ...
Eventually,such a mechanism could entail some form of dependency-control on updating apps, e.g. app-branches for different underlying xwiki versions; when you upgrade to a new version of xwiki, any apps installed this way would automatically update changed documents to their new version. Of course, application authors would want to be able to "go the other way", saving out whole spaces/collections of documents into an external subversion repository...
The app would, in groovy, via HTTP, read each subversion document into a "pipe", capturing a single document as XML "in memory" (groovy->java) and write it to the database with set-content and save/save-with-prog-rights Xwiki API's. As this would be done one XML file at a time, the maximum "memory explosion" would be the size of the largest XML document (e.g. translations doc) in the app, as opposed to the current situation. (Seems like it would be easier to sidestep large xar export/import issues this way, rather than trying to make XAR import export work via streaming). And of course, if you ended up customizing an application-document on your server, subversion would be used to merge any non-conflicting upgrades to the document that might occur as the application is improved....
Sounds good. I'll be eagerly waiting to see your prototype in action ;-) Guillaume
Niels http://nielsmayer.com _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
participants (3)
-
Guillaume Lerouge -
Ludovic Dubost -
Niels Mayer