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

[xwiki-devs] [Important] More stability needed - To all committers
by Vincent Massol 08 Apr '08

08 Apr '08

Hi everyone, I don't know if you're like me but I have the strong feeling we should be better at not introducing regressions. One of the goal of XE 1.3 and now again XE 1.4 was more stability and more automated tests. Several potential problems are occurring now: 1) People using XWiki are expecting more stability when they upgrade. This is due to the fact that XWiki is improving in general and more people use it. It's expected that it'll just work and that's a reasonable expectations 2) We've introduced several important regressions for the past *4* releases (login/logout/RMUI/Escapes and more). We're following a bas trend. 3) We've recently introduced several storage changes (Sergiu and Artem) and I haven't seen tests that would prove what was working before is still working. I'm not saying it isn't but last time we made a change to the storage area it took us several months to stabilize it and we cannot do that again. 4) We're committing more code than tests meaning the overall quality of XWiki is degrading :( Thus I'd like to propose that: A) We become very very careful when committing things and we only commit when we can *guarantee* that what we've done is working (with a given level of confidence of course). This can only be achieved through tests being committed at the same time as the code is committed B) We stop putting stuff that are NOT critical in point releases. For example dangerous changes were done in the WYSIWYG editor for 1.3.1 and I'm not confident this was a good thing, and certainly not with so little tests and verifications since we know that whenever we touch that editor we introduce problems elsewhere. C) In general we reduce the number of changes that we commit and instead we focus on tests and stability. This is indeed one of the general goals for 1.4. WDYT? Thanks -Vincent

6 10

[xwiki-devs] Script that is run when users want to attach files to an XWiki page ?
by Kamna Jain 08 Apr '08

08 Apr '08

Hello, I have been looking out for the code /script that handles the UI and the functionality of the UI for attachments section of an Xwiki page. These are the places I have looked at: 1) com.xpn.xwiki.web.AttachAction.java 2) com.xpn.xwiki.web.UploadAction.java 3) Fileupload plugin 4) XWiki Enterprise\webapps\xwiki\wiki_editor\plugins\attachments.js 5) HTML source code of any XWiki page ! the reason I am looking for it, is to try to see how I can modify the code to allow *selection of multiple files for upload at one time* ! In our application, users ight be required to upload more than 10 files at a time and we do not want them to browse to the file system for every file! If someone can point out anything that might help, it would be great. Thanks

1 0

Re: [xwiki-devs] FW: Request for iCal4j API
by Ludovic Dubost 08 Apr '08

08 Apr '08

Yes it would be better to add any API you need in the current CalendarPlugin. There are already a function that generates an ics file but from a CalendarData object public String toICal(CalendarData data) Ludovic Evelina Slatineanu wrote: > Hi, > > > > I've taken a closer look at the Calendar plugin in xwiki-platform-core and I > believe that maybe is not necessary to create a whole new plugin for > generating ics files but to include in the existing plugin a method of > saving a calendar in .ics format. I wait for your opinions. > > > > Thanks. > > Evelina > > > > From: Evelina Slatineanu [mailto:evelina.slatineanu@xwiki.com] > Sent: Tuesday, April 08, 2008 12:32 PM > To: 'devs(a)xwiki.org' > Subject: Request for iCal4j API > > > > Hello all, > > > > I have a situation in Chronopolys where I would like to generate an iCal for > some deadlines widgets I made. I spoked to JV and Sergiu and find out that > there are some methods of parsing an iCal file in the Calendar plugin but > there is nothing to create a new iCal file. So, I would like to propose an > xwiki generic plugin to both create and parse iCals. I can do this, using > http://ical4j.sourceforge.net/introduction.html > > > > Please tell me your opinions. > > Thanks, > > > > Evelina > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 3008 (20080408) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 3009 (20080408) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0

Re: [xwiki-devs] FW: Request for iCal4j API
by ancapaula.luca＠xwiki.com 08 Apr '08

08 Apr '08

That sounds good. +1 > Hi, > > > > I've taken a closer look at the Calendar plugin in xwiki-platform-core and > I > believe that maybe is not necessary to create a whole new plugin for > generating ics files but to include in the existing plugin a method of > saving a calendar in .ics format. I wait for your opinions. > > > > Thanks. > > Evelina > > > > From: Evelina Slatineanu [mailto:evelina.slatineanu@xwiki.com] > Sent: Tuesday, April 08, 2008 12:32 PM > To: 'devs(a)xwiki.org' > Subject: Request for iCal4j API > > > > Hello all, > > > > I have a situation in Chronopolys where I would like to generate an iCal > for > some deadlines widgets I made. I spoked to JV and Sergiu and find out that > there are some methods of parsing an iCal file in the Calendar plugin but > there is nothing to create a new iCal file. So, I would like to propose an > xwiki generic plugin to both create and parse iCals. I can do this, using > http://ical4j.sourceforge.net/introduction.html > > > > Please tell me your opinions. > > Thanks, > > > > Evelina > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3008 (20080408) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3009 (20080408) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

