xwiki-devs February 2007

xwiki-devs@xwiki.org

29 participants
70 discussions

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, 7 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, 4 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, 5 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, 5 months

URLs

by Hans Gerwitz

How can I turn off the "shortcut" URLs where /bin/Space/Page is interpreted as /bin/view/Space/Page? (Specifically, I'm using mod_redirect to clean up the URL architecture and need to assume that anything prefixed /bin that isn't /bin/view needs to be passed through as an action.) - - - Hans Gerwitz http://phobia.com/

17 years, 9 months

[xwiki-dev] create a personal rss feed

by EMPTOZ Mathieu 310507

Hello again, I have developed a method that allows creating a personal rss feed for the wiki. The user can chose to follow (and un-follow) a page by clicking on a link in the page. Users can follow the pages they want. Answers me if you're interested in seeing my method in order to ameliorate it. @+ --------------------------------------------------- Mathieu Emptoz CEA Cadarache DRFC/STEP XWiki's EFDA Remote Participation Administrator ---------------------------------------------------

17 years, 9 months

tiny_mce and the integration into xwiki

by Christian Gmeiner

Hi all. At the moment I am looking into problems exists with xwikis wysiwyg editor. For instance, it is not possible to save the result of image operations in the wiki page. I have created an jira - http://jira.xwiki.org/jira/browse/XWIKI-906 - to update tiny_mce to most recent version. But know I need more informations, where, how, ... tiny_mce is integrated in xwiki. Where can i find the setup of tiny_mce... I hope somebody can help me, Christian

17 years, 9 months

Re: [xwiki-commits] r2279 - in xwiki/trunk: . core/src/main/java/com/xpn/xwiki core/src/main/java/com/xpn/xwiki/content core/src/main/java/com/xpn/xwiki/content/parsers core/src/main/java/com/xpn/xwiki/render core/src/main/java/com/xpn/xwiki/web lib web/standard/src/main/webapp/WEB-INF

by Vincent Massol

Sorry about the ContentParserException which was committed by error... I'm leaving it as I need it for a future commit of tomorrow... Thanks -Vincent On Mar 1, 2007, at 12:50 AM, Vincent Massol wrote: > Author: vmassol > Date: 2007-03-01 00:50:18 +0100 (Thu, 01 Mar 2007) > New Revision: 2279 > > Added: > xwiki/trunk/core/src/main/java/com/xpn/xwiki/content/ > xwiki/trunk/core/src/main/java/com/xpn/xwiki/content/parsers/ > xwiki/trunk/core/src/main/java/com/xpn/xwiki/content/parsers/ > ContentParserException.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/web/ > InitializationServletContextListener.java > xwiki/trunk/lib/velocity-tools-1.3.jar > Removed: > xwiki/trunk/lib/velocity-tools-1.1.jar > xwiki/trunk/web/standard/src/main/webapp/WEB-INF/toolbox.xml > Modified: > xwiki/trunk/build.xml > xwiki/trunk/core/src/main/java/com/xpn/xwiki/render/ > XWikiVelocityRenderer.java > xwiki/trunk/web/standard/src/main/webapp/WEB-INF/web.xml > Log: > XWIKI-923: Upgrade to Velocity Tools 1.3 > > - Upgraded to newest version > - Removed unused Velocity View Servlet and unused toolbox.xml > config file > - Added XWiki Initialization strategy and initialized Velocity there

17 years, 9 months

Google Summer of Code Project Proposals

by Ludovic Dubost

Hi, We need to start a quick discussion to propose Google Summer of Code projects for students. We will apply on March 5th to be part of the Google Summer of Code and we need a few things by then: 1/ A list of project proposals (with some cool and fun projects) 2/ A list of volunteer mentors (a mentor will have to follow at least one student during the summer) Any ideas welcome on this. Ludovic -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

17 years, 9 months

[VOTE] Change package names from com.xpn.xwiki to org.xwiki

by Vincent Massol

Hi everyone, I think it would be better for the XWiki project to use a org.xwiki package. There are several reasons for this: - fits better as XWiki is under OSS/LGPL - the company name can change, it's less likely the product name will change - I believe if we want to make that change we should do it before the 1.0 release, as it's quite an important change and would break some advanced usages of XWiki (like plugin creators, extension creators in general). I think users should be safe though for the vast majority, unless they're doing funky stuff in their pages. Here's my +1 Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2007