(1) SVNSearch<http://svnsearch.org/svnsearch/repos/XWIKI/search?start-index=20&>(general
purpose -- just requires web browser)
(2) if you have subversion source checked out, and use emacs and it's
tags-facility, the following script may be of use to generate
emacs TAGS files.
------------------------------------------------------------------------------------------------------------
#!/bin/sh
## Run in a directory where you want an emacs TAGS file, as used by M-. ;
## M-, ; M-x visit-tags-table; tags-search; tags-query-replace; etc
echo -n "Calling 'svn list -R' to get project files list ..."
all_svn_files=`svn list -R | grep -v '/$'`
echo "... DONE!"
echo "Calling etags on `echo "$all_svn_files" | wc -l` files."
rm -f TAGS
touch TAGS
for i in `echo "$all_svn_files"`
do
etags -a "$i"
done
------------------------------------------------------------------------------------------------------------
(3) if you're an emacs user, vtl-mode is nice for editing velocity-macros
(doesn't do indentation, just syntax-highlighting).
http://wiki.apache.org/jakarta-velocity/EmacsVtlModehttp://markmail.org/message/u3vfq2d5frdpuiu4
;; see /usr/lib/xemacs/site-lisp/vtl.el -- for velocity template language
(autoload 'turn-on-vtl-mode "vtl" nil t)
(add-hook 'html-mode-hook 'turn-on-vtl-mode t t)
(add-hook 'xml-mode-hook 'turn-on-vtl-mode t t)
(add-hook 'text-mode-hook 'turn-on-vtl-mode t t)
(add-to-list 'auto-mode-alist '("\\.vm\\'" . turn-on-vtl-mode))
(4) subversion-enable your emacs with http://www.xsteve.at/prg/vc_svn/ and
(require 'vc)
(require 'psvn)
--
Niels Mayer ( http://http://www.curriki.org/xwiki/bin/view/XWiki/NielsMayer)
Curriki: The Global Education & Learning Community
Hello wiki developers,
How can you persist an object accross three pages?
To clarify it further.... Users enter data accross three pages and all that
data has to be stored in the attributes of one object.
When the user hits NEXT button to go from Page 1 to Page 2, he would still
be entering the data of same object as before.
Eagerly awaiting your response,
Regards,
Archana Mettu.
Sorry, haven't had the time to read this thread yet. Just wanted to
say that I'm -1 right now to add a new Admin space. There was one
before and we removed it and put everything in the XWiki space.
Will read more tomorrow in the train.
Thanks
-Vincent
On May 15, 2008, at 2:09 PM, Evelina Slatineanu wrote:
> Hi guys,
>
> After a little more thinking I have found this problem with the
> proposal
> below:
>
> If we keep the admin.vm and all the admin templates for the case of
> an empty
> wiki, we will have code duplication for several sections of the
> administration (like users, groups, rights, panels, import/export)
> because
> we will have the same code in the templates and in the sheets that
> will be
> eventually imported. So the problem is that, at some point, the code
> in the
> templates will become unmaintained and soon deprecated (since
> everyone will
> want to use the new Administration).
>
> Also, as JV pointed well, the cases where someone starts building
> pages from
> scratch in an empty wiki is very rare, so we propose that an empty
> wiki
> should contain only an "Import" section (and therefore, keep only the
> import.vm template). Please vote here ASAP about keeping only the
> Import in
> an empty wiki because otherwise I will be late with the
> implementation (I
> already changed things several times now based on the discussions on
> the
> devs :P) !
>
> Second, we propose to make the Administration as a xwiki application,
> therefore, move it into xwiki-platform-application. We also need
> your vote
> here, please.
>
> I also talked to Sergiu and Jv about adding a special space for the
> Administration application (the Admin space) and put the sheets there.
> Please put your vote here as well.
>
> I also wanted to rename the XWiki.XWikiPreferences to
> Admin.WikiPreferences
> and Anyspace.WebPreferences to Anyspace.SpacePreferences to sound
> more
> "pleasant" but since this will imply a lot of modifs both in core,
> templates
> and wiki pages and affect the compatibility, we should leave them
> alone,
> like they are now.
>
> I hope I'm not forgetting anything important. If you have comments,
> suggestions, proposals please shout ASAP on the devs list.
>
> Thanks a lot,
> Evelina
>
> -----Original Message-----
> From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On
> Behalf Of
> Sergiu Dumitriu
> Sent: Wednesday, May 14, 2008 6:07 PM
> To: XWiki Developers
> Subject: Re: [xwiki-devs] Proposal for the new Administration
>
> Evelina Slatineanu wrote:
>> Hi guys,
>>
>> Thanks Sergiu for the reply. I already implemented a demo of the new
>> Administration by keeping the admin.vm template, as JV said last
>> week.
>>
>> So, from your email and Jv's one what should I choose for the final
>> Administration? Leave the admin template (as I did) or start changing
> things
>> in the core (and yes, I want your help with the observation
>> component, if
> it
>> comes to it)?
>>
>> Thanks,
>> Evelina
>>
>
> There are 2 main issues here:
> 1. How should the administration work when the wiki is empty (no
> sheets)
> 2. How and when should WebPreferences document be created
>
> 1. There are two options, one is to create them from java, similar to
> the way critical classes are initialized or updated if they don't
> exist;
> the other one is to use static skin velocity templates. I'd go for the
> second option, as creating sheets from java is a conflict of roles:
> the
> platform core is supposed to offer some services, not to create wiki
> documents. Plus, there will have to be a synchronization between the
> core and product-enterprise-wiki, which otherwise are completely
> separated.
>
> The admin templates (.vm) should be a failback mechanism; currently
> the
> register.vm checks first if the XWiki.Registration page exists, and if
> it does, displays its content, otherwise it renders a default
> registration page. admin.vm should work in the same way.
> - If the current document is not an administration one
> (XWikiPreferences
> or WebPreferences), then redirect to a proper document (or warn that
> this is not an administration page, whatever is better);
> - otherwise, if the document does not have an XWikiPreferences object
> and does not have a content, add those;
> - if the AdminSheet page exists, display the current document's
> rendered
> content;
> - otherwise, do what it does now (parse static admin${editor} velocity
> files).
> This ensures that the administration is accessible even when the
> database is empty, and it allows each product to have it's own
> administration interface.
>
> I think that the administration part should be separated as an
> application, and not part of XE. This way we can put a warning in
> admin.vm when the admin sheet doesn't exist, something like "This is a
> basic administration interface. We strongly recommend installing the
> [Administration application>http://...wherever-it-is]".
>
> 2. Here there are another 2 options, create the document + object +
> #includeForm from java, using a listener, or from velocity, in the
> admin.vm template. I really don't know what option is better, as there
> are + and - points for each one. The java approach is better
> performance-wise, does not need an extra redirect, and keeps the
> admin.vm template a bit smaller. The velocity approach is better as it
> keeps everything in one file (hm, maybe it can be done without a
> redirect, too). If you already have something working in velocity,
> then
> let's leave it like that.
>
> Instead of redirecting to objectadd, admin.vm should use the API to
> change the document, then save() it. We should see if there's any bug
> here, I hope there isn't, but I'm not sure...
>
> And by the way, I am against creating WebPreferences for all spaces at
> startup, and against creating web preferences when creating the first
> document in a space. What settings should we put there? Why grant
> admin
> rights to the first author? Automatic admin rights is something
> dangerous, IMHO. The administrators should be responsible for proper
> administration, and the preferences should be created when an admin
> visits the administration page.
>
>> -----Original Message-----
>> From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On
>> Behalf Of
>> Jean-Vincent Drean
>> Sent: Friday, May 09, 2008 9:58 PM
>> To: XWiki Developers
>> Subject: Re: [xwiki-devs] Proposal for the new Administration
>>
>> On Fri, May 9, 2008 at 11:12 AM, Jean-Vincent Drean <jv(a)xwiki.com>
>> wrote:
>>> On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu
>>> <evelina.slatineanu(a)xwiki.com> wrote:
>>>> Since the admin templates will be deleted and replaced by an
>>>> AdminSheet
>>>> which will be included by default in XwikiPreferences (wiki
>>>> level) and
>>>> WebPreferences (space level), I need to create the WebPreferences
>> document
>>>> for each space, attach an Xwiki.XwikiPreferences object to it and
> include
>>>> the AdminSheet.
>>>> To do that, I need to write some java code in the core . So ,
>>>> here's my
>>>> proposal:
>>>>
>>>> 1) At xwiki intitialization create all the WebPreferences for the
>>>> currently existing spaces in the wiki (this should be done for
>>>> all the
>>>> wikis, if in a multi-wiki).
>>> I guess a migrator would be the best way to do this.
>>
>> After discussing this with vincent it looks like migrators can't be
>> used for this kind of wiki stuff.
>>
>>>> 2) Then, use a notification system to create the WebPreferences for
>>>> any new space in the wiki in one of two ways:
>>>>
>>>> a) When calling the "view" action on AnySpace.WebPreferences,
>>>> check if
>>>> it exists, if not create it, attach the obj. and include the sheet
>>>> b) When calling the "save" action on AnySpace.AnyDoc, check if
>>>> AnySpace.WebPreferences exists, if not, create it etc.
>>> I'm +1 for 2) b) :
>>> * saving the WebPreferences document on a view action looks bad to
>>> me :
>>> ** we'd have to bypass context user rights when he don't have edit
>>> rights on the space
>>> ** we'd have to check that there's at least 1 page within the
>>> requested space before creating the WebPreferences
>>> ** it will slow down the view request
>>> * it seems logical that the first user to create a page within a
>>> space gets the admin right on it
>>
>> Afterthoughts : It seems complicated to do it that way and having the
>> administration application relying on new core java code would be
>> bad.
>>
>> I guess the best solution is, as Sergiu pointed it before :
>> * keep the admin action (with admin.vm)
>> * make it create the preferences if needed (current behavior)
>> * instead of including sub-templates (admin${editor}.vm) from
>> admin.vm, call contentview.vm
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hello Devs,
This is regarding the SVN integration with XWiki, about which I had been
asking a lot of questions in the past.
So, now we have an applet that helps users browse throught their filesystema
nd upload multiple files with in click.
the uploaded files are commited to SVN. Also, these files are associated
with XWiki objects we created.
The next step is, checking out of SVN.
The scenario is that the user selects a folder on his local system(working
copy) and hits a button that should initiate the ceckout/update from sVN for
all the objects that are on that XWiki page.
What is the best way to achieve this:
1) Is it possible through Velocity (I am sure not...right?)
2) If I write a JAVA class to do the SVNcheckout, how do I integrate it with
XWiki (without messing with the XWiki core...or is that the only way to
accomplish this)
3) Write a servlet and use teh macro includeServlet...If yes, then how is
this doen..I am not evry sure what are the steps to follow to this.
4) any other method?
Any help will be great..
Thanks for all help
Ok.
So I followed all steps but, as expected (for any first time effort) it did
not work :(
Following are the steps I followed:
1) Created the plugin. The plugin's path is rock.xwiki.plugin.svnsynchronize
It has 3 files - the Plugin, PluginApi and one more class which is called in
one of the methods of the PluginApi class.
2) It compiled without errors in Eclipse so, I created the .class file and
placed them in the
\tomcat_v5.5.26\webapps\xwiki\WEB-INF\classes\rock\xwiki\plugin\svnsynchronize
folder.
(now this folder is also in svn so it also has the .svn folder in it...hope
that is not interfering with my plugin)
3) added the following in xwiki.cfg
com.xpn.xwiki.plugin.watchlist.WatchListPlugin,\
rock.xwiki.plugin.svnsynchronize.SVNSynchronizePlugin
4) restarted the xwiki browser and tried the following code:
## Trying SVNSyncronize Plugin
#set($svnApi = $xwiki.svnsynchronize)
#set($mesg=$svnApi.hello())
The message is $mesg
RESULT: $svnApi.hello() :(( (hello() is the same as provided in the
example)
5) I also created a.jar of the 3 plugin classes from Eclipse.
The jar contains a META-INF>MANIFEST.MF
and rock\xwiki\plugin\svnsynchronize\3 classes
Added it to the lib folder - \tomcat_v5.5.26\webapps\xwiki\WEB-INF\lib
tried the code again..but does not work yet.
What am I missing .... any step gone wrong...anything else need to be taken
care of.
xwiki version used: 1.3.2.9174
PLEASE help...
Thanks for all help!
On 5/14/08, Kamna Jain <kammy.scorpi(a)gmail.com> wrote:
>
> Thanks Thomas. That was a great solution. I have started working on it but
> don't know if it works yet.
> but, I had one question about "Creating Xwiki Plugins"
> In the final step of adding the "classes" to the webapps folder, do the
> classes refer to .class files or just .java files. I am assuming .class
> because the alternative is to add the .jar to the lib folder.
>
> It would be great if you could confirm this.
>
> Thanks again
>
>
> On Wed, May 14, 2008 at 10:57 AM, Kamna Jain <kammy.scorpi(a)gmail.com>
> wrote:
>
>> Hello Devs,
>> This is regarding the SVN integration with XWiki, about which I had been
>> asking a lot of questions in the past.
>> So, now we have an applet that helps users browse throught their
>> filesystema nd upload multiple files with in click.
>> the uploaded files are commited to SVN. Also, these files are associated
>> with XWiki objects we created.
>>
>> The next step is, checking out of SVN.
>> The scenario is that the user selects a folder on his local system(working
>> copy) and hits a button that should initiate the ceckout/update from sVN for
>> all the objects that are on that XWiki page.
>>
>> What is the best way to achieve this:
>> 1) Is it possible through Velocity (I am sure not...right?)
>> 2) If I write a JAVA class to do the SVNcheckout, how do I integrate it
>> with XWiki (without messing with the XWiki core...or is that the only way to
>> accomplish this)
>> 3) Write a servlet and use teh macro includeServlet...If yes, then how is
>> this doen..I am not evry sure what are the steps to follow to this.
>>
>> 4) any other method?
>>
>> Any help will be great..
>>
>> Thanks for all help
>>
>
>
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.4 final.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release spanned a bit more than 2 months starting on the 8th of
March 2008 and ending on the 15th of May 2008.
During that period we implemented 116 issues, fixing 67 bugs and
adding new features such as:
* Attachment Rollback, when rollbacking a wiki page, attachments
versions are now rollbacked as well.
* 2 new colors were added for the toucan skin : Black & Dark Blue.
* Various performance improvements.
* New Admin page to monitor Requests in your XWiki instance
* The Index page was improved to add realtime page filtering.
* Keyboard shortcuts were made a generic feature using a standard
keyboard shortcuts set, see http://tinyurl.com/3hnvge
* The Watchlist feature now adds a diff in the email it sends when
watched documents or spaces are modified. The diff is between "first
revision since last notification" and "last revision".
* Added better Active Directory support by supporting case
insensitive username.
* Added Galician translation
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise14
Thanks
-The XWiki dev team
Evelina Slatineanu wrote:
> Also, as JV pointed well, the cases where someone starts building pages from
> scratch in an empty wiki is very rare, so we propose that an empty wiki
> should contain only an "Import" section (and therefore, keep only the
> import.vm template). Please vote here ASAP about keeping only the Import in
> an empty wiki because otherwise I will be late with the implementation (I
> already changed things several times now based on the discussions on the
> devs :P) !
+1
> Second, we propose to make the Administration as a xwiki application,
> therefore, move it into xwiki-platform-application. We also need your vote
> here, please.
+1
> I also talked to Sergiu and Jv about adding a special space for the
> Administration application (the Admin space) and put the sheets there.
> Please put your vote here as well.
+1
--
Artem Melentyev
On Thu, May 15, 2008 at 2:09 PM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
> Hi guys,
>
> After a little more thinking I have found this problem with the proposal
> below:
>
> If we keep the admin.vm and all the admin templates for the case of an empty
> wiki, we will have code duplication for several sections of the
> administration (like users, groups, rights, panels, import/export) because
> we will have the same code in the templates and in the sheets that will be
> eventually imported. So the problem is that, at some point, the code in the
> templates will become unmaintained and soon deprecated (since everyone will
> want to use the new Administration).
>
> Also, as JV pointed well, the cases where someone starts building pages from
> scratch in an empty wiki is very rare, so we propose that an empty wiki
> should contain only an "Import" section (and therefore, keep only the
> import.vm template). Please vote here ASAP about keeping only the Import in
> an empty wiki because otherwise I will be late with the implementation (I
> already changed things several times now based on the discussions on the
> devs :P) !
I'm +1 for this but only if administration is an application (or a set
of administration applications) which can work on a empty wiki
(without XE xar).
>
> Second, we propose to make the Administration as a xwiki application,
> therefore, move it into xwiki-platform-application. We also need your vote
> here, please.
+1 as I already said for previous vote part.
>
> I also talked to Sergiu and Jv about adding a special space for the
> Administration application (the Admin space) and put the sheets there.
> Please put your vote here as well.
+1 for special space containing administration application(s)
>
> I also wanted to rename the XWiki.XWikiPreferences to Admin.WikiPreferences
> and Anyspace.WebPreferences to Anyspace.SpacePreferences to sound more
> "pleasant" but since this will imply a lot of modifs both in core, templates
> and wiki pages and affect the compatibility, we should leave them alone,
> like they are now.
Yes would be a really big and dangerous work to change this.
>
> I hope I'm not forgetting anything important. If you have comments,
> suggestions, proposals please shout ASAP on the devs list.
>
> Thanks a lot,
> Evelina
>
> -----Original Message-----
> From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of
> Sergiu Dumitriu
> Sent: Wednesday, May 14, 2008 6:07 PM
> To: XWiki Developers
> Subject: Re: [xwiki-devs] Proposal for the new Administration
>
> Evelina Slatineanu wrote:
>> Hi guys,
>>
>> Thanks Sergiu for the reply. I already implemented a demo of the new
>> Administration by keeping the admin.vm template, as JV said last week.
>>
>> So, from your email and Jv's one what should I choose for the final
>> Administration? Leave the admin template (as I did) or start changing
> things
>> in the core (and yes, I want your help with the observation component, if
> it
>> comes to it)?
>>
>> Thanks,
>> Evelina
>>
>
> There are 2 main issues here:
> 1. How should the administration work when the wiki is empty (no sheets)
> 2. How and when should WebPreferences document be created
>
> 1. There are two options, one is to create them from java, similar to
> the way critical classes are initialized or updated if they don't exist;
> the other one is to use static skin velocity templates. I'd go for the
> second option, as creating sheets from java is a conflict of roles: the
> platform core is supposed to offer some services, not to create wiki
> documents. Plus, there will have to be a synchronization between the
> core and product-enterprise-wiki, which otherwise are completely separated.
>
> The admin templates (.vm) should be a failback mechanism; currently the
> register.vm checks first if the XWiki.Registration page exists, and if
> it does, displays its content, otherwise it renders a default
> registration page. admin.vm should work in the same way.
> - If the current document is not an administration one (XWikiPreferences
> or WebPreferences), then redirect to a proper document (or warn that
> this is not an administration page, whatever is better);
> - otherwise, if the document does not have an XWikiPreferences object
> and does not have a content, add those;
> - if the AdminSheet page exists, display the current document's rendered
> content;
> - otherwise, do what it does now (parse static admin${editor} velocity
> files).
> This ensures that the administration is accessible even when the
> database is empty, and it allows each product to have it's own
> administration interface.
>
> I think that the administration part should be separated as an
> application, and not part of XE. This way we can put a warning in
> admin.vm when the admin sheet doesn't exist, something like "This is a
> basic administration interface. We strongly recommend installing the
> [Administration application>http://...wherever-it-is]".
>
> 2. Here there are another 2 options, create the document + object +
> #includeForm from java, using a listener, or from velocity, in the
> admin.vm template. I really don't know what option is better, as there
> are + and - points for each one. The java approach is better
> performance-wise, does not need an extra redirect, and keeps the
> admin.vm template a bit smaller. The velocity approach is better as it
> keeps everything in one file (hm, maybe it can be done without a
> redirect, too). If you already have something working in velocity, then
> let's leave it like that.
>
> Instead of redirecting to objectadd, admin.vm should use the API to
> change the document, then save() it. We should see if there's any bug
> here, I hope there isn't, but I'm not sure...
>
> And by the way, I am against creating WebPreferences for all spaces at
> startup, and against creating web preferences when creating the first
> document in a space. What settings should we put there? Why grant admin
> rights to the first author? Automatic admin rights is something
> dangerous, IMHO. The administrators should be responsible for proper
> administration, and the preferences should be created when an admin
> visits the administration page.
>
>> -----Original Message-----
>> From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of
>> Jean-Vincent Drean
>> Sent: Friday, May 09, 2008 9:58 PM
>> To: XWiki Developers
>> Subject: Re: [xwiki-devs] Proposal for the new Administration
>>
>> On Fri, May 9, 2008 at 11:12 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
>>> On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu
>>> <evelina.slatineanu(a)xwiki.com> wrote:
>>>> Since the admin templates will be deleted and replaced by an AdminSheet
>>>> which will be included by default in XwikiPreferences (wiki level) and
>>>> WebPreferences (space level), I need to create the WebPreferences
>> document
>>>> for each space, attach an Xwiki.XwikiPreferences object to it and
> include
>>>> the AdminSheet.
>>>> To do that, I need to write some java code in the core . So , here's my
>>>> proposal:
>>>>
>>>> 1) At xwiki intitialization create all the WebPreferences for the
>>>> currently existing spaces in the wiki (this should be done for all the
>>>> wikis, if in a multi-wiki).
>>> I guess a migrator would be the best way to do this.
>>
>> After discussing this with vincent it looks like migrators can't be
>> used for this kind of wiki stuff.
>>
>>>> 2) Then, use a notification system to create the WebPreferences for
>>>> any new space in the wiki in one of two ways:
>>>>
>>>> a) When calling the "view" action on AnySpace.WebPreferences, check if
>>>> it exists, if not create it, attach the obj. and include the sheet
>>>> b) When calling the "save" action on AnySpace.AnyDoc, check if
>>>> AnySpace.WebPreferences exists, if not, create it etc.
>>> I'm +1 for 2) b) :
>>> * saving the WebPreferences document on a view action looks bad to me :
>>> ** we'd have to bypass context user rights when he don't have edit
>>> rights on the space
>>> ** we'd have to check that there's at least 1 page within the
>>> requested space before creating the WebPreferences
>>> ** it will slow down the view request
>>> * it seems logical that the first user to create a page within a
>>> space gets the admin right on it
>>
>> Afterthoughts : It seems complicated to do it that way and having the
>> administration application relying on new core java code would be bad.
>>
>> I guess the best solution is, as Sergiu pointed it before :
>> * keep the admin action (with admin.vm)
>> * make it create the preferences if needed (current behavior)
>> * instead of including sub-templates (admin${editor}.vm) from
>> admin.vm, call contentview.vm
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
Hi,
We need to finalize the XE 1.4 release date. I propose that we don't
do a RC2 unless a big bug shows up. I've reviewed the jira isssues
scheduled for RC2 and I'm confident we can push them all for 1.5M1.
Thus I'd like to propose that:
1) we don't commit stuff anymore on the 1.4 branch unless they are
*important* bug fixes.
2) we release the 1.4 final on the 14th of May (JV will be the release
manager).
Here's my +1
Thanks
-Vincent
On Thu, May 15, 2008 at 2:09 PM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
>
> Also, as JV pointed well, the cases where someone starts building pages from
> scratch in an empty wiki is very rare, so we propose that an empty wiki
> should contain only an "Import" section (and therefore, keep only the
> import.vm template). Please vote here ASAP about keeping only the Import in
> an empty wiki because otherwise I will be late with the implementation (I
> already changed things several times now based on the discussions on the
> devs :P) !
>
I'm +1 with this, not because it may be faster to implement but
because I'm afraid admin templates would be, sooner or later,
deprecated.
> Second, we propose to make the Administration as a xwiki application,
> therefore, move it into xwiki-platform-application. We also need your vote
> here, please.
+1
> I also talked to Sergiu and Jv about adding a special space for the
> Administration application (the Admin space) and put the sheets there.
> Please put your vote here as well.
-0.5. I don't know if we have a convention about this but putting all
the 'system' pages in XWiki :
- it makes the adminstration work easier (there's one space that
really needs to be protected)
- ftm we can't set a space to be hidden from the wiki tree or spaces lists
+ almost all our applications have their own dedicated space (Stats,
Panels, etc)
--
Jean-Vincent Drean