1 0

[xwiki-devs] FW: Request for iCal4j API
by Evelina Slatineanu 08 Apr '08

08 Apr '08

Hi, I've taken a closer look at the Calendar plugin in xwiki-platform-core and I believe that maybe is not necessary to create a whole new plugin for generating ics files but to include in the existing plugin a method of saving a calendar in .ics format. I wait for your opinions. Thanks. Evelina From: Evelina Slatineanu [mailto:evelina.slatineanu@xwiki.com] Sent: Tuesday, April 08, 2008 12:32 PM To: 'devs(a)xwiki.org' Subject: Request for iCal4j API Hello all, I have a situation in Chronopolys where I would like to generate an iCal for some deadlines widgets I made. I spoked to JV and Sergiu and find out that there are some methods of parsing an iCal file in the Calendar plugin but there is nothing to create a new iCal file. So, I would like to propose an xwiki generic plugin to both create and parse iCals. I can do this, using http://ical4j.sourceforge.net/introduction.html Please tell me your opinions. Thanks, Evelina __________ Information from ESET NOD32 Antivirus, version of virus signature database 3008 (20080408) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3009 (20080408) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

1 0

[xwiki-devs] Request for iCal4j API
by Evelina Slatineanu 08 Apr '08

08 Apr '08

Hello all, I have a situation in Chronopolys where I would like to generate an iCal for some deadlines widgets I made. I spoked to JV and Sergiu and find out that there are some methods of parsing an iCal file in the Calendar plugin but there is nothing to create a new iCal file. So, I would like to propose an xwiki generic plugin to both create and parse iCals. I can do this, using http://ical4j.sourceforge.net/introduction.html Please tell me your opinions. Thanks, Evelina

1 0

[xwiki-devs] XWiki CRUD
by Ludovic Dubost 08 Apr '08

08 Apr '08

I've done some experiments to improve applications creating in XWiki. Here is a proposal to allow CRUD (Create, Read, Update, Delete) in XWiki in a more easy manner. The proposal is also available here: http://dev.xwiki.org/xwiki/bin/view/Design/XWikiCRUD The idea is to be able to control all this from an XWiki Class. Some configuration fields would be available for the edit class user interface. Let's take the following use case of creating a client database: - the developer would define an XWiki class with the field describing the clients: name, address, client type, city, country - the developer would choose in the XWiki class the default space to hold the client documents: Clients - the developer would choose an alias for the URL to access the CRUD features: clients - the developer would choose optionnaly to override sheets for the view, edit, create, search, list actions - the developer would choose optionnaly validation controls for the fields or for the whole class (would be used by the create and edit forms automatically) - the developer would choose optionnaly which fields should be visible on the view/edit form and the list/search results - the developer would choose the field to be used to generate the wiki page name for the created documents. If none is set a counter would be used. By doing this. automatically would be made available the following URLs: - /xwiki/bin/clients/create This URL would show the creation form. It would either be the standard one showing the visible fields or the custom form defined in the Create sheet. This is currently equivalent to the 2 step process to create a document with a form. It would be in one step, thanks to the automatic generating of page name using the field in the settings. The document would automatically be created in the space specified in the class settings. /xwiki/bin/clients/view/PageName or /xwiki/bin/clients/PageName This URL would show the view form. It would either be the standard one showing the visible fields or the custom form defined in the Create sheet. This is equivalent to the current document view of a document with a form. Now it would not be necessary to add #includeForm in the content of the document. The content field would still be usable. The wiki document would still be available through it's standard document URL in the space where it is. We would need to decide if we automatically redirect one URL to the other. /xwiki/bin/clients/edit/PageName This URL would show the edit form. It would either be the standard one showing the visible fields or the custom form defined in the Create sheet. This is equivalend to the inline view of a document with a form. Now it would not be necessary to add #includeForm in the content of the document. The content field would still be usable. /xwiki/bin/clients/list or /xwiki/bin/clients/ This URL would allow to show a list of documents with pagination. It would show the columns specified in the class settings. This is equivalent to velocity script we usually create to show the list of documents matching a class. /xwiki/bin/clients/search This URL would allow to show a search interface allowing to choose multiple criterias and search for documents of the class. The results would be similar to the list action. Automatically similar actions would return the same results in XML, RSS or JSON giving a REST interface to the data of the class. The results from these forms would also be available through easy to use velocity macros to be used in other places of the XWiki site. Some questions are still open: - In this scheme, the pages are still available through 2 URLs. We could decide the alias is the space name (automatically) and then the "create, search, list" would be implicit page names in the space. The normal page name URL could be used instead of the new view and edit URLs. The skins can handle this and look for the class params as long as there is some information telling us with class information to use. - The URLs are inverted versus our current URL scheme. An approach could be to stay with the current way to handle URLs and add the create, search, list actions on a space with our without using the alias but the space name. Without alias (only one class by space) /xwiki/bin/create/Clients/ /xwiki/bin/list/Clients/ /xwiki/bin/search/Clients/ With alias (with multiple classes per space, but conflict between alias and space name in view and edit mode): /xwiki/bin/create/clients/ /xwiki/bin/list/clients/ /xwiki/bin/search/clients/ Any ideas, suggestions, remarks ? -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 3

