xwiki-devs July 2008

xwiki-devs@xwiki.org

54 participants
180 discussions

[xwiki-devs] XWiki - Browser full URL in xwiki page

by Prathap Pandian

Hi, How can i print the current browser full URL in xwiki page. I tired this one $doc.getURL("view"), but it displaying the url from the application name like this */xwiki/bin/view/Main/ *Is there any other way to print the whole browser URL in xwiki page like this* http://<server>:<port>/xwiki/bin/view/Main/ *-- Prathap* *

16 years, 2 months

[xwiki-devs] [GOSC] WebDav status

by Ludovic Dubost

Hi Asiri, When do you plan to deliver your milestone status ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 2 months

[xwiki-devs] [GSOC][WEBDAV] Comments & Exposed properties

by Asiri Rathnayake

Hi Ludovic & All, Two small questions, 1. According to my understanding, current design of xwiki-webdav interface<http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService>does not take document comments into account (shouldn't they be exposed via webdav ?). 2. Which xwiki specific properties are to be exposed through this interface (out of author, revision , etc. etc.) ? Thanks a lot. - Asiri

16 years, 2 months

[xwiki-devs] [GSOC] [WEBDAV] MKCOL Where should it be allowed ?

by Asiri Rathnayake

Hi devs, current xwiki-webdav interface is exposed as follows, root | + - library | + - orphans | + - attachments | + - home | + - spaces My questions is, where should MKCOL (create collection) operation be allowed ? I believe it only makes sense in `spaces` view where we can allow the user to create a space (if he has appropriate access levels). Also, another doubt i have is about creating pages, should it be same as with collections where we manually add the wiki.txt and wiki.xml files into the collection once it is created ? Thanks a lot. - Asiri

16 years, 2 months

[xwiki-devs] [GSOC] help choosing a js lybrary/wrapper

by Miguel Bento

First of all, hi again! I'm developing the collaborative business drawing framework to integrate on XWiki and currently need some feedback. In order to provide the abillity of drawing SVG/VML/Canvas objects in the browser, this framework has many options that i shall explain: * A) Tatami, the GWT wrapper of the Dojo Toolkit library ( http://code.google.com/p/tatami/)* This is by far the most used option, and the reasons are somewhat obvious. - It wraps up the dojo toolkit code for GWT providing access to the GFX package's functionalities and thus giving us the possibility to draw objects in SVG/VML/Canvas. This is a very important point as it provides support for Safari with canvas objects and IE with VML objects, accomplishing thus a better product. - Provides the creation of basic and advanced drawing figures from squares to paths with drag and drop, scale, rotate and parameters specification. - It has the biggest active developer's base, having a lot of activity on their forum (http://groups.google.com/group/tatami) - It gives us efficiency and usability by being well developed. Personally, this is a key point for me as i've seen a lot of svg drawing boards slow and badly done. A demo of the tatami can be found here ( http://tatami.googlecode.com/svn/trunk/site/samples/TatamiDemo/index.html ) but don't mind the slow reaction of the site as it's using aloot of dojo objects(Fisheye, etc) and it's runing from the svn. After some coding with it, i realized it can indeed be very fast. IMHO, this looks like the winner.. we should use this wrapper for the job and if necessary develop some new items on it to provide us the required functionalities, which will also be needed in any other option. *B) JSGraphic's library ( http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm) *As it's the case with Dojo Toolkit, this library can be used in GWT by including a wrapper on the project. The downsides of this alternative are obvious as, for example, it doesn't support's drag and drop or any interaction with the objects and is a one man project. It's allways good to have options heh! *C) Develop an API fit to the job* As this option might bring some (? small) benefits in efficiency and additional funcionalities, on the other hand, it's slowed by the time required to develop the API knowing that there are some fully functional good options out there. Talking about functionalities, Tatami provides every svg object and property that i remind me of and it's efficiency and usability are high, so there shouldn't be much more to do in this area. (besides implementating screw transformations, which aren't included in the latest realease of Tatami :) In the next days i'll be building a propotype of a drawing API so please give me your opinions. My vote : +1 Tatami Best Regards, Miguel Bento.

16 years, 2 months

[xwiki-devs] [GSOC] Collaborative Drawing content

by Miguel Bento

As some of you know, the collaborative drawing application will use svg( http://www.w3.org/Graphics/SVG) syntax in order to draw the various objects and therefore we have to found a way to store and edit this information. Currently we have two implementation options to perform this task, the Object approach and the Attachment approach, and are trying to decide which one is the better, so, in order to perform that i've prepared a few mockups. To clarify the intent of these approachs, it's good to keep in mind that a drawing has various edition modes and privileges.More specifically, we should have 3 user modes: - Administrator: In administrator mode the drawing content will be presented by the SVG editor and the user can: - Edit the drawing - Add or remove users - Modify the drawing name and description - Editor: In the editor mode the drawing content will also be presented by the SVG editor but the user can only edit the drawing content. - Viewer: In the viewer mode the drawing will be presented as .png file using the Batik plugin and therefore the user only has rights to view the drawing. The object approach: In this perspective, the SVG content would be saved on a SVG object with the following properties: http://dl.getdropbox.com/u/47956/XWiki_SVG_Object_Description.pdf , this SVG object would be available in the page, could be accessed by the getContent() method and edited with a simple saveContent() call. In order to store the privileges and the creation date the current page should be used and to show that here's example: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/XWikipa…) Here's a example of the view mode: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) And finally here's a edition mode example: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) The attachment approach: In this approach, the SVG content will be stored on a attachment and so all the edition operations would be saved on it as new versions. It's identical to the object approach except in the fact that the svg content wouldn't be in the page itself(we still would need a reference to the attachment on it). When a user want's to go to edition mode, in this approach a full-screen editor will be launched like the next one: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) and all the document properties would have to be stored on the attachment. Note: Obviously the full screen mode can be used in both approaches and the examples shown are possible desings for the UI which in the future will be discussed. (Refer to http://dev.xwiki.org/xwiki/bin/view/Design/CollaborativeDrawingfor a better version) So, WDYT? Best Regards, Miguel Bento

16 years, 2 months

[xwiki-devs] XWiki - Dynamic Space Name In The Links

by Prathap Pandian

Hi, I tried to display the space name dynamically in the links. Example: In the new panel i have give like this [Home>*Main.WebHome*] Basically all the spaces will have WebHome page by default. So i tried to change the space name dynamically. And here what i have given in the panel... [Home>*$doc.space.WebHome*] But it seems not working for me. And it provided me the following *url*http:// <server>:<port>/xwiki/bin/edit/%24doc.space/WebHome?parent=Main.WebHome&editor=wysiwyg Is there any other way to do this...? *OR* I did it wrong...? -- Prathap

16 years, 2 months

[xwiki-devs] [GSOC][WEBDAV] DAVExplorer on Linux

by Asiri Rathnayake

Hi All, I'm having a small issue with DAVExplorer on fedora 6 where i cannot put the password (for login) into password box because it doesn't accept keyboard input. I know this is something wrong with fedora (or the jdk i'm using) because it works fine on XP. This is not a big issue for me because i can simply disable authentication related code in the webdav servlet and carry on my development but i thought it is best to make a note (in case someone knows how to fix it). Up untill now i have been using nautilus's built-in webdav support for testing but for advaced functionality i need DAVExplorer. Anyway, as i said, this is not a big issue (but surely it is a big annoyance), if anyone knows how to fix it, feel free to advice :) Thanks. - Asiri

16 years, 2 months

[xwiki-devs] Mirror offer

by Squirrel

Hi guys, I'm just downloading the 1.5M2 release to test your new administration GUI. The speed is currently 30KB/s.... I've a 100Mbit/s dedicated server located in Germany (Hoster: Hetzner). I can spend, let's say 100GB/month at full speed, would that help? Cheers, Squirrel PS: Will you sometime publish some statistics on this topic?

16 years, 2 months

[xwiki-devs] How I fix another encoding problem and my experience on encoding for non-English language

by LiDan

I met another encoding problem. In firefox, I edited a page by wysiwyg editor, when I saved the page, all the links with Chinese name are ill formated(the href part).So you can not get the right page by click a link. But in IE, there is no such problem. So I checked the wysiwyg editor to find where the hrefs begin ill-formated. Finally I found the file wiki_editor/plugins/core.js After line 173, I add a new line. href = this.trimString(att["href"]); href=decodeURI(href);//added by lidan, decode URI Then tested again, it's OK, the problem's gone. I didn't go deeply why only in firefox there is such problem. I don't know if others have met the same problem. If you do, you can try this way, it may help. I have been implementing my own wiki based on xwiki for about several months. Normally, xwiki is a very good product. But when I'm trying to implemented it in my language, Chinese, I met many encoding problems. Fortunatelly I can get help from this forum, and many of the problems has been fixed. In my experience, there are several factors will affect the encoding, the operation system, web server, web server configuration, xwiki configuration, your web-browser. But it seems that you can not find a general way to fix all the problems. Sometimes you should deal with them one by one. -- View this message in context: http://www.nabble.com/How-I-fix-another-encoding-problem-and-my-experience-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 2 months

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