xwiki-devs April 2007

xwiki-devs@xwiki.org

40 participants
80 discussions

LANG property in startup script in standalone version

by Vincent Massol

Hi, Does anyone know why we have the following LANG property defined in our startup scripts: #!/bin/sh export LANG=fr_FR.ISO8859-1 JETTY_HOME=. JETTY_PORT=8080 JAVA_OPTS=-Xmx300m java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT - Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar I think this is bad as it's french and I don't think we should set it for the user. That said, if it's there its probably because it was required in the past, hence my question here. To summarize: anyone sees any issue if I remove that "export LANG" line? Thanks -Vincent

16 years, 8 months

Attaching an image from another document?

by Vincent Massol

Hi, I'd like to attach an image to the current document but the image is attached to another document. I couldn't find the answer in the FAQ. It would be great if the {image:} radeox macro allowed for this. Right now the only solution I'v found (which is a bit ugly) is to use an HTML <img> tag as in: <img src="/xwiki/bin/download/XWiki/Toolbar/image.gif" /> Any other solution I would have missed? Thanks -Vincent ___________________________________________________________________________ D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions ! Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses http://fr.answers.yahoo.com

16 years, 10 months

[Proposal] Document history storage

by Sergiu Dumitriu

Hi, Sometime ago, there was a discussion regarding how should the document history be stored in a better way. Right now, the complete history is stored as one field in the xwikidoc table. From my PoV, this has some major disadvantages: - loading an older version requires parsing all the history -> memory inefficiency - as the documents grow older, loading a document will take a lot of time -> time inefficiency - queries on archives cannot return just one version, but they match the whole document (somewhere in the history, there was a version containing "search term") The blocking issue with storing old version in a different table was, at that time, the fact that a document archive should contain all information needed for completely restoring the document, like content, metadata, objects. I don't think that is actually an issue. We are archiving document versions, but we're joining all versions in one large string. Why don't we archive the complete version, but one version per row? So, the archive table should look like: - document name - version number - language (for translations) - content - archived metadata (one field, or the same fields as in xwikidoc) - archived objects (one field) - attachment names and versions It is not like storing the version as a normal document is, with separate objects and properties, but at least it provides a better storage and retrieval mechanism, and it separates a bit the parts of a wikidocument - content, metadata, objects. WDYT? -- http://purl.org/net/sergiu

17 years, 8 months

XWikiMessageTool refactoring

by Sergiu Dumitriu

Hi, I looked today over the XWikiMessageTool class, and I must say that I'm not quite satisfied with it. First, there was XWIKI-919, which I implemented. OK, I understand that files stored on disk should be charset independent, so only ASCII characters are supported by the ResourceBundle class (jvm) .But, when I can edit a wiki document for storing bundles, I expect it to accept all the characters the wiki supports (in my case, it was an UTF8 instance). I had some troubles fixing this, since the JavaDoc says that bundles accepts only ASCII characters, but it understands and parses unicode references ( \u0123 ). Maybe I did something wrong, but doing content.replaceAll("\u0139", "\\u0139") resulted in the string u0139 being displayed in the page. So I had to trick it into believing that the component bytes of the encoding are ASCII characters and manually restore the multibyte chars. Second, I don't like the fact that XWIKI-921 was not already implemented. Third, I don't like the cache refresh mechanism. It retrieves the XWikiProperties->documentBundles property for each request, and It retrieves the bundle documents for every request and checks if it must be refreshed or not. Why isn't the com.xpn.xwiki.notify package used? It allows registering callback handlers for specific document changes. How I see it: - at startup, register a handler for XWiki.XWikiPreferences (so that we know when the documentBundles property might change). - remember the list of document bundles, don't ask it for each request - also register handlers for the current bundle documents and load the strings from these documents - when XWikiPreferences is changed, if the documentBundle property is also changed, remove the unused bundles and build the new ones - when a undle document (or a translation for it) is changed, rebuild the bundle for that document This should speedup the code a bit, it makes use of a nice, but mostly unknown feature, it doesn't log an error for each request when a specified document is not found in the wiki, and it doesn't require so many variables (previousDates, docsToRefresh). Fourth, as I said above, if a document is specified in the documentBundles property, but it does not exist in the wiki, for each $msg.get call an error is logged. And there are a lot of calls for each request. Now, in my opinion this is a nice way to get in the core of XWiki for a newcomer, so does anybody want to write the changes I mentioned? Also, this is a good occasion to document the event notification mechanism, in JavaDoc and on www.xwiki.org Regards, Sergiu Dumitriu -- http://purl.org/net/sergiu

