28 Aug
2007
28 Aug
'07
3:09 p.m.
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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
29 Aug
29 Aug
8:49 a.m.
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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
4 Sep
4 Sep
6:22 a.m.
On Wed, Aug 29, 2007 at 10:49:34AM +0200, Thomas Drevon wrote:
Pavel Kolesnikov wrote:
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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
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. 
6:37 a.m.
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:
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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Pavel Kolesnikov wrote:
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. 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.
6418
days inactive
6425
days old
3 comments
4 participants
participants (4)
-
Paul Armstrong -
Pavel Kolesnikov -
Thomas Drevon -
Vincent Massol