- xwiki-devs@xwiki.org - lists.xwiki.org

by Archana Mettu

Hello developers, 1. Is it possible to create two separate classsheets to render the objects of the same class? One with a 'View only' presentation and the other with an 'Edit & View' presentation? The default classSheets have a 'view only'. How can I invoke the 'edit' previleges and do an 'Update' to object data in the database? 2. How do I go about calling these different classsheets from the same template? Will I need two classtemplates? 3. Is it possible to send an Object handler, document name or object id from one page to another? The HTML Post does'nt seem to do what I want. Regards, Archana Mettu.

17 years, 4 months

1
0
0 0

[xwiki-devs] Easy way to work on the stable 1.4 branch

by Ludovic Dubost

Hello, Is there an easy way to work on the stable 1.4 branch. I would like to work on some improvements to the form validation system but I don't want the hassle of the changes that will come up in 1.5 until I have a nice patch ready. What are the 1.4 branches neede do get platform-web running and is there a way to all get them at once. I've seen: - xwiki-core-1.4 - xwiki-web-1.4 - xwiki-toucan-1.2 (is that a 1.4 branch ?) - xwiki-albatross-1.4 Are there any plugin branches ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

17 years, 4 months

2
1
0 0

[xwiki-devs] Why should I care about OSGi article

by Vincent Massol

nice article: http://blog.springsource.com/main/2008/05/15/why-should-i-care-about-osgi-a… I think we already support most points through: * Our conventions of using the internal package for non user public code. BTW we can (and we should) enforce this at build time and fail the build if someone is using the internal package using the maven enforcer plugin. * The fact that we're using maven and components creates clean boundaries between modules and allows different teams to focus their work on some subpart of the system. * Dependency mgmt: done with Maven Nice things we don't currently have: * "Faster testing cycles". We already have a way to do with Eclipse but this is a part that could be improved. * "isolate changes". This can be done with Plexus (+ classworld) later on but we're not using this feature yet. This could also be done with XBean I believe. In summary I don't think we're too bad compared to the list of advantages listed in the article. We're working on improving that but we're already on good tracks. The single most important thing we have to do is modularize the core into components and well-delimited build modules. -Vincent

17 years, 4 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r9842 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/rcs

by Vincent Massol

On May 17, 2008, at 3:44 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-05-17 03:44:04 +0200 (Sat, 17 May 2008) > New Revision: 9842 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > doc/rcs/XWikiRCSArchive.java > Log: > XWIKI-2379: Import fails on document archive field > Fixed, I hope > > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/doc/rcs/XWikiRCSArchive.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > doc/rcs/XWikiRCSArchive.java 2008-05-17 00:59:08 UTC (rev 9841) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > doc/rcs/XWikiRCSArchive.java 2008-05-17 01:44:04 UTC (rev 9842) > @@ -153,7 +153,7 @@ > // empty author is error in jrcs > if (user == null || "".equals(user)) { > super.setAuthor(sauthorIfEmpty); > - } else { > + } else { > byte[] enc = URLCodec.encodeUrl(safeAuthorChars, > user.getBytes()); > String senc = new String(enc).replace('%', '_'); > super.setAuthor(senc); > @@ -170,12 +170,17 @@ > result = result.replace('_', '%'); > try { > byte[] dec = > URLCodec.decodeUrl(result.getBytes()); > - String sdec = new String(dec); > - return sdec; > + result = new String(dec); > } catch (DecoderException e) { > - throw new Error(e); > + // Probably the archive was created before > introducing this encoding (1.2M1/M2). > + result = super.getAuthor(); > + if (!result.matches("^(\\w|\\d|\\.)++$")) { > + // It's safer to use an empty author than > to use an invalid value. > + result = ""; shouldn't we log a warning here? [snip] Thanks -Vincent

17 years, 4 months

1
0
0 0

[xwiki-devs] Adding Space information to the context - follow up

by Kamna Jain