17 years, 8 months

[Proposal] Some/All fields in the database should be longer

by Sergiu Dumitriu

There are many properties stored in VARCHAR(255) fields, which sometimes isn't enough. This already causes http://jira.xwiki.org/jira/browse/XWIKI-883 . Changing to variable length field doesn't have any major side effects, as I know. As pro arguments: 1. The size of the database will not increase 2. There are already some fields stored as mediumtext and longblob, so it's not something new in the database 3. The fewer limits there are, the better 4. Issues like XWIKI-883 will be fixed ... and maybe more Is there something I'm missing that prevents this? -- http://purl.org/net/sergiu

17 years, 8 months

[Proposal] Reorganizing JIRA projects

by Vincent Massol

Hi, We need to organize a bit better the different JIRA projects. Right now there are: - XWiki - XWiki Applications - XWiki Clients We need to clean the XWiki Applications and XWiki Clients projects. For this we need to define a strategy for where to put xwiki plugins, applications, etc. Here are some facts: * A JIRA project has the same versions for all components. This means one JIRA project per release lifecycle. And here's my proposal in term of JIRA projects: * "XWiki": - We put everything here that is tied to the XWiki Core release (1.0 RC2, 1.1 B1, etc). Right now there are several plugins that are still tied to the XWiki release (all the core plugins). So they should go in there for now. When we'll move out the plugins later on, we will then move their JIRA issues. * "XWiki Applications": - We remove this JIRA project * "XWiki Default Wiki": - We create this new JIRA project. Corresponds to xwiki- applications/wikis/default. - We move all issues from current XWiki JIRA project that have a "Default Wiki" component to it. - We define a version scheme for it. I propose to use the same versions as for XWiki core for now. But in the future it'll be possible to release the default wiki independently of XWiki Core. - We create components for the various XWiki applications that we haven't separated from the xwiki-applications/wikis/default yet (i.e. all except the Panels which has been moved out) * "XWiki Panels Application": - We create this JIRA project. Corresponds to xwiki-applications/ xarlets/panels - We define a version scheme for it. I propose to use the same versions as for XWiki core for now. But in the future it'll be possible to release the default wiki independently of XWiki Core. - We release the panels application on the forge instead of just releasing it as an attachment to http://www.xwiki.org/xwiki/bin/view/ Code/PanelsApplication. We'll continue to reference the download from that page but it'll point to OW's forge. We ensure it's also referenced from the main Download page on xwiki.org * "XWiki Selenium Application": - We create this JIRA project. Corresponds to xwiki-applications/ xarlets/selenium - We define a version scheme for it. I propose to start at 0.1 as it's still early stuff - Release it as 0.1 on the forge and, as above, modify xwiki.org to point to it (from the code zone). * "XWiki <plugin name> Plugin": - Where <plugin name> is: "Adwords", "Alexa", "Email Notification", "IP Resolver", "Laszlo", "Task Manager", "Terraserver" - The strategy is that once a plugin is moved out of the core to the xwiki-plugins/ dir, we create a JIRA project for it - We define a version scheme for them. I propose to start at 0.1 as we haven't released them yet. We shouldn't release any of them until we've tested it works with the latest version of XWiki Core. * "XWiki Clients": - We remove this JIRA project and move all current clients to the sandbox. Namely they are: "foxwiki", "anyedit", "p2pxwiki", "wiked" Others: * I'm not entirely sure what to do with these projects in xwiki- tools: build tools, package and cryptpasswords. * I think they're too small and not well-defined enough to warrant a JIRA project each. I'm proposing to create a Tools component in the main XWiki JIRA project for now to see how they develop in the future. WDYT? If you're ok I'm proposing to do the reorganization work. Thanks -Vincent

17 years, 10 months

[Proposal] OpenID support in XWiki

by Artem Melentyev

