xwiki-devs March 2007

xwiki-devs@xwiki.org

36 participants
65 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, 5 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, 3 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, 4 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, 4 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, 6 months

[ArchitectureV2] UI Interfaces

by Vincent Massol

Hi, I'd like to propose the following general principles for the V2 Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2): 1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package). <example - I'm not asking to vote on this, it's just an example to better visualize what "one Java Interface for each UI contribution" means> For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example: public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); } where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere. The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example. </example> 4) There are Java UI Interfaces for skins. These are interfaces used by skins. <example> Continuing the example above we could have the following: public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); } And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc. </example> <example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example> WDYT? After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2 Thanks -Vincent

17 years, 7 months

xredirect on a confirm delete action

by Arnaud Thimel

Hi all, I tried to use the xredirect functionnality on a confirm delete action I would like the URL : /xwiki/bin/delete/Plans/aaaa?confirm=1&xredirect=/xwiki/bin/view/Plans/bbbb to delete the doc aaaa and then redirect to the doc bbbb If I remove the confirmation (confirm=1) my redirect is OK but, as I don't confirm deletion, my doc aaaa is still here. I patched my own version of XWiki because I need it, but I would like to know if this is volunteer (and so why ?) or if I should submit my patch. Thanks -- Arnaud Thimel Société Code Lutin - http://www.codelutin.com

17 years, 7 months

Right approach for filtering

by Zeljko Trogrlic

Hi, For our department Wiki, I really needed automatic links for acronyms because we have a whole bunch for them. So, after couple of days playing with code and regular expressions I managed to create Radeox filter, which converts acronyms to links. My questions are: 1) Is that the right approach to do that or I should write plug-in? Can you write a plug-in that processes every page, or you have to call it explicitly? 2) What is the right place to attach it to rendering? I attached it to the end, just before link filter, but then I had to struggle with HTML. It will be probably easier to write something that processes pure Wiki or abstract syntax tree, but it seems to me that there is no such place in Wiki. If I do the processing immediately after page is loaded, macros are not evaluated yet, therefore text generated by macros can't be processed (I don't know is this a big deal, though). It seems to me that macros are generating HTML instead of Wiki, which is not very clean. On the other hand it will be hard to write event simple macros with formatted text (e.g. "warning") without generating HTML directly, or introducing some kind of style tags for Wiki markup. 3) Radeox status: What is your experienece with Radeox team? Is there anybody still working on the project? I found some some funny stuff in the source code, which I would like to fix. They "swallowed" exceptions in some places, so if you mis-configure filter, you will not why it doesn't work.

17 years, 7 months

XWiki and SVN as a backend

by Hamish Cunningham

Hi, I'm investigating what it would take to store (or duplicate) some of the data in XWiki's database in Subversion. Rationale: - A plain text version of wiki pages stored in SVN buys you: - off-line edit, merge, etc - access to the pages using other tools, editors and so on - replication options - versionning, branching etc, and version display via e.g. ViewCVS - insulation from database crashes, with easier incremental backup - a kind of poor-man's content management system - SVN is very robust, reliable, and has a mature Java interface (SVNKit) - if Tomcat crashes a static version of the site can still be served - I have a large static site that is managed in SVN (8 Gb in 40,000 files) which I want to migrate to a more dynamic system. This looks like a significant size job, but we have a fair amount of resources in my team, and possibly we might fund some of the work in the XWiki community if anyone is interested. I wonder if this type of idea has been discussed before, and if anyone has comments on the best way to go about the problem? It seems to me that trying to replace the database entirely with a file-based store is too much work and would lead to performance problems, but perhaps it would be possible to have a process which pushed changes from the database into an SVN working copy and vice versa? Where would be good places to start looking at the code from this point of view? I also need to include a JavaCC-based wiki-to-html parser that we have as an option, but I'm betting that's an easier task? Thanks, best, Hamish -- Prof. Hamish Cunningham Department of Computer Science University of Sheffield Regent Court 211 Portobello St. Sheffield S1 4DP United Kingdom http://www.dcs.shef.ac.uk/~hamish/

17 years, 7 months

Re: [xwiki-commits] r2503 - in xwiki/trunk/web/standard/src/main/webapp/skins: albatross dodo finch

by Vincent Massol

On Mar 25, 2007, at 10:22 AM, Marta Girdea wrote: > Author: marta_girdea > Date: 2007-03-25 10:22:52 +0200 (Sun, 25 Mar 2007) > New Revision: 2503 > > Modified: > xwiki/trunk/web/standard/src/main/webapp/skins/albatross/ > contentview.vm > xwiki/trunk/web/standard/src/main/webapp/skins/dodo/view.vm > xwiki/trunk/web/standard/src/main/webapp/skins/finch/contentview.vm > Log: > XWIKI-1006: Add new #footnote macro > Automatic call of #putFootnotes at the end of the page What is this new feature of footnotes at the bottom of pages in our skins? I think that ideally this new feature should have warranted a JIRA issue so that it could have appeared in the release notes and users know to expect this new feature (which some may have been awaiting for). Note that this is different than creating a new footnote macro. Am I missing something? :) Thanks -Vincent

17 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2007