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

[xwiki-devs] [Proposal] Continuing work on xwiki-url
by Vincent Massol 08 Jun '09

08 Jun '09

Hi, I've progressed a bit over the weekend on our xwiki-url module. I've created a patch at http://jira.xwiki.org/jira/secure/attachment/15161/XWIKI-3951.txt Quickly the idea is to: * Make XWikiURL an interface * Add XWikiDocumentURL, XWikiAttachmentURL, etc for the various URL types * Examples of various XWiki URL types: document, attachment, skin, template, resource * Generify XWikiURLFactory * Introduce XWikiURLSerializer (for ex to generate standard URLs) Let me know what you think. I'd like to commit what I have already before progressing further. Thanks -Vincent

2 1

[xwiki-devs] Help need in Javascriptextention
by Chathura Prabuddha 07 Jun '09

07 Jun '09

Hai... I tried to use the xwiki.javascrpitextention object to separate my javascript code.But it didn't work correctly.I included the whole javascript code in (Document Type Manager Demo) http://gsoc.myxwiki.org/xwiki/bin/view/DocTypeManagerDemo to here: http://gsoc.myxwiki.org/xwiki/bin/edit/DocTypeManagerDemo/DocTypeManagerScr… and then tried the $xwiki.jsx.use("DocTypeManagerDemo.DocTypeManagerScript"). you can see it in here (I commented it) http://gsoc.myxwiki.org/xwiki/bin/edit/DocTypeManagerDemo/WebHome?&editor=w…<http://gsoc.myxwiki.org/xwiki/bin/view/DocTypeManagerDemo> please give me some hints to fix this issue... :). Thank you. ~ Chathura Prabuddha Ganegoda~

3 2

[xwiki-devs] XWiki Blog + Ecto3
by Andreas Schaefer 07 Jun '09

07 Jun '09

Hi Now that XWiki is up and running I can now pay attention to the little details that I would love to have. Top on my list for the Blog is to be able to create and manage entries through Ecto3. Now Ecto3 does not support XWiki or XWiki Blog and even using the Blogger type does not work even though I could connect to the server. Confluence does support Ecto (at least the Ecto2 verison) through the Blogger RPC API type. There are two ways to fix it. First a XWiki connection plugin could be created for Ecto but I would thing there are other blogging clients that would love to get access to XWiki. Another way would be to support other types of RCP APIs like Blogger (because that is what Confluence support(ed)). I don't know if that is sufficient for the entire Wiki but I think it should do the trick for the Blog. What do you think? Thanks Andreas Schaefer CEO of Madplanet.com Inc. Email: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter; andy_mpc AIM: schaefera(a)me.com

2 1

[xwiki-devs] Blog RSS Feed Problems with 1.8.3
by Andreas Schaefer 07 Jun '09

07 Jun '09