Hi. I would like to propose the project: OpenID[1] support in XWiki. OpenID is an open, decentralized, free framework for user-centric digital identity. [1] 1) XWiki as openid consumer. Possibility to login into xwiki with openid. Value: major 2) XWiki as openid provider. Some users of xwiki will have openid account like username.xwiki.host or xwiki.host/openid/username For example users in xwiki.com will have openid = username.xwiki.com Value: minor User story: I have account and virtual wiki at username.xwiki.com. I wish to login with openid into xwiki.org. Standard authentication process with openid[3]: I enter to openid login form at xwiki.org my openid=username.xwiki.com, click sumbit. xwiki.org redirects me to openid authentication page in username.xwiki.com. I enter my password, click submit. username.xwiki.com redirects me back to xwiki.org. Done. I logined into xwiki.org with openid. If I already logined to username.xwiki.com, xwiki.org will not redirects me to username.xwiki.com, and I don't enter password. I may use my openid=username.xwiki.com as normal openid. For example I may write comments to livejournal.com with openid[2]. Advantages: The User needs only one login for all xwikis and openid services. User's openid will be point at homepage on xwiki (possibly). Increase popularity of xwiki project: There are not much openid providers for now. [4] XWiki users will promote xwiki their openids (*.xwiki.com) There are also bounty($5000) for openid-enabled opensource projects: http://iwantmyopenid.org/bounty There are other authorization protocols, similar to the technology openid: http://lid.netmesh.org/ http://en.wikipedia.org/wiki/Inames (inames mostly paid) http://yadis.org/ But it is not too common. Technical details: Possible openid implementations: http://code.google.com/p/openid4java/ or http://code.google.com/p/joid/ Consumer: Then user logins with openid first time, xwiki create special user like XWiki.openid_<user's openid> for a user settings storage. Provider: java servlet. WDYT? Is this project suitable for GSoC 2007? Estimated workload: 1-2 man/month References: [1] http://openid.net/ [2] http://www.livejournal.com/openid/ [3] http://openid.net/about.bml [4] http://openid.net/wiki/index.php/Public_OpenID_providers -- Artem Melentyev, UralSU, CS401

17 years, 10 months

WYSIWYG issues for 1.0 and RC4 release

by Vincent Massol

Hi, We thought RC3 would be the last RC before the final release. However we have discovered regressions in the WYSIWYG module :( Thus I'd like to propose a RC4 release as soon as the problem listed below are fixed. Here are some issues that I think need to be fixed ASAP for a RC4 release (please add more if you think they are critical for a 1.0 release): - XWIKI-1152 Wysiwyg loosing content when copy pasting and switching to list - XWIKI-1151 Wyswiyg editor has problem with lists and carriage returns I think we need to all do a thorough review of the WYSIWYG editor to try to find any other big issues that would need to be fixed before the 1.0 release. Minor issues will have to wait for 1.1B1 or later. Proposal: - RC4 release for Wednesday - 1.0 final postponed to the 9th of May Is that ok with everyone? Thanks everyone -Vincent PS: It should be clear by now that we need to spend more time on functional testing...

17 years, 10 months

How to create own tags in xwiki?

by kinslayer

Hi, I don't understand how to create plugin with my own tags in xwiki. I would like to create some tags - something like {table} .... {table}, but I don't know how to render xwiki text with plugin. Can anybody help me? In fact is it even possible to write this plugin with XWikiDefaultPlugin/XWikiPluginInterface? It would be great if somebody be able to publish plugin which implementing new tags or write me the instruction what I have to do. Thank you. -- View this message in context: http://www.nabble.com/How-to-create-own-tags-in-xwiki--tf3504145.html#a9786… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 10 months

XML/RPC oddities

by François Déchelle

Hello, I made a simple example using XWiki XML/RPC API, and I'm facing something bizarre. The example is located at: http://www.xwiki.org/xwiki/bin/view/UserGuide/XMLRPCExample It's a work in progress; is it OK to put it on www.xwiki.org user guide? The idea is to make it a reusable example of XML/RCP API use. The archive contains the source code, an Ant build file to compile and run the example, an Eclipse project. I do the following: 1- I run 'ant login': result is ok 2- I run 'ant create': result is ok, seen from the XML/RPC client side 3- I visit Sandbox.WebHome using firefox: Test page appears in Sandbox space pages, but as a link to a non existing page; clicking on the link brings to editing an empty page 4- I run 'ant get': the page is received ok, with same content as when created (i.e. "This content was created by XMLRPC") 5- I visit Sandbox.WebHome using firefox: same as before. Clearing the cache, quitting firefox does not change anything 6- I run 'ant edit': the page is edited ok 7- I run 'ant get': the content is correct w.r.t. previous editing 8- I visit Sandbox.WebHome with firefox: idem as before (page Sandbox.Test is non existant) 9- I restart Tomcat 10- I visit Sandbox.WebHome with firefox: page is there 11- I visit Sandbox.Test with firefox: content is correct Looks like a cache problem, but where? The source code of the example may seem unnecessarily complicated (use of properties, separation in several classes), but the idea is to move it to Ant task easily. Any idea? François

17 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2007