Re: [xwiki-users] where put macros?
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's something
technical and 99% of wiki users don't want/need to see it (and they won't
even understand it). So for me this space would need to be hidden from
simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess ;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to find
information (not as contributors) and they'll see the list of spaces listed on
the home page mixed with spaces containing real content for that wiki. All I
want is a separation between business content and technical content. I'm fine
if we have 2 space lists on the home page, one for each type of content. But I
really don't like to mix the two kind of content.
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard application
and that spaces macro could be moved to that dashboard application.
Recent Activity should be moved to an Activity application too and the activity
macro there too.
Basically I still believe strongly that we need to list all our default XE
pages and assign them an application. I had done that exercise one and created
the jira components in XE asa result. Maybe we should revisit this and do this
mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki content
organization and as a result I feel that our default wiki content is a bit of a
disorganized mess. We should improve. Want to lead a proposal?
I think the (not existing) UI at Macros.WebHome should retrieve and
list documents from the entire wiki, not just the Macros space.
I agree
Same
as the scheduler (I changed that behavior just recently by the way - I
wanted my application scheduler jobs in my application space, not in
the Scheduler space - see http://jira.xwiki.org/jira/browse/XASCH-56)
Yep seen that and I agree.
Does it mean a new platform/application in svn?
There is already one : the wikibridge I think, with just one
document now (the name is not correct though, I agree)
Agree, it's a good place and it should be renamed or merged with another app,
all depending if we find that there are macros that don't belong to any
specific app.
What macros go there? When do we use wiki macros vs java macros (we haven't
really decided on this I think)?
I'm quite sure you will not agree, but I would say generic (i.e. not
tied to a particular application) wiki macros could go there. For
example {{spaces /}} or even {{activity /}} which goes beyond just the
dashboard app.
See comment above about the dashboard and activity apps.
Will java macros also be listed on that home page (they should IMO)?
Yes they should. Maybe not under the exact same form, but they
definitely should be listed and documented here
Generally speaking I'm rather +1 (I'd like macros to stay in their apps
though).
Cool. I'm +1 too and +1 to have the possibility for apps to bring
their own
Re: [xwiki-users] where put macros?
Vincent Massol wrote:
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's
something technical and 99% of wiki users don't want/need to see it (and
they won't even understand it). So for me this space would need to be
hidden from simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess ;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to find
information (not as contributors) and they'll see the list of spaces listed
on the home page mixed with spaces containing real content for that wiki. All
I want is a separation between business content and technical content. I'm
fine if we have 2 space lists on the home page, one for each type of content.
But I really don't like to mix the two kind of content.
This categorization would also welcome here. It is been hard to me to
explain to regular users what is the difference between business
content and technical content as Vicent called that different nature
documents. Even talking with tech-skilled people, is by no means easy to
explain that one thing are contents produced by the community they are
going to create/support by using a new XWiki installation and the
contains produced/updated by the XWiki community in subsequent releases.
To tag in any simple way those contents in a way they could be
hidden/shown, could even also helps, IMO, the upgrade and backup operations.
Just my two cents.
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard
application and that spaces macro could be moved to that dashboard
application.
Recent Activity should be moved to an Activity application too and the
activity macro there too.
Basically I still believe strongly that we need to list all our default XE
pages and assign them an application. I had done that exercise one and
created the jira components in XE asa result. Maybe we should revisit this
and do this mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki content
organization and as a result I feel that our default wiki content is a bit of
a disorganized mess. We should improve. Want to lead a proposal?
I think the (not existing) UI at Macros.WebHome should retrieve and
list documents from the entire wiki, not just the Macros space.
I agree
Same
as the scheduler (I changed that behavior just recently by the way - I
wanted my application scheduler jobs in my application space, not in
the Scheduler space - see http://jira.xwiki.org/jira/browse/XASCH-56)
Yep seen that and I agree.
Does it mean a new platform/application in svn?
There is already one : the wikibridge I think, with just one
document now (the name is not correct though, I agree)
Agree, it's a good place and it should be renamed or merged with
Re: [xwiki-users] [xwiki-devs] [Proposal] XE 3.0 and Roadmap leading to it
On 11/01/2010 12:50 PM, Gregory GUENEAU wrote: Hi everyone, I am +1 to make stabilization work, on a couple of releases I am +1 to have soon a 3.0 release And i am +1 on the content vincent propose But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family. Therefore : - do we consider a january 2011 release to be stable enough ? - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? - do we have a clear consensus short list of features that show the path of 3.x family ? - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? From the committers' point of view, it makes perfect sense for 3.0 to be the culmination of the 2.x releases, but I'm not sure the users understand this as well, so I'm extending the question to the users list. Traditionally, proprietary software is developed behind the curtains, and it's normal to have one big release every two years, with lots of new features and some bugs which get fixed in subsequent bugfix releases. Marketing comes mostly from the proprietary software world, so from a marketing point of view, this is the normal way releases work. In the open source world, since the development is done in the open, it doesn't make sense to stash code away in a repository and only release it once every two years. Still, most big projects use a release versioning scheme similar to the proprietary products, but with a slight difference which deeply changes the meaning. While proprietary products use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, 5.5), open source usually has 3 numbers in its versions, with the following meanings: The first number changes rarely, and when it does, it signals a critical change, like a complete rewrite of the codebase, a change of paradigm, or major new features. The second number is the one that actually identifies a release. The third number is the bugfix version. So, when we say that PHP 5.3.2 was released, we actually say that version 3 of PHP5, which is a different thing than PHP4, has been released again, giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw its first bugfix release. Another tendency is for open source software to linger towards a major release. For example, lots of software have a lot of releases before 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows that 0.x comes before 1.0, and it's not just a bugfix version of an imaginary 0.0 release. A different topic is that of agile development, with very short releases (2-3 weeks) for which traditional version number make no sense, since such a product would reach version 42 in a couple of years. Either an identifier, such as the SCM version number is used, or a continuous counter (v1.42) is used. Since the software evolves in a fluid manner, without a breakthrough version coming out of the regular releases, a major version is released when the current features are stable and they mix well together in a coherent product. Since releases come so frequently, it's normal for users to be split into two categories: those that follow the releases and know how the software is evolving, and those that only monitor the major releases, and which see all the continuous improvements at once. While XWiki Enterprise is used in the enterprise environment, and it is backed by commercial companies, it is a true open source project, following an open source release model, so I don't think that a proprietary product release scheme is suited. Our development/release style is closer to the agile development practice, albeit with mixed release types. In the future, once the core is more stable than it is now, we'd like to move even closer to a full agile release process, with 2-3 weeks between final releases. Thus, I believe that the last release versioning strategy is the best for XWiki Enterprise. Note that we're already using this strategy in a more obvious way for smaller modules (applications, skins, tools), where we do have 1.32 as a stable version number. Also note that although 1.9 was followed by 2.0, this was just a coincidence, and not a natural version evolution, since we also felt that the code was mature enough to receive a major number bump, but it could just as well have been followed by a 1.10. So, there are two different
Re: [xwiki-users] where put macros?
Hi,
On Wed, Nov 3, 2010 at 09:10, [Ricardo Rodriguez] eBioTIC.
ricardo.rodrig...@ebiotic.net wrote:
Vincent Massol wrote:
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net
wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com
wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki
advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's
something technical and 99% of wiki users don't want/need to see it (and
they won't even understand it). So for me this space would need to be hidden
from simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess
;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to
find information (not as contributors) and they'll see the list of spaces
listed on the home page mixed with spaces containing real content for that
wiki. All I want is a separation between business content and technical
content. I'm fine if we have 2 space lists on the home page, one for each
type of content. But I really don't like to mix the two kind of content.
This categorization would also welcome here. It is been hard to me to
explain to regular users what is the difference between business
content and technical content as Vicent called that different nature
documents. Even talking with tech-skilled people, is by no means easy to
explain that one thing are contents produced by the community they are
going to create/support by using a new XWiki installation and the
contains produced/updated by the XWiki community in subsequent releases.
To tag in any simple way those contents in a way they could be
hidden/shown, could even also helps, IMO, the upgrade and backup
operations.
Just my two cents.
+1 for a better separation as well. I regularly give demos of XWiki and
landing on a first page with all the technical spaces is indeed confusing
for users.
Guillaume
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently
located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard
application and that spaces macro could be moved to that dashboard
application.
Recent Activity should be moved to an Activity application too and the
activity macro there too.
Basically I still believe strongly that we need to list all our default
XE pages and assign them an application. I had done that exercise one and
created the jira components in XE asa result. Maybe we should revisit this
and do this mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki
content organization and as a result I feel that our default wiki content is
a bit of a disorganized mess. We should improve. Want to lead a proposal?
I think the (not existing) UI at Macros.WebHome should retrieve and
list documents from the entire wiki, not just the Macros space.
I agree
Same
as the scheduler (I changed that behavior just recently by the way - I
wanted my application scheduler jobs in my application space, not in
the Scheduler space - see http://jira.xwiki.org/jira/browse/XASCH-56)
Yep seen that and I agree.
Does it mean a
[xwiki-users] This object is currently locked by - section editing
Hello :) I configured my XWiki instance in the following way: #-# This parameter will activate the sectional editing. xwiki.section.edit=1 #-# This parameter controls the depth of sections that have section editing. #-# By default level 1 and level 2 sections have section editing. xwiki.section.depth=6 I have many users working on documents simultaneously and in order to minimize document locking and possible merging I encourage them to edit sections/paragraphs instead. I noticed that when, for instance, two users edit different sections within the same page, the latter gets the message: This object is currently locked by user1 I checked and it's possible to force editing and save both of concurrent changes to that document, but the message itself is a bit confusing to the users. I'm asking if it's possible to change xwiki configuration to not display that message when the users edit different paragraphs within the same page ? Regards, Piotr ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 8:00 AM, Vincent Massol vinc...@massol.net wrote:
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net
wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com
wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's
something technical and 99% of wiki users don't want/need to see it (and
they won't even understand it). So for me this space would need to be hidden
from simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess
;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to find
information (not as contributors) and they'll see the list of spaces listed
on the home page mixed with spaces containing real content for that wiki.
All I want is a separation between business content and technical content.
I'm fine if we have 2 space lists on the home page, one for each type of
content. But I really don't like to mix the two kind of content.
+1 for space separation, based on the user type (Advanced/Standard). It is
very disturbing to have technical spaces mixed with content/business spaces.
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently
located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard
application and that spaces macro could be moved to that dashboard
application.
Recent Activity should be moved to an Activity application too and the
activity macro there too.
Basically I still believe strongly that we need to list all our default XE
pages and assign them an application. I had done that exercise one and
created the jira components in XE asa result. Maybe we should revisit this
and do this mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki
content organization and as a result I feel that our default wiki content is
a bit of a disorganized mess. We should improve. Want to lead a proposal?
Yes, we miss conventions on the naming. Moreover, AFAIR something is not
coherent between class wizard and livetable macro : The livetable macro
displays the template document because its name which is given by the class
wizard is not matching the one the livetable macro is expecting (and that
would be excluded).
I think the (not existing) UI at Macros.WebHome should retrieve and
list documents from the entire wiki, not just the Macros space.
I agree
Same
as the scheduler (I changed that behavior just recently by the way - I
wanted my application scheduler jobs in my application space, not in
the Scheduler space - see http://jira.xwiki.org/jira/browse/XASCH-56)
Yep seen that and I agree.
Does it mean a new platform/application in svn?
There is already one : the wikibridge I think, with just one
document now (the name is not correct though, I agree)
Agree, it's a good place and it should be renamed or merged with another
app, all depending if we find that there are macros that don't belong to any
specific app.
I guess there are generic macros that don't belong to a specific app.
What macros go there? When do we use wiki macros vs java macros (we
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 10:47 AM, Guillaume Lerouge guilla...@xwiki.com wrote:
Hi,
On Wed, Nov 3, 2010 at 09:10, [Ricardo Rodriguez] eBioTIC.
ricardo.rodrig...@ebiotic.net wrote:
Vincent Massol wrote:
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net
wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com
wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki
advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's
something technical and 99% of wiki users don't want/need to see it (and
they won't even understand it). So for me this space would need to be hidden
from simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess
;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to
find information (not as contributors) and they'll see the list of spaces
listed on the home page mixed with spaces containing real content for that
wiki. All I want is a separation between business content and technical
content. I'm fine if we have 2 space lists on the home page, one for each
type of content. But I really don't like to mix the two kind of content.
This categorization would also welcome here. It is been hard to me to
explain to regular users what is the difference between business
content and technical content as Vicent called that different nature
documents. Even talking with tech-skilled people, is by no means easy to
explain that one thing are contents produced by the community they are
going to create/support by using a new XWiki installation and the
contains produced/updated by the XWiki community in subsequent releases.
To tag in any simple way those contents in a way they could be
hidden/shown, could even also helps, IMO, the upgrade and backup
operations.
Just my two cents.
+1 for a better separation as well. I regularly give demos of XWiki and
landing on a first page with all the technical spaces is indeed confusing
for users.
I agree. Maybe it's time we thing about typed spaces.
It could start with something light such as a XWiki.SpaceClass with
only a pretty name (quite needed too if you ask me) and a category
list
Jerome.
Guillaume
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently
located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard
application and that spaces macro could be moved to that dashboard
application.
Recent Activity should be moved to an Activity application too and the
activity macro there too.
Basically I still believe strongly that we need to list all our default
XE pages and assign them an application. I had done that exercise one and
created the jira components in XE asa result. Maybe we should revisit this
and do this mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki
content organization and as a result I feel that our default wiki content is
a bit of a disorganized mess. We should improve. Want to lead a proposal?
I think the (not existing) UI at Macros.WebHome should retrieve and
list documents from the entire wiki, not just the Macros space.
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 11:04, Jerome Velociter jerome.xw...@gmail.com wrote:
On Wed, Nov 3, 2010 at 10:47 AM, Guillaume Lerouge guilla...@xwiki.com
wrote:
Hi,
On Wed, Nov 3, 2010 at 09:10, [Ricardo Rodriguez] eBioTIC.
ricardo.rodrig...@ebiotic.net wrote:
Vincent Massol wrote:
On Nov 2, 2010, at 11:12 PM, Jerome Velociter wrote:
Hi Vincent, all,
See below
On Tue, Nov 2, 2010 at 10:46 PM, Vincent Massol vinc...@massol.net
wrote:
On Nov 2, 2010, at 7:47 PM, Thibaut Camberlin wrote:
On Tue, Nov 2, 2010 at 3:05 PM, Jerome Velociter jer...@xwiki.com
wrote:
Actually I've been thinking maybe we could provide a Macros/ space
with XE. The home page would be a improved version of the current
XWiki.WikiMacros page (adding for example a ClassSheet for macros, a
form to create a new macro, some documentation, etc.)
WDYT?
This polishing would empower a standard user to use this XWiki
advanced
feature.
I don't quite agree. Standard users shouldn't see this space. it's
something technical and 99% of wiki users don't want/need to see it (and
they won't even understand it). So for me this space would need to be hidden
from simple users (same as for other tech spaces).
Then we should probably hide them from the WYSIWYG tooIbar too, I guess
;)
Seriously, the space could be blacklisted, but it should be discussed,
I'm not sure we want to have only admins seing it (personally I see
that space as being documentation on macros existing in the wiki
before being a place to create new macros - so not so technical in
the end).
The reason is simple. Most people come to the wiki as a place where to
find information (not as contributors) and they'll see the list of spaces
listed on the home page mixed with spaces containing real content for that
wiki. All I want is a separation between business content and technical
content. I'm fine if we have 2 space lists on the home page, one for each
type of content. But I really don't like to mix the two kind of content.
This categorization would also welcome here. It is been hard to me to
explain to regular users what is the difference between business
content and technical content as Vicent called that different nature
documents. Even talking with tech-skilled people, is by no means easy to
explain that one thing are contents produced by the community they are
going to create/support by using a new XWiki installation and the
contains produced/updated by the XWiki community in subsequent releases.
To tag in any simple way those contents in a way they could be
hidden/shown, could even also helps, IMO, the upgrade and backup
operations.
Just my two cents.
+1 for a better separation as well. I regularly give demos of XWiki and
landing on a first page with all the technical spaces is indeed confusing
for users.
I agree. Maybe it's time we thing about typed spaces.
It could start with something light such as a XWiki.SpaceClass with
only a pretty name (quite needed too if you ask me) and a category
list
+1
Jerome.
Guillaume
Maybe in some distant future we should have an intermediary level
between Normal users and Admins. BTW do users that chose to be
Advanced Users in their profile see the blacklisted spaces ?
yes.
Maybe
the intermediary level could be this one.
I don't think we need one ATM.
I'm not sure what the proposal is about exactly.
Well it's not a proposal yet, rather an idea.
Some open questions: Would the macros stay where they are currently
located?
If you ask me some should be moved already (like {{spaces}} and
{{tags}}), since they are located in documents that already have
another purpose, and thus can not benefit from a potential
WikiMacroClassSheet (that for example could display the usage of the
macro and its parameters ; thus becoming a sort of self-contained
documentation for the held macro)
Well I'm not sure. IMO the dashboard should be moved to a dashboard
application and that spaces macro could be moved to that dashboard
application.
Recent Activity should be moved to an Activity application too and the
activity macro there too.
Basically I still believe strongly that we need to list all our default
XE pages and assign them an application. I had done that exercise one and
created the jira components in XE asa result. Maybe we should revisit this
and do this mapping now?
Shouldn't macros stay with their apps?
Yes they should.
Right now we don't even have a rule for where to put applications
documents (in their own space ? with a Code suffix ? in the XWiki
space ? somewhere else ?)
Yes we need to define that too. We've been quite poor in term of wiki
content organization and as a result I feel that our default wiki content is
a bit of a disorganized mess. We should improve. Want to lead a proposal?
I think the (not existing) UI at Macros.WebHome
[xwiki-users] WYSIWYG plugin missing in 2.5?
Hello, I've just updated a 2.4 test installation to 2.5 and when accessing the first page I got an exception: the WYSIWYG plugin is missing and so the WYSIWYG editor is disabled. I guessed I should find it in xwiki-web-gwt-wysiwyg-server-2.5.jar but there is no editor class included. In the older versions the class was available?! Is there a quick fix available? Best wishes Werner Greßhoff ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 11:04 AM, Jerome Velociter jerome.xw...@gmail.com wrote: On Wed, Nov 3, 2010 at 10:47 AM, Guillaume Lerouge guilla...@xwiki.com wrote: +1 for a better separation as well. I regularly give demos of XWiki and landing on a first page with all the technical spaces is indeed confusing for users. +1 for a better handling of hidden items in the wiki. I agree. Maybe it's time we thing about typed spaces. It could start with something light such as a XWiki.SpaceClass with only a pretty name (quite needed too if you ask me) and a category list We indeed need a pretty name for spaces and wikis (currently handled in wiki descriptors). I think this could go in the XWikiPreference class. Category ? Do we really need to categorize spaces which already are categories ? JV. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 11:32 AM, Jean-Vincent Drean jean-vinc...@drean.org wrote: On Wed, Nov 3, 2010 at 11:04 AM, Jerome Velociter jerome.xw...@gmail.com wrote: On Wed, Nov 3, 2010 at 10:47 AM, Guillaume Lerouge guilla...@xwiki.com wrote: +1 for a better separation as well. I regularly give demos of XWiki and landing on a first page with all the technical spaces is indeed confusing for users. +1 for a better handling of hidden items in the wiki. I agree. Maybe it's time we thing about typed spaces. It could start with something light such as a XWiki.SpaceClass with only a pretty name (quite needed too if you ask me) and a category list We indeed need a pretty name for spaces and wikis (currently handled in wiki descriptors). I think this could go in the XWikiPreference class. Category ? Do we really need to categorize spaces which already are categories ? Ok I read too fast. If the category is here to be able to mark a space as technical, I think it's like using a bazooka to kill a fly. WDYT about hiding spaces to basic users when all the pages within the space are hidden ? (of course the hidden page feature would need to be finished, we'd need APIs to retrieve them for advanced users). Thanks, JV. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] where put macros?
On Wed, Nov 3, 2010 at 11:52 AM, Jean-Vincent Drean jean-vinc...@drean.org wrote: On Wed, Nov 3, 2010 at 11:32 AM, Jean-Vincent Drean jean-vinc...@drean.org wrote: On Wed, Nov 3, 2010 at 11:04 AM, Jerome Velociter jerome.xw...@gmail.com wrote: On Wed, Nov 3, 2010 at 10:47 AM, Guillaume Lerouge guilla...@xwiki.com wrote: +1 for a better separation as well. I regularly give demos of XWiki and landing on a first page with all the technical spaces is indeed confusing for users. +1 for a better handling of hidden items in the wiki. I agree. Maybe it's time we thing about typed spaces. It could start with something light such as a XWiki.SpaceClass with only a pretty name (quite needed too if you ask me) and a category list We indeed need a pretty name for spaces and wikis (currently handled in wiki descriptors). I think this could go in the XWikiPreference class. Category ? Do we really need to categorize spaces which already are categories ? Ok I read too fast. If the category is here to be able to mark a space as technical, I think it's like using a bazooka to kill a fly No I think it could be more than that. You could have spaces of type Content, of type User space, of type Application or Application code, etc. . WDYT about hiding spaces to basic users when all the pages within the space are hidden ? (of course the hidden page feature would need to be finished, we'd need APIs to retrieve them for advanced users). That would work. Jerome Thanks, JV. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] XE 3.0 and Roadmap leading to it
Hi! Sergiu Dumitriu wrote: On 11/01/2010 12:50 PM, Gregory GUENEAU wrote: Hi everyone, I am +1 to make stabilization work, on a couple of releases I am +1 to have soon a 3.0 release And i am +1 on the content vincent propose But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family. Therefore : - do we consider a january 2011 release to be stable enough ? - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? - do we have a clear consensus short list of features that show the path of 3.x family ? - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? From the committers' point of view, it makes perfect sense for 3.0 to be the culmination of the 2.x releases, but I'm not sure the users understand this as well, so I'm extending the question to the users list. Traditionally, proprietary software is developed behind the curtains, and it's normal to have one big release every two years, with lots of new features and some bugs which get fixed in subsequent bugfix releases. Marketing comes mostly from the proprietary software world, so from a marketing point of view, this is the normal way releases work. In the open source world, since the development is done in the open, it doesn't make sense to stash code away in a repository and only release it once every two years. Still, most big projects use a release versioning scheme similar to the proprietary products, but with a slight difference which deeply changes the meaning. While proprietary products use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, 5.5), open source usually has 3 numbers in its versions, with the following meanings: The first number changes rarely, and when it does, it signals a critical change, like a complete rewrite of the codebase, a change of paradigm, or major new features. The second number is the one that actually identifies a release. The third number is the bugfix version. So, when we say that PHP 5.3.2 was released, we actually say that version 3 of PHP5, which is a different thing than PHP4, has been released again, giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw its first bugfix release. Another tendency is for open source software to linger towards a major release. For example, lots of software have a lot of releases before 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows that 0.x comes before 1.0, and it's not just a bugfix version of an imaginary 0.0 release. A different topic is that of agile development, with very short releases (2-3 weeks) for which traditional version number make no sense, since such a product would reach version 42 in a couple of years. Either an identifier, such as the SCM version number is used, or a continuous counter (v1.42) is used. Since the software evolves in a fluid manner, without a breakthrough version coming out of the regular releases, a major version is released when the current features are stable and they mix well together in a coherent product. Since releases come so frequently, it's normal for users to be split into two categories: those that follow the releases and know how the software is evolving, and those that only monitor the major releases, and which see all the continuous improvements at once. While XWiki Enterprise is used in the enterprise environment, and it is backed by commercial companies, it is a true open source project, following an open source release model, so I don't think that a proprietary product release scheme is suited. Our development/release style is closer to the agile development practice, albeit with mixed release types. In the future, once the core is more stable than it is now, we'd like to move even closer to a full agile release process, with 2-3 weeks between final releases. Thus, I believe that the last release versioning strategy is the best for XWiki Enterprise. Note that we're already using this strategy in a more obvious way for smaller modules (applications, skins, tools), where we do have 1.32 as a stable version number. Also note that although 1.9 was followed by 2.0, this was just a coincidence, and not a natural version evolution, since we also felt that the code was mature enough to receive a major number
Re: [xwiki-users] [xwiki-devs] [Proposal] XE 3.0 and Roadmap leading to it
[Ricardo Rodriguez] eBioTIC. wrote: Hi! Sergiu Dumitriu wrote: On 11/01/2010 12:50 PM, Gregory GUENEAU wrote: Hi everyone, I am +1 to make stabilization work, on a couple of releases I am +1 to have soon a 3.0 release And i am +1 on the content vincent propose But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family. Therefore : - do we consider a january 2011 release to be stable enough ? - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? - do we have a clear consensus short list of features that show the path of 3.x family ? - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? From the committers' point of view, it makes perfect sense for 3.0 to be the culmination of the 2.x releases, but I'm not sure the users understand this as well, so I'm extending the question to the users list. Traditionally, proprietary software is developed behind the curtains, and it's normal to have one big release every two years, with lots of new features and some bugs which get fixed in subsequent bugfix releases. Marketing comes mostly from the proprietary software world, so from a marketing point of view, this is the normal way releases work. In the open source world, since the development is done in the open, it doesn't make sense to stash code away in a repository and only release it once every two years. Still, most big projects use a release versioning scheme similar to the proprietary products, but with a slight difference which deeply changes the meaning. While proprietary products use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, 5.5), open source usually has 3 numbers in its versions, with the following meanings: The first number changes rarely, and when it does, it signals a critical change, like a complete rewrite of the codebase, a change of paradigm, or major new features. The second number is the one that actually identifies a release. The third number is the bugfix version. So, when we say that PHP 5.3.2 was released, we actually say that version 3 of PHP5, which is a different thing than PHP4, has been released again, giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw its first bugfix release. Another tendency is for open source software to linger towards a major release. For example, lots of software have a lot of releases before 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows that 0.x comes before 1.0, and it's not just a bugfix version of an imaginary 0.0 release. A different topic is that of agile development, with very short releases (2-3 weeks) for which traditional version number make no sense, since such a product would reach version 42 in a couple of years. Either an identifier, such as the SCM version number is used, or a continuous counter (v1.42) is used. Since the software evolves in a fluid manner, without a breakthrough version coming out of the regular releases, a major version is released when the current features are stable and they mix well together in a coherent product. Since releases come so frequently, it's normal for users to be split into two categories: those that follow the releases and know how the software is evolving, and those that only monitor the major releases, and which see all the continuous improvements at once. While XWiki Enterprise is used in the enterprise environment, and it is backed by commercial companies, it is a true open source project, following an open source release model, so I don't think that a proprietary product release scheme is suited. Our development/release style is closer to the agile development practice, albeit with mixed release types. In the future, once the core is more stable than it is now, we'd like to move even closer to a full agile release process, with 2-3 weeks between final releases. Thus, I believe that the last release versioning strategy is the best for XWiki Enterprise. Note that we're already using this strategy in a more obvious way for smaller modules (applications, skins, tools), where we do have 1.32 as a stable version number. Also note that although 1.9 was followed by 2.0, this was just a coincidence, and not a natural version evolution, since we also felt that
Re: [xwiki-users] WYSIWYG plugin missing in 2.5?
Hi Werner, See http://jira.xwiki.org/jira/browse/XWIKI-5500 . Make sure the WysiwygPlugin is no longer loaded in your xwiki.cfg and that your velocity templates (textarea_wysiwyg.vm, editwysiwygnew.vm, wysiwyginput.vm) are up to date. Hope this helps, Marius On 11/03/2010 12:30 PM, Werner Greßhoff wrote: Hello, I've just updated a 2.4 test installation to 2.5 and when accessing the first page I got an exception: the WYSIWYG plugin is missing and so the WYSIWYG editor is disabled. I guessed I should find it in xwiki-web-gwt-wysiwyg-server-2.5.jar but there is no editor class included. In the older versions the class was available?! Is there a quick fix available? Best wishes Werner Greßhoff ___ 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] watchlist daily notifier doesn't work
The version we're currently using is XE 2.2.4, but we're planning to upgrade to 2.5 within the end of 2010. Anyway, it's not working yet... Next week i'll start to test XE 2.5 on different env, i'll be more precise by that time. thanks claudio -- View this message in context: http://xwiki.475771.n2.nabble.com/watchlist-daily-notifier-doesn-t-work-tp5697641p5702011.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] watchlist daily notifier doesn't work
Then the NPE occurs at the following line: -8- String emailAddr = (String) userObj.getProperty(XWIKI_USER_CLASS_EMAIL_PROP).getValue(); -8- I think this could be caused by a XWiki.WatchListClass object, with a notifier set and watched stuff, in a page which is not a user (no XWiki.XWikiUsers object) JV. On Wed, Nov 3, 2010 at 5:19 PM, ccoreggioli claudio.coreggi...@gidi.it wrote: The version we're currently using is XE 2.2.4, but we're planning to upgrade to 2.5 within the end of 2010. Anyway, it's not working yet... Next week i'll start to test XE 2.5 on different env, i'll be more precise by that time. thanks claudio -- View this message in context: http://xwiki.475771.n2.nabble.com/watchlist-daily-notifier-doesn-t-work-tp5697641p5702011.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
Re: [xwiki-users] [myxwiki] new wiki request
You can access you new wiki on http://etvc.myxwiki.org Enjoy :) On Sun, Oct 31, 2010 at 07:20, Eugen Colesnicov ecolesni...@gmail.com wrote: Hi, I would like to realize activities, informational materials, personal presentations. Also, I assume to share with community materials about xwiki, prepared myself. username : ecolesnicov server name : etvc.myxwiki.org Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/myxwiki-new-wiki-request-tp5690825p5690825.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 -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
Hi, You are supposed to register yourself on myxwiki.org. On Mon, Nov 1, 2010 at 11:35, Vladimir Goloubtzoff vladimir.goloubtz...@gmail.com wrote: Hi, As stated in my previous mail my wiki account has not yet been activated. Could you please take any necessary steps to activate my account? Thank you in advance Yours truly, 2010/10/28 Vladimir Goloubtzoff Hi, i would like to realize articles, manuals and activities about the Internet, and the web. username : vladimir server name : vg-concept.myxwiki.org Thank you. ___ 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
[xwiki-users] Unexpected 'Order By' Results
Hello,
I am having some issues with the order by clause in HQL - the following
query:
$xwiki.searchDocuments(where doc.hidden = false and doc.id='${doc.parent}'
order by doc.title asc)
is returning the expected set of documents, but the title order is erratic.
The documents are reordered, but it is not alphabetized as anticipated.
Instead, there are several alphabetized spurts -- for example, I have 'A',
'C', 'P', ... 'A', 'A', 'B', 'C', 'D', 'E', etc. Within one of these spans,
no items appear out of order, but the 'span' separation is not expected or
desired. Is there a common issue that I could be overlooking?
Thank you,
Chris
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Unexpected-Order-By-Results-tp5702753p5702753.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] Create application similar to attach file application
Hi, I finally finish a little application that let you attach files to an XWiki page and add, edit or delete a comment for the attachment. I didn't have much time to create a page for the app on the xwiki server. Maybe in the future. But I want to put the application online in case someone need that functionality (I know Ricardo need it :) ). The xar file of the File Storage application (I called like that) is at http://dl.dropbox.com/u/3688604/file-storage.xar. By the way you need to have the ModalBox Application installed. The ModalBox application can be found at http://code.xwiki.org/xwiki/bin/view/Applications/ModalBoxApplication. Let me know if you have any doubt or comment. On Fri, Aug 20, 2010 at 12:20 AM, Abel Solórzano Astorga abelsolorz...@gmail.com wrote: Hi, I have the application almost working :). I just need to figure out one thing that I asked in here. I 'll be glad to share the code with the community and with you once it is finish. Regards, On Tue, Aug 10, 2010 at 1:14 PM, [Ricardo Rodriguez] eBioTIC. ricardo.rodrig...@ebiotic.net wrote: Hi! Abel Solórzano Astorga wrote: I appreciate you take the time to answer my question. You gave me part of the solution :). The other part is in here http://www.mail-archive.com/users@xwiki.org/msg02301.html, in case someone need to do a similar XWiki application. Great to know I've been of any help! :-) BTW, have you then manage to get this application working? Are you planning to share it with the community? At least it will be helpful for me to get fileUploadPlugin or an application allowing to add descriptions to the uploaded files. Thanks! Cheers, Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems ___ 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] Unexpected 'Order By' Results
On 11/03/2010 07:47 PM, Chris Wagner wrote:
Hello,
I am having some issues with the order by clause in HQL - the following
query:
$xwiki.searchDocuments(where doc.hidden = false and doc.id='${doc.parent}'
order by doc.title asc)
is returning the expected set of documents, but the title order is erratic.
The documents are reordered, but it is not alphabetized as anticipated.
Instead, there are several alphabetized spurts -- for example, I have 'A',
'C', 'P', ... 'A', 'A', 'B', 'C', 'D', 'E', etc. Within one of these spans,
no items appear out of order, but the 'span' separation is not expected or
desired. Is there a common issue that I could be overlooking?
There are two types of titles.
Document titles are stored in the database as the doc.title field, and
they are editable in the editor above the content.
Display titles are computed from the document title, first heading from
the content, or the document name, depending on which one exists, in
this order. Unfortunately it is not possible to see the display title in
queries.
I'm not sure, but I think that your problem is caused by this difference
between display and document titles. The first set of documents has an
empty document title, but in the UI you see their computed display
title. The second set of documents is correctly ordered by their
persisted document title.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
You can access your new wiki on http://vg-concept.myxwiki.org Enjoy :) On Wed, Nov 3, 2010 at 21:00, Vladimir Goloubtzoff vladimir.goloubtz...@gmail.com wrote: Hi My register on myxwiki.org. is Vladimir Could you please activate my account Thanks 2010/11/3 Thomas Mortagne thomas.morta...@xwiki.com Hi, You are supposed to register yourself on myxwiki.org. On Mon, Nov 1, 2010 at 11:35, Vladimir Goloubtzoff vladimir.goloubtz...@gmail.com wrote: Hi, As stated in my previous mail my wiki account has not yet been activated. Could you please take any necessary steps to activate my account? Thank you in advance Yours truly, 2010/10/28 Vladimir Goloubtzoff Hi, i would like to realize articles, manuals and activities about the Internet, and the web. username : vladimir server name : vg-concept.myxwiki.org Thank you. ___ 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 -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [myxwiki] new wiki request
Hello, I would like to use this wiki for the purpose of exchanging informations with colleagues involved in a collaborative research project in my university and abroad. my user name is pascalvenier I would like to use the following server name for the wiki: complexite Merci d'avance. Pascal ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
