xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

XWiki 1.0 skin and Panels need to be separated

by Vincent Massol

Hi, I think we need to cleanly separate the 1.0 skin from the Panels application. I think they shouldn't be linked and it should be possible for a user to upgrade to the XWiki 1.0 skin without requiring to install the Panels application (http://www.xwiki.org/xwiki/bin/view/Code/PanelsApplication). Conversely, it would be nice if the Panels application could be used with some other skin. Any idea on how to achieve this? How easy would it be? 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

17 years, 10 months

XWiki 1.0 JIRA issues

by Vincent Massol

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

17 years, 10 months

[xwiki dev] 1.0 Beta 1 & XWiki Classes issues

by Dan Murphy

Hi Chaps, I'm having problems using the XWiki Class support and could do with some help... Firstly it's worth mentioning that I'm building my own XWiki from the XWIKI_1_0_BETA_1 tag in svn - but I don't think this is a problem :) When I try to edit a class, the URL is incorrect : <http://localhost:8080/xwiki/bin/edit/XWiki/TestClass?editor=class> http://localhost:8080/xwiki/bin/admin/XWiki/TestClass?editor=class Where as I think it should be : http://localhost:8080/xwiki/bin/edit/XWiki/TestClass?editor=class This looks like jira http://jira.xwiki.org/jira/browse/XWIKI-624 & I've added a comment to it about the URLs. I can get around this problem and sucesfully get create my desired class, sheet & template. However, when I create a new document with the class it doesn't seem to be adding an instance of my class automatically. Things are OK when I add the object, but I need the instance to be added automatically. Any clues / pointers on how to debug this and figure out what's wrong ? I'm running on Kubuntu 6.0.6, MySQL 5.0.21, WAS CE 1.1 & a 1.5 JDK Many thanks in advance, Dan

17 years, 10 months

[vote] Should emphasizing radeox filters ignore spaces?

by Sergiu Dumitriu

Hello, Should the following work, too? A * bold * word In my opinion, for the filter to work, the bold markers should not be separated by spaces from the text, like: A *bold* word This reduces the misinterpretations of the filter (two bolds on the same row, http://jira.xwiki.org/jira/browse/XWIKI-333 ), eliminates the confusion between bold and lists: * is this bold, * or is it a list with an asterisk? The same for italics and underline. The radeox filter rules can be easily changed, but the wysiwyg editor must put the filter markers not exactly at the selection start/end, but at the nearest character.

17 years, 10 months

W3C compliance

by Marc Lijour

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

17 years, 10 months

[Proposal] Create wikis/ module in SVN

by Vincent Massol

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

17 years, 10 months

XWiki 309 : Bold codification is not the same than in wiki editor mode

by phunghainam＠xwiki.com

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.

17 years, 10 months

[Proposal] New locations for skins in SVN and their delivery format

by Vincent Massol

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

17 years, 10 months

[vote] Skin naming convention

by Sergiu Dumitriu

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.

17 years, 10 months

[Important] Definition of Committers and their roles and responsibilities

by Vincent Massol

Hi all XWiki developers, I have created a page on http://www.xwiki.org/xwiki/bin/view/Community/Committership explaining what we call a Committer and their roles and responsibilities. Please all take the time to read this page and to provide any comment you have. If nobody objects these will be the new roles and responsibilities to follow for Committers in 72 hours! :-) Once we've agreed on what is a Committer, I'll then review the svn logs and see who's been participating to XWiki for the past year and elect those who have been active participants to this new status of Committer. Those who have been committing in the further past (more than 1 year ago) will be elected as Emeritus Committers. Thanks -Vincent, self-declaimed benevolent despot ;-) ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 10 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