[xwiki-users] wiki for documentation and planning projects
Hi all, I am considering XWiki for a collaborative mapping IT infrastructure and planning changes. The idea behind that is as follows: few times a year, a team of central architecture group and organization units specific stakeholders want to review the existing infrastructure map, requirements collected in third party tools and propose changes. My tool should support only this documentation and planning part, implementation of proposed changes would be supported by other tools. If I use a wiki to manage such a documentation and planning project, I need pages for individual documents, I need some index pages for different kinds of documents, and I need also pages for project metadata (team members, milestones, processes). Also, I need a set of templates to generate stubs of new projects easily. Perhaps such a project could be implemented as a wiki space, and there could be an extra wiki space as a template. I am very new to Xwiki, so I would like to ask the more experienced users: - Does my idea of mapping projects to spaces sense? - Is Xwiki suitable for that? - Is it possible to define something like a template space and customize the new space wizard to use such a template? One more question: is there any mechanism/best-practice how to keep my Xwiki extensions (plugins, Xwiki classes, templates, ...) isolated somehow to make future upgrades of Xwiki as easy as possible? thanks a lot, Pavel _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Pavel Kolesnikov wrote:
I am very new to Xwiki, so I would like to ask the more experienced users: - Does my idea of mapping projects to spaces sense? - Is Xwiki suitable for that? - Is it possible to define something like a template space and customize the new space wizard to use such a template?
I'll leave this to be answered by somebody else :-)
One more question: is there any mechanism/best-practice how to keep my Xwiki extensions (plugins, Xwiki classes, templates, ...) isolated somehow to make future upgrades of Xwiki as easy as possible?
Yes. In my opinion, only do changes to your xwiki instance by 1. Editing pages (e.g. html or velocity). These changes consists of updating your database, and will thus survive an xwiki update. However, should the database structure change (dunno how often this happens) you are of course in trouble. 2. Write homebrew java plugins (package as jar and copy into WEB-INF/lib/) which you invoke from xwiki pages. Under no circumstance edit .vm files. This may seem like at decent idea at first, but will gradually make upgrade something you will try to avoid. Which of course is the opposite of progress. cheers :-) Thomas Drevon _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Wed, Aug 29, 2007 at 10:49:34AM +0200, Thomas Drevon wrote:
Pavel Kolesnikov wrote:
One more question: is there any mechanism/best-practice how to keep my Xwiki extensions (plugins, Xwiki classes, templates, ...) isolated somehow to make future upgrades of Xwiki as easy as possible?
Yes. In my opinion, only do changes to your xwiki instance by
1. Editing pages (e.g. html or velocity). These changes consists of updating your database, and will thus survive an xwiki update. However, should the database structure change (dunno how often this happens) you are of course in trouble.
2. Write homebrew java plugins (package as jar and copy into WEB-INF/lib/) which you invoke from xwiki pages.
Under no circumstance edit .vm files. This may seem like at decent idea at first, but will gradually make upgrade something you will try to avoid. Which of course is the opposite of progress.
What do you suggest for customizing things that are stored in .vm files in the skins directory rather than the database? The other thing that I find makes updates significantly harder is if you update pre-defined pages. For example, editing Blog.Macros causes me to go through some pain every time I do an update. Paul -- End dual-measurement, let's finish going metric! http://gometric.us/ http://www.metric.org/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Hi Paul, On Sep 4, 2007, at 8:22 AM, Paul Armstrong wrote:
On Wed, Aug 29, 2007 at 10:49:34AM +0200, Thomas Drevon wrote:
Pavel Kolesnikov wrote:
One more question: is there any mechanism/best-practice how to keep my Xwiki extensions (plugins, Xwiki classes, templates, ...) isolated somehow to make future upgrades of Xwiki as easy as possible?
Yes. In my opinion, only do changes to your xwiki instance by
1. Editing pages (e.g. html or velocity). These changes consists of updating your database, and will thus survive an xwiki update. However, should the database structure change (dunno how often this happens) you are of course in trouble.
2. Write homebrew java plugins (package as jar and copy into WEB-INF/lib/) which you invoke from xwiki pages.
Under no circumstance edit .vm files. This may seem like at decent idea at first, but will gradually make upgrade something you will try to avoid. Which of course is the opposite of progress.
What do you suggest for customizing things that are stored in .vm files in the skins directory rather than the database?
The other thing that I find makes updates significantly harder is if you update pre-defined pages. For example, editing Blog.Macros causes me to go through some pain every time I do an update.
This is indeed a very interesting topic for which we need to do 2 things: 1) Work on making it easier to upgrade XWiki versions 2) Document best practices for upgrading I had started doing so here: http://www.xwiki.org/xwiki/bin/view/ AdminGuide/Installation#HUpgradinganexistingwiki However it deserves a proper page on xwiki.org, in the admin guide. Would you be interested in starting such a page there? (if so please go ahead) so that everyone can add to it? So far, we've listed 2 practices in this thread: 1) Avoid touching Templates and skin files. 2) Avoid modifying default pages in the XWiki space. If you do the best practice I think is to leave the current page as is and instead copy it to a new page and then use that page. What I'd love to see in the future is the following: A) Separate the default XWiki Enterprise XAR into a set of small application XAR. I've started defining them (see the components defined in JIRA for the XWiki Enterprise project) B) Implement an Application manager application to manage upgrading applications. See http://www.xwiki.org/xwiki/bin/view/Idea/ ApplicationManager (implementation is old but specification is still ok). I guess there could be a comparison done on application pages and if a change is found in the user wiki then a window asking which version to use would pop up with a diff of the 2 versions. C) A new skin that is easy to extend and which offers extension points. I know work has been started on this by Laurent Lunati but I don't know when it'll be done. In the further future, we'll need to implement some UI extension capability such as: http:// www.nabble.com/-ArchitectureV2--UI-Interfaces-tf3432811.html#a9569729 Thanks -Vincent _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
participants (4)
-
Paul Armstrong -
Pavel Kolesnikov -
Thomas Drevon -
Vincent Massol