[xwiki-devs] A New Comer.
by Asiri Rathnayake 07 Apr '08

07 Apr '08

Hi Devs, I want to introduce a student (Jinath Sanjitha) to you who is interested in opensource development. He is very new to the field and i told him XWiki is a nice place to get started ;). So can anyone of you ( core devs ) guide him in the correct direction ? I will render my assistance to get him familiar with xwiki (what it is, build process and so on) but someone more experienced should allocate him some task (i don't know if this is the right way). Thanks a lot. - Asiri

2 1

[xwiki-devs] [ANN] XWiki Watch Milestone 4 Released
by ancapaula.luca＠xwiki.com 07 Apr '08

07 Apr '08

XWiki Watch 1.0 Milestone 4 Released The XWiki development team is pleased to announce the release of XWiki Watch 1.0 Milestone 4. You can go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiWatch. This release include both bug fixes and new features, among which you can find: * Upgraded to GWT 1.4 which improves performance and brings new features * Added autosuggest for article tags * Added delete and edit actions to groups and keywords as well as a mechanism to delete fetched articles upon deleting a feed * Various bugfixes and improvements Check the full release notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWatch10M4 and the installation guide at http://code.xwiki.org/xwiki/bin/view/Applications/WatchApplication for more details. Have fun! The XWiki Watch development team

1 0

[xwiki-devs] XSL Plugin
by Marco Casavecchia Morganti 07 Apr '08

07 Apr '08

Hello all, I hope that my previous post were rejected by the moderator because of size of the attachment. All I wanted to say was that i developed a new plugin. It can include and transform external resources into xwiki pages. I used it to embed my pages with some external RSS feeds. The plugin is based upon xsl transformations. I attach to this mail only the README included into the package. Tell me if you are intrested. Hope to be useful. -- By MCM. Hello, This is a simple plugin that lets you include an external content into any xwiki page. Actually I used it to show external RSS contents into "dynamic" panels. To work properly the plugin needs an XSL template that produces the desired html code from the source content. The "example" directory of this package countains a simple XSL stylesheet that transform an RSS 2.0 feed into an html fragment. How to build it: - A precompiled version (only for JDK 1.5) is available into the dist/lib directory of the package. - you can build the whole project by typing: ant -f ant/build.xml dist How to install: - Copy all the jars from the "dist/lib" directory into the "WEB-INF/lib" of your XWiki installation. - Edit your "WEB-INF/xwiki.cfg" and add the following line into the "xwiki.plugins" section: com.xpn.xwiki.plugin.xsltransformer.XslURITransformerPlugin - At the end of the same file, append the following lines (WEB-INF/xwiki.cfg) #XSLTransormer Plugin configuration parameters xwiki.xsluritransformer.debug=disabled xwiki.xsluritransformer.connectiontimeout=15000 xwiki.xsluritransformer.fallbackencoding=UTF-8 - Restart your XWiki How to use it: - First of all you need a new Wiki page, so create it. - Now you have to attach the "example/rss2xhtml.xsl" file to the page. - Go to edit the page and add the following snippet code (change the uri with something that works ;O): $xwiki.xslURITransformer.cachedTransformURI("http://rss.host/path/to/the/rssfeed.xml","http://your.wiki.host/xwiki/bin/download/path/to/the/attached/rss2xhtml.xsl", "900") - Save the page and enjoy the included and reformatted rss ;O) How does it works: The plugnin uses 2 http connections to fetch the source and the xsl (that i often attach to the same page) and performs the transformation. It has 2 functions that performs the same work but in 2 different ways: $xwiki.xslURITransformer.cachedTransformURI(SourceURI,XSLURI,Timeout) $xwiki.xslURITransformer.transformURI(SourceURI,XSLURI) Common parameters: The SourceURI parameter is the full URI of the resource that you want include. The XSLURI parameter is the full URI of the XSL stylesheet to use for the transformation (if you followed my instructions you wil find it attached to the page) The "normal" version performs all the tasks every time the page is viewed (with lot of http traffic to fetch the resources and cpu usage for the transformation). The "cached" version has an extra "timeout" parameter that specify the amount of seconds to consider the resource as valid. This function mantains an internal cache of the transformed resources and send them back to the client without perform the whole work every time. The resource is fetched again after it expires (with a great incement of speed and a better memory usage). NOTE: This whole package is released under Apache License. PS: Sorry for my english.. By Marco Casavecchia M. (marcolinuz(a)gmail.com)

4 6