Hi, So, I tried the querystring option. Didn't quite work. We have a form that we ask the user to fill on page 1 and this form represents only a PART of an object that gets created for this particular form. So, say for eg., we have a name field in the form and this gets copied on to the underlying obect when we click a button. Now, currently when we cllick the button on this page, we have a script that is run and what that does is - Creates a new object, creates a new document with the name entered by the user in the form, adds the new object to this document and copies all form fields to the Object properties. Finally the script redirects the user to the newly created page which displays the object with the help of the class sheet. (the following is the last line of the script which does the redirect) $response.sendRedirect($newdoc.getURL("save", "template=${etemplate}&parent=${eparent}&title=$etitle")) Now, our use case has changed a little bit, in the sense that, the user will need to enter form field values (object values in xwiki) on a sequence of pages, i.e, everything does not get added to the object the first time a button is clilcked. In this case, to be able to copy the values from the Page 2 to the same object as was created in Page 1, we need some way to access the same object. This could be done using the object name and as seen in the response.sendRedirect line above, we pass the title (which is the name entered by the user) to the next page (newdoc page in this case). But, when I try to access this on that newdoc, I do not get a value I am expecting. So, what am I doing wrong when I try this scritp on the newdoc: #set($title = $request.getParameter("title")) The title : $title This returns: The title : XWiki - $doc.web - $doc.name #set($template = $request.getParameter("template")) The template : $template This returns: The title : $template Please point out whats wrong in this usage and if it is valid in the first place! Also, what alternative could we use. I mean how to access the application context in the velocity scripts? Thanks much for all help.

17 years, 4 months

1
0
0 0

[xwiki-devs] XBeans

by Vincent Massol

Hi devs, Just a quick note to let you know of XBeans: http://geronimo.apache.org/xbean/index.html I haven't researched it but I know it plays well with Plexus. At some point we'll probably need to decide if we want to go the OSGi route or use Plexus + XBeans, or use the Plexus OSGi bridge, or... Anyway our work is still to transform our monolithic code base into components for now and that's what we should be focusing on. We can delay the choice of the IOC tool/component manager to later for now. Thanks -Vincent

17 years, 4 months

2
2
0 0

[xwiki-devs] Questions on the new XMLRPC implementation tests

by Vincent Massol

Hi Fabio, I was looking at the new XMLRPC tests and I think there are some unfinished stuff we need to clean up/align. Right now there are 2 series of tests: ones in com.xpn package and one in org.xwiki package: addTestCase(suite, AnonymousAccessTest.class); addTestCase(suite, AttachmentsTest.class); addTestCase(suite, CommentsTest.class); addTestCase(suite, PagesTest.class); addTestCase(suite, SpacesTest.class); addTestCase(suite, org.xwiki.xmlrpc.AttachmentsTest.class); addTestCase(suite, org.xwiki.xmlrpc.AuthenticationTest.class); addTestCase(suite, org.xwiki.xmlrpc.CommentsTest.class); addTestCase(suite, org.xwiki.xmlrpc.PagesTest.class); addTestCase(suite, org.xwiki.xmlrpc.SpacesTest.class); addTestCase(suite, org.xwiki.xmlrpc.XWikiClassesTest.class); addTestCase(suite, org.xwiki.xmlrpc.XWikiObjectsTest.class); addTestCase(suite, org.xwiki.xmlrpc.SearchTest.class); We need to merge them (not sure why there are 2 locations). The correct package is probably com.xpn since the org.xwiki one is reserved for new components. Also I've noticed that lots of your new tests are using System.out calls. I don't think we should do that. The tests shouldn't print anything at all. They should do asserts wherever required but they should not require any visual verification to verify that they have passed or not IMO. Also this is the strategy we've followed so far. WDYT? Do you think you could have a look at those points? Thanks a lot -Vincent

17 years, 4 months

2
2
0 0

[xwiki-devs] Adding space information to the context.

by Kamna Jain

Hello Devs, Is it possible to use $context.put in the following way: $context.put("space","Main") where space is the key and Main is the value of Space and then retrieve it using $context.get("space") on any page in xwiki! I tried using it but did not work and did not throw any exception either. I am trying to simulate login based on spaces in XWiki Enterprise and this information will be very helpful. Also, if I wanted to change the "function" that is called when a login form is submitted (loginsubmit action), where do I do that. Thanks

17 years, 4 months

2
2
0 0

[xwiki-devs] useful tools for dealing with xwiki code

by Niels Mayer