Hi I have a blog up and running with XWiki (http://madplanet.com/blog) but I have problems to create an RSS feed for it. I tried to use the snippet on: http://code.xwiki.org/xwiki/bin/view/Applications/BlogApplication but that does not work. The resulting XML is empty (only the XML header is there). Using the Blog Category Panel gives me links to the the Category Feeds but these feeds all point to the category 'Personal' no matter what category I put into. Could that be an issue with an outdate document (from 1.8 or so) ? How would I create a RSS Feed for the entire blog (all categories) and more specific is there a way to make the RSS feed symbol come up (on the Main.Blog site) in the address bar (blue-white RSS symbol on the right hand side) ? Thanks Andreas Schaefer CEO of Madplanet.com Inc. Email: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter; andy_mpc AIM: schaefera(a)me.com

4 14

Re: [xwiki-devs] [VOTE] HTML and Velocity macro NL/WS behaviors (TAKE 2)
by Vincent Massol 06 Jun '09

06 Jun '09

Hi, We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose: * Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now) This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted). WDYT? Here's my +1 Thanks -Vincent PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this. On Thu, Apr 16, 2009 at 3:56 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > We need to come to a conclusion for handling New Lines(NL) and white spaces > (WS) in HTML and Velocity Macro. > If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current > problem is that we cannot indent scripts since WS and NL are meaningful. > I'd like to reiterate the proposal that was sent but not enough people voted > on it (only Thomas did). > A) For the HTML macro, we propose to make the following changes: > - strip NL/WS between elements (elements that don't accept CDATA) > - strip leading/trailing NL/WS for element content before passing them to > the wiki syntax parser > B) for the Velocity macro we have 2 choices I can think of: > 1) strip all leading spaces for all lines (but keep NL) > Note that this means that inside a velocity macro you wouldn't be able to > have a line break with the new line starting with spaces without escaping > the leading space with ~(space). > Note also that this means we will not be able to add extra new lines to > format the text nicely (since that would add new paragraphs) or split a > single line into several lines for extra readability. This is the case today > with the old syntax and it's a pain not to be able to aerate the text with > empty lines. > Ex: > some text > ~ next line #if (...) this goes on the same line #something(...) #end > This is a new paragraph > In this example notice that we need the velocity #if to be on the same line > since NL are significant. > 2) strip all leading spaces for all lines + remove all NL too. > This means we need to ensure we still have one space remaining between > "words" (same as HTML). > The user would use something like $nl and $sp to explicitely enter new lines > and spaces. > The advantage is that you control completely the formatting (no magic > anymore) at the cost of a little extra work (adding the $nl where > required). > Basically this means the same pros/cons as when you work with HTML where you > need to explicitly add <br/> when you want new lines. > Ex: > some text $nl > $sp next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > $nl $nl > This a new paragraph > Note: I've aerated the text by putting extra new lines around the velocity > #if to show that it would work. > 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line > breaks with "\\". > The exact algorithm is: if there's 1 NL remove it, if there's more than 1 > leave them. > Ex: > some text\\ > ~ next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > This a new paragraph > I'm +1 for A) > For B) I think the most flexible is 2) but I'm wondering if it's too big a > change for our users or not. If not 2) then 3). > Thanks > -Vincent >

5 9

Re: [xwiki-devs] [xwiki-notifications] r20881 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model org.xwiki.eclipse.core/src/main/java/org/xwiki/ecl
by Venkatesh Nandakumar 06 Jun '09

06 Jun '09

Hi Sergiu, Are you sure it's supposed to be OBJECT_SUMMARY_FILE_EXTENSION? Also see > the comment for the next file. > I was unsure then if I should go ahead with Attachment Caching, hence that was not the correct code. Florin and Fabio have both said not to look into that (LocalXWikiDatastorage) as of now. Why do you store both objects and attachments with the same code? > Shouldn't you create two lists instead? Why is that wrong? Both Attachments and Objects are shown in the tree as children of Pages. They are differentiated by the user with the help of icons (ImageDescriptor). I thought that was good enough. Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

1 0

[xwiki-devs] Attachment Caching in XEclipse.
by Venkatesh Nandakumar 06 Jun '09

06 Jun '09

Hi, For the rest, I'll wait for your first contribution as soon as it's ready. > I have committed the attachment-display code, as I told you yesterday itself. Please do have a look at it. Should Attachments be cached (LocalXWikiDataStorage)? Or should it be done depending on size(I don't think xmlrpc function exists to check size)? In my opinion, Attachments should not be cached. I had initially thought of using LocalXWikiDataStorage, and then ran into some problems (At isLocallyAvailable() of DataManager class) because Attachment Class is defined by Confluence, and hence is not that flexible according to our requirements. Secondly, Caching a 2-5MB, say, attachment is not feasible. Is there any way around? What should I do when the user wants to "Open" the attachment from the Navigator? Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

2 1

Re: [xwiki-devs] [xwiki-notifications] r20911 - enterprise/trunk/wiki/src/main/resources/XWiki
by Vincent Massol 06 Jun '09

06 Jun '09

On Jun 6, 2009, at 3:05 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-06-06 03:05:33 +0200 (Sat, 06 Jun 2009) > New Revision: 20911 > > Modified: > enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > Log: > [cleanup] Minor code improvements. > > Modified: enterprise/trunk/wiki/src/main/resources/XWiki/ > WebSearchCode.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > 2009-06-06 00:53:45 UTC (rev 20910) > +++ enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > 2009-06-06 01:05:33 UTC (rev 20911) > @@ -38,21 +38,20 @@ > #set($text = $text.replaceAll("'", "''").replaceAll("%", "\\%")) > #set($nbitems = 50) > ## ----------------------------------------------------------- > - ## Non-admins should not see results from XWiki, Admin and > - ## Panels spaces. Also exclude the WebPreferences doc. > - ## ----------------------------------------------------------- > - #if ($xwiki.hasAdminRights()) > - #set ($excludedWebs = '') > - #else > - #set ($excludedWebs = "doc.space<>'XWiki' and > doc.space<>'Admin' and doc.space<>'Panels' and > doc.name<>'WebPreferences' and") > - #end > - ## ----------------------------------------------------------- > ## Display only a given space if $request.space is defined > ## ----------------------------------------------------------- > #if("$!space" == '') > - #set ($webClause = $excludedWebs) > + ## ----------------------------------------------------------- > + ## Non-admins should not see results from XWiki, Admin and > + ## Panels spaces. Also exclude the WebPreferences doc. > + ## ----------------------------------------------------------- > + #if ($xwiki.hasAdminRights()) > + #set ($webClause = '') > + #else > + #set ($webClause = "doc.space<>'XWiki' and > doc.space<>'Admin' and doc.space<>'Panels' and > doc.name<>'WebPreferences' and") Actually this should use $blacklistedSpaces for excluding spaces. > > + #end > #else > - #set ($webClause = "doc.space='$space' and $excludedWebs") > + #set ($webClause = "doc.space='$space' and") > #end > #macro(addelement $item $list) > #if($xwiki.hasAccessLevel('view', $context.user, "$ > {context.database}:${item}")) Thanks -Vincent

1 0

[xwiki-devs] Fwd: [ANN] Maven Assembly Plugin 2.2-beta-4 released
by Vincent Massol 05 Jun '09

05 Jun '09

Begin forwarded message: > From: John Casey <jdcasey(a)commonjava.org> > Date: June 5, 2009 10:35:04 PM CEDT > To: Maven Users List <users(a)maven.apache.org>, announce(a)maven.apache.org > Subject: [ANN] Maven Assembly Plugin 2.2-beta-4 released > Reply-To: "Maven Users List" <users(a)maven.apache.org> > > The Maven team is pleased to announce the release of the Maven > Assembly > Plugin, version 2.2-beta-4. > > This plugin is useful in creating project artifacts that custom > layouts. > It also includes a set of predefined standard custom artifact types > you > can choose to create. For more information, see: > > http://maven.apache.org/plugins/maven-assembly-plugin/ > > You should specify the version in your project's plugin configuration: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-assembly-plugin</artifactId> > <version>2.2-beta-4</version> > </plugin> > > > Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 > > > ** Bug > * [MASSEMBLY-238] - Assembly plugin removes file permissions this is useful for us. We can remove some todos from our pom files. -Vincent > * [MASSEMBLY-379] - Follow-up: file permissions are removed when > creating tar.gz assembly > * [MASSEMBLY-413] - Assembly plugin uses absolute paths from > project instance after interpolation > * [MASSEMBLY-414] - Allow regular expressions in include/exclude > patterns for filesets > * [MASSEMBLY-416] - outputDirectory default value in fileSet seems > changed; now seems to use directory name of fileSet sourcedir > * [MASSEMBLY-417] - regex in/exclusion patterns can fail on Windows > due to file-separator replacement. > * [MASSEMBLY-418] - Broken link to assembly-1.1.0-SNAPSHOT.xsd > * [MASSEMBLY-419] - All module directories are included with > complete system path > > ** Improvement > * [MASSEMBLY-421] - Maven repository layout like directory > structure using dependencySet > > > Enjoy, > > -The Maven team > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe(a)maven.apache.org > For additional commands, e-mail: users-help(a)maven.apache.org >

1 0

Re: [xwiki-devs] [xwiki-notifications] r20881 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage org.xwiki.eclipse.ui org.xwiki.eclipse.ui/icons org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/actions org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters
by Sergiu Dumitriu 05 Jun '09

05 Jun '09

vnkatesh (SVN) wrote: > Author: vnkatesh > Date: 2009-06-05 18:43:32 +0200 (Fri, 05 Jun 2009) > New Revision: 20881 > > Added: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/icons/xwiki.attachment.png > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/actions/XWikiEclipseAttachmentSummaryActionProvider.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipseAttachmentSummaryAdapter.java > Modified: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/DataManager.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/RemoteXWikiDataStorage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/plugin.xml > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/UIConstants.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/AdapterFactory.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java > Log: > Basic Attachment Display. > No Functionality (Open/Properties) > Unsure of LocalDataStorageFunctionalities as of yet. > > Added: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java (rev 0) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java 2009-06-05 16:43:32 UTC (rev 20881) This is definitely not right: > + String url = "http://192.168.121.161:5005/xwiki/xmlrpc/confluence"; > + String user = "vnkatesh"; > + String pass = "ranjith"; > Added: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java (rev 0) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java 2009-06-05 16:43:32 UTC (rev 20881) > @@ -0,0 +1,47 @@ You should add the standard copyright notice header at the start of each new file. > +/** > + * > + */ > +package org.xwiki.eclipse.core.model; > + (non-Javadoc) comments are not useful. Either remove them or add a proper Javadoc. For @Override methods it's enough to turn the plain comment into a javadoc and replace the (non-Javadoc) line with {@inheritDoc}. > + /* > + * (non-Javadoc) > + * @see org.xwiki.eclipse.core.model.ModelObject#getXWikiEclipseId() > + */ > + @Override > Modified: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java 2009-06-05 16:37:12 UTC (rev 20880) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java 2009-06-05 16:43:32 UTC (rev 20881) > + public List<Attachment> getAttachments(String pageId) throws XWikiEclipseException > + { > + List<Attachment> result = new ArrayList<Attachment>(); > + > + XWikiPage page = getPage(pageId); > + if (page == null) { > + return result; > + } > + > + IFolder pageFolder = baseFolder.getFolder(INDEX_DIRECTORY).getFolder(page.getSpace()).getFolder(pageId); > + if (pageFolder.exists()) { > + try { > + List<IResource> pageFolderResources = getChildResources(pageFolder, IResource.DEPTH_ONE); > + for (IResource pageFolderResource : pageFolderResources) { > + if (pageFolderResource instanceof IFile) { > + IFile file = (IFile) pageFolderResource; Are you sure it's supposed to be OBJECT_SUMMARY_FILE_EXTENSION? Also see the comment for the next file. > + if (file.getFileExtension().equals(OBJECT_SUMMARY_FILE_EXTENSION)) { > + Map<String, Object> map = (Map<String, Object>) CoreUtils.readDataFromXML(file); > + Attachment attachment = new Attachment(map); > + result.add(attachment); > + } > Modified: sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java 2009-06-05 16:37:12 UTC (rev 20880) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java 2009-06-05 16:43:32 UTC (rev 20881) > @@ -32,7 +32,6 @@ Why do you store both objects and attachments with the same code? Shouldn't you create two lists instead? > try { > - List<XWikiEclipseObjectSummary> result = > - pageSummary.getDataManager().getObjects(pageSummary.getData().getId()); > + List result = pageSummary.getDataManager().getObjects(pageSummary.getData().getId()); > + result.addAll(pageSummary.getDataManager().getAttachments(pageSummary.getData().getId())); -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0