xwiki-devs April 2008

xwiki-devs@xwiki.org

55 participants
180 discussions

Re: [xwiki-devs] FW: Request for iCal4j API

by ancapaula.luca＠xwiki.com

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 >

16 years, 8 months

[xwiki-devs] FW: Request for iCal4j API

by Evelina Slatineanu

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

16 years, 8 months

[xwiki-devs] Request for iCal4j API

by Evelina Slatineanu

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

16 years, 8 months

[xwiki-devs] XWiki CRUD

by Ludovic Dubost

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

16 years, 8 months

[xwiki-devs] A New Comer.

by Asiri Rathnayake

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

16 years, 8 months

[xwiki-devs] [ANN] XWiki Watch Milestone 4 Released

by ancapaula.luca＠xwiki.com

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

16 years, 8 months

[xwiki-devs] XSL Plugin

by Marco Casavecchia Morganti

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)

16 years, 8 months

[xwiki-devs] [ANN] XWiki Workspaces Milestone 2 Released

by Jerome Velociter

The XWiki development team is pleased to announce the release of XWiki Workspaces Milestone 2, Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This second milestone brings bug fixes, improvements as well as new features. You can find out more reading the full releases notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces10M2, including installation and upgrade instructions. Thanks, -The XWiki dev team

16 years, 8 months

[xwiki-devs] URL encoding problem

by LiDan

I tried Xwiki standalone version 1.2 and 1.3, I met same problem. I created a new link named in Chinese Characters in a page which name was also in Chinese Character. And when I clicked the link to edit the new page, the parent link could not display correctly in the new page. When I went back to the last page and check the URL of the link, I found that the URL was like this: /xwiki/bin/edit/Main/%E6%B5%8B%E8%AF%951?parent=Main.测试&editor=wysiwyg, The main part of the URL is like %E6%B5%8B%E8%AF%951 but the value of the parent parameter is in the original Chinese Character , why there are two different encodings in one URL? And what confused me more is that this only happened in IE. In firefox, the whole URL was in original Chinese Character I also find that when I use export function, spaces and pages which named in Chinese Character can not display crorrect name. Could anyone tell me how to resolve these encoding problems, thank you very much. -- View this message in context: http://www.nabble.com/URL-encoding-problem-tp16494345p16494345.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 8 months

[xwiki-devs] Uploading Multiple Files at once ?

by Kamna Jain

Hello, Is it possible to upload multiple files (like an unzipped folder) in XWiki ? I have come across the ZipExplorerPlugin - but I understand this is for navigating through files in a zipped folder that is uploaded as an attachment. Is that right? Also, when I searched xwiki.org for "uploading multiple files" I came across a Files Application for Xwiki Workspaces. Does that have any relevance here? Thanks

16 years, 8 months

← Newer
1
...
11
12
13
14
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2008