(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/EmacsVtlMode http://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

17 years, 4 months

1
0
0 0

[xwiki-devs] Urgent! Looking for answers

by Archana Mettu

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.

17 years, 4 months

2
1
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Vincent Massol

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

17 years, 4 months

1
0
0 0

[xwiki-devs] Downloading from SVN repository..

by Kamna Jain

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

17 years, 4 months

4
8
0 0

[xwiki-devs] XWiki Plugin not working

by Kamna Jain

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 >> > >

17 years, 4 months

2
1
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.4 Released

by Jean-Vincent Drean

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

17 years, 4 months

1
0
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Artem Melentyev

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

17 years, 4 months

1
0
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Thomas Mortagne

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

17 years, 4 months

1
0
0 0

[xwiki-devs] [VOTE] XE 1.4 final release date

by Vincent Massol

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

17 years, 4 months

5
5
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Jean-Vincent Drean

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

17 years, 4 months

1
0
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Sergiu Dumitriu

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/

17 years, 4 months

2
1
0 0

[xwiki-devs] [proposal] Enable some commons-lang classes as velocity tools

by Sergiu Dumitriu

Hi devs, I'd like to enable some classes from the commons-lang library as velocity tools. As a reminder, a velocity tool is an object that is placed in the velocity context, and which can be used to perform some actions. The tool should be stateless and thread-safe, as the same object is used for all requests. There is the VelocityTools library, which contains some useful tools, but I think those are not enough. So, I'd like to enable StringUtils, WordUtils, RandomStringUtils, StringEscapeUtils, BooleanUtils, ArrayUtils, math.NumberUtils, math.RandomUtils, time.DateUtils, time.DateFormatUtils Given the fact that tools are only create once, there won't be any memory issue. And I think that these tools are wide enough to discourage any attempt to add nice methods to the XWiki class, and will allow to deprecate utility methods in the XWiki API, and remove the Util API. Any objections? Any other classes we should enable? -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 4 months

2
2
0 0

[xwiki-devs] Wysiwyg editor questions

by archana m

Hello, I am dealing with the following issues... 1. The default properties available to add to a class is a limited list. Is it possible to extend that list? Is it possible to provide a Wysiwyg editor embedded in a class, without giving users 'edit' rights to the wiki-page? I am just looking for a user-friendly text-area where users can add descriptions that can be stored and retrieved as objects. 2. How to store the contents of wysiwyg editor to a file? 3. Is it possible to launch Microsoft Documents, text files and HTML files stored on a server or the local file-system in wysiwyg with URL path as the input? If no, can you please suggest any alternative solutions? I'd appreciate your help. Regards, Archana Mettu.

17 years, 4 months

1
0
0 0

[xwiki-devs] Groovy roadmap

by shivshan

Hi Is there is a roadmap for supporting the latest groovy versions? I am aware that there were some issues when the upgrade to 1.0 was tried earlier. However, Groovy 1.5 has been released and apparently there are some major performance benefits. Put another way, what is the priority within the developer community to fix the existing issues and/or move to the latest groovy version? Thanks Shiva -- View this message in context: http://www.nabble.com/Groovy-roadmap-tp17185652p17185652.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 4 months

2
1
0 0

Re: [xwiki-devs] Proposal for the new Administration

by Jean-Vincent Drean

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. > 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 > notify(XWikiNotificationRule rule, XWikiDocument doc, String action, XWikiContext context) That's the usual way to do what is described in 2) b). > Thomas Mortagne also told me that this notif system is a little bit outdated > and would be replaced by the observation component, but I have no idea which > I should use. I don't know this component as well. > Also, according to the specifs in the draft above, so far I created the > Xwiki.AdminSheet, that will display the main categories (General, > Presentation, Rights, Users, Groups, Import/Export etc). For each section of > this menu I created a sheet (General - > Xwiki.GeneralSheet etc.) in which I > can personalize the display. I also created Xwiki.AdminSectionSheet which > contains the common code to display the fields necessary from the > Xwiki.XwikiPreferences object and this sheet will be included in the > sections where is needed (Genera, Presentation etc.) The reason I created > separated sheets for each section of the menu (which are fixed as number) is > to keep the code clean and allow the possibility to display something else > than fields from the xwiki prefs. object (for example for rights, users, > groups, import/export). > > I would really really appreciate some feedback for this 2 proposals. Looks good to me. ++, -- Jean-Vincent Drean

17 years, 4 months

2
2
0 0

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.2 Release Candidate 1 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.2 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This release follow XWiki Enterprise 1.4 Release Candidate 1 release to maintain XEM synchronised with XE. It add the wiki name ajax based validation to the wiki creation page and XE 1.4M2 -> XE 1.4RC1 dependency upgrade. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12RC1 Thanks -The XWiki dev team

17 years, 4 months

1
0
0 0

[xwiki-devs] Branching Lucene plugin

by Vincent Massol

Hi, Just to let you know I'm going to branch the Lucene plugin. I need that since in the patch I'm writing for ThreadLocal I need to have it depend on core 1.5. This means Trunk will be Lucene plugin 1.3 (depending on core 1.5) while the branch will be 1.2 (depending on core 1.4). Ok with everyone? I'll create that later today. Thanks -Vincent

17 years, 4 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs