December 2006 - xwiki-devs@xwiki.org

Attaching an image from another document?
by Vincent Massol 22 May '08

22 May '08

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

4 4

URLs
by Hans Gerwitz 20 Mar '07

20 Mar '07

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/

8 22

XWiki is one of the top project downloaded on ObjectWeb!
by Vincent Massol 31 Jan '07

31 Jan '07

This is cool: http://forge.objectweb.org/ (check the sidebar on the right). As you can see XWiki is in the top downloads for the past 7 days (it's in 5th position). 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

3 4

[vote] Missing searchDocumentsNames functionality
by Sergiu Dumitriu 05 Jan '07

05 Jan '07

com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames supports a selectColumns parameter which is supposed to specify which columns should be selected. This parameter is used when building the select string, but the columns are not included in the returned list, so this parameter just makes a bigger select string and increases the execution time. In order to include the specified columns in the result, I propose this: - if selectedColumns is the empty string, keep the previous behavior (return a list of document names) - if selectedColumns is not empty, then return a list of hashmaps, with the column name as the key, with a special name for the document name (for example docname)

4 5

XWiki 1.0 JIRA issues
by Vincent Massol 02 Jan '07

02 Jan '07

Hi, Reminder: We need everyone who are committing to implement issues for 1.0 B2 and RC1 to assign issues to themselves (or unassign themselves if they cannot do it). I'd like this to be finalized by today end of day. I'll then do a full pass to see what's left and send a summary email. It's probably there'll be lots of important issues not taken up so we'll have to do some shuffling. Make you select issues please choose with the following in mind: 1) no new features 2) as little as possible of improvements 3) bug fixes in priority 4) bug fixes raised in b1 in priority. There are several issues reported by users on the list which we need to transform into jira issues (the best is to ask users who are reporting them to do that in order to help) 5) Don't put any issues in 1.0. We should have issues only in B2 and RC1. We must leave 1.0 free for any bug found when RC1 is released. 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

2 5

W3C compliance
by Marc Lijour 01 Jan '07

01 Jan '07

xwiki.org home page is not valid html: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.xwiki.org

4 11

[Proposal] Create wikis/ module in SVN
by Vincent Massol 30 Dec '06

30 Dec '06

Hi, I'd like to propose creating a wikis/ module in wiki/wiki/trunk, as follows: xwiki/xwiki/trunk/ |_ wikis |_ default |_ xwikiorg |_ pom.xml The idea is to save both the default wiki and the xwiki.org wikis in SVN. Right now the default wiki is saved in xwiki/xwiki/trunk/standalone/import/... which I don't think is the right place. And the xwikiorg wiki is not saved at all. The rationale for having it in SVN is 1/ to have it linked and tagged along with the sources, 2/ to have it in the IDE when we refactor stuff (for example, it's easy to go a search and replace on some tokens), 3/ to get SVN diffs on modifications brought to xwiki.org so that all developers can see the changes and also to link the JIRA documentation issues to modifications on the wiki pages. In the "far" future, it would be cool to finish the SVN storage implementation so that we could configure the xwikiorg wiki to use xwiki/xwiki/trunk/wikis/xwikiorg as the storage location. For now, we should simply be careful to use the online wikis to make changes and from time to time (say once every week - I need to automate this) export data from there and save them in SVN in the locations defined above. Another detail: for xwikiorg we should not export the users as 1/ the passwords are saved in clear in the export (that's a bug to fix) and 2/ There's no point in saving all those users registering on xwiki.org. To summarize there are 2 proposals in one here: A) Create the xwiki/xwiki/trunk/wikis/default structure and move the default wiki there B) Add the xwikiorg wiki in there too. Please provide your feedback on these 2 proposals. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

5 10

XWiki 309 : Bold codification is not the same than in wiki editor mode
by phunghainam＠xwiki.com 30 Dec '06

30 Dec '06

Hi All ? We will use syntax for bold text is *text* or _text_ for both editor mode ? and how to config to show the toolbar in wiki editor (normal mode) . >> In wysiwyg mode, bold text is coded with *text*. in wiki mode, when using the >> small toolbar, it is coded with _text_. In some cases, switching from wysiwyg to >> wiki mode, some problems appear, but I can't reproduce them systematically. I >> suggest to have a same codification between both modes to avoid any problem.

4 7

[Proposal] New locations for skins in SVN and their delivery format
by Vincent Massol 30 Dec '06

30 Dec '06

Hi, As previously discussed, it would be nice to put skins in a specific location in SVN so that we can start delivering skins separately from the main distribution. I'm proposing to put the skins in: xwiki/xwiki/trunks/ |_ skins/ |_ <skin1>/ |_ <skinN>/ The web/* modules builds would still bundle one skin. Now the question I still have is how do we make the skins available to end users? We have 2 options: 1) We could provide them as zips. The users would then have to have access to the machine where the wiki is running and unzip them in the skins/ dir of the webapp. 2) Provide them as a single XML document (with all files attached to the skin document), as a XAR. I think option 2 is much better as it allows users to install the skin without requiring access to the machine. Note: Sergiu tells me that we need to check that attaching all the files to a skins document works as he had some issues with an old wiki. As a reminder Sergiu tells me that skin files are searched in 5 places: - XWikiSkins object property - skin doc attachment - skin directory - base skin - default skin It's a little bit more complex in term of build but it should still be doable. Here's how I envisage it: * have the skin files in the <skinN> directories as mentioned above * have the build use the XWiki Java API to do the following: - create a Document - add a XWikiSkins object to it - for each file in <skinN> attach it to the Document - export the Document in XML * have the build create a package file (XAR format) and create a XAR file Thus each <skinN> modules would produce a XAR file WDYT? 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

2 2

[vote] Skin naming convention
by Sergiu Dumitriu 29 Dec '06

29 Dec '06

The current trunk version has 4 skin directories: - 'default' is the skin used until this autumn, the classic XWiki skin, which can still be seen on old.xwiki.org - 'new' is (AFAIK) a failed experiment for implementing a new skin, mostly empty, unused - 'xwiki10' is the skin developed this summer/autumn by Marta, with the main goal of improving usability. It was deployed on the intranet, and was used as the starting point for a few sites. Also it is the starting point for the beta1 skin (if you take away the images and colors). Thus, we call it the XWiki10 alpha skin - 'xwiki10b1' is the current skin, deployed in the beta1. Problem: we're now working on the beta2. Should we make a new directory, xwiki10b2? This is bad practice. We will also have 1.0rc1 and 1.0 final, and then 1.1 and 2.0 (with beta-s and rc-s) and who knows what next. We'll soon have a dozed directories if we keep it like that. This is why we must decide on one skin naming convention which should work for an unlimited timespan. Options: 1. We continue in the same way as it is now, making lots of skin directories 2. Each major version will have it's own skin directory. Thus, we will have 'xwiki09', 'xwiki10', 'xwiki11', 'xwiki20', etc. 2a. 'default' points to the 0.9 version 2b. 'default' points to the latest stable skin 3. As 2, but each release duplicates the skin, like a svn tag, creating xwiki10b1, xwiki10b2, xwiki10rc1, etc. 4. We only have two skin directories, 'default' and 'wip' (work in progress). Once we release a new version, we copy the wip skin as the new default. Pros and cons, as I see them: 1+ We don't have to change anything, we continue as it is now 1+ Users kep the old skin intact, nothing gets broken for them 1- Anytime we make a new release, those willing to use the new skin have to change their settings to reference the new skin 1- We make tons of directories, thus ignoring one of the benefits of version control. 1- We increase the size of XWiki a lot (the current skin has more than 1Mbyte) 2+ We let users choose their favorite skin-flavor and stick with it 2+ We offer a few different skins to choose from 2a+ we keep a piece of backwards compatibility, meaning that sites based on the default skin will not be broken with each new release 2b+ we offer the best of XWiki with each new release. Sites using the default skin unmodified will instantly have a fresh new look, and those that want to keep the old one just have to change one option. 2b+ default means default, so it should always be the skin used by default 2- We have to override the current directories. xwiki10 (the alpha skin) will be replaced with the real 1.0 skin, and any site using the alpha will have to be fixed. This problem only occurs this time, since xwiki10 was used prematurely, and only in a few sites 3+ If a user prefers the beta2 skin over the final skin, he has a choice, without asking him to never update that directory or manually copy it into a 'mycustomskin' directory 3- In theory, the skin will be almost the same between the beta1 and final version, with only minor fixes and improvements. So, anyone wanting to stick to a temporary version must be crazy :) . Of course, this does not apply to the 1.0alpha skin. 3- Again, we discard versioning 3- Again, we make too many unnecessary directories which can be retrieved from the various branches/tags 4+ We make full use of version control, and we keep the xwiki package size to a minimum. Users always have the latest version of the skin, and we don't have to maintain too many skin directories up to date with important features/fixes. 4- We have to change too many existing directories 4- It is hard to fix bugs in existing skins, so we provide poor support for those who chose to use an older skin. A big + for keeping the number of directories to a minimum and overriding existing directories: XWiki users can always copy their skin to a new directory and use it as it is, ignoring 'default' or 'xwiki10', which are subject to change. Another big + for keeping the number of directories to a minimum: new features/fixes/improvements are usually implemented in only one skin, so at least you don't have to feel bad knowing that you probably should make the change in all the other skin directories A big + for keeping a skin directory for each major release: some features/fixes/improvements must be implemented in all skin versions, for the clients using an older version of the skin Implied changes: 1: None 2a: we copy 'default' into 'xwiki09' and rename 'xwiki10b1' into 'xwiki10', overriding the alpha skin 2b: 2a + we copy the new skin in the 'default' directory 3 'xwiki10' becomes 'xwiki10a', 'xwiki10b1' becomes 'xwiki10', 'xwiki10b1' is copied from the beta1 branch 4 'default' remains the same until 1.0 rc1, 'xwiki10b1' becomes 'wip', and all the other directories are removed. After rc1, we replace 'default' with the new skin I vote for 2b.

3 3