xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Thoughts about the ID assigned to documents, etc.

by Erin Schnabel

Now, I've sent about 4 of these to the dev list, and they'll probably all show up at once in a week. *sigh* I am a big proponent of the principles of this bug: http://jira.xwiki.org/jira/browse/XWIKI-1021 I don't think the whole ID scheme currently used should be thrown out, however, as it might break anyone with an existing XWiki installation of any size (which I have). I would like to see the following: a) go ahead and use a hash of the name to find an initial ID b) increment the number if necessary to ensure it's unique. c) stay with that ID, period. Don't change it when something is renamed, etc. I've been seeing some issues with renames where the name hash collides, or all of the attachments associated with an ID aren't updated correctly (so the attachments effectively "disappear"..) There is no reason to keep the ID associated with a hash of the name, as the initial lookup is almost always based on the document's name... I think this is pretty important, especially with document renaming now possible. I was talking to Vincent about this, and I'll see if I can find a patch. This also seems to line up with a Google Summer of Code item: http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Storage+Improvements Erin -- Waste of a good apple. --Samwise Gamgee

17 years, 4 months

[help] XWiki-Eclipse-Plugin

by tharindu jayasuriya

Hi All! We have been implementing the editing part of the above plug-in and came across a little problem. Basically the editor (inside eclipse work-bench) consists of two tabs; one for editing the XWiki markup and the other for viewing the results. The XWiki markup editor tab is quite ok ( may be we can worry about some syntax highlighting later on), this is shown in edit_view.png ( see attachment ). But the problem is with rendered out put. output_view_1.png shows the output from a browser widget (using the URL of the page being edited). Here the problem is that navigation panel is repeated, one in XWiki Navigator (Plug-in component) and the other one in the browser itself (a.k.a in web page). output_view_2.png shows the output rendered with the renderContent() (refer to Confluence XML RPC API<http://confluence.atlassian.com/display/DOC/Remote+API+Specification>) method. Here the problem is that we only get a basic html output which is ugly. Ideally we should have the browser output (output_view_1.png) without the navigation panel. We're currently stuck here unable to make a decision or find an alternative method. So, any help would be really appreciated. Thanks - Tharindu & Asiri PS : We have formatted the code into standards but still working on the Maven2 build l, will finish it soon.

17 years, 4 months

Thoughts about the ID assigned to documents, etc.

by Erin Schnabel

I am a big proponent of the principles of this bug: http://jira.xwiki.org/jira/browse/XWIKI-1021 I don't think the whole ID scheme currently used should be thrown out, however, as it might break anyone with an existing XWiki installation of any size (which I have). I would like to see the following: a) go ahead and use a hash of the name to find an initial ID b) increment the number if necessary to ensure it's unique. c) stay with that ID, period. Don't change it when something is renamed, etc. I've been seeing some issues with renames where the name hash collides, or all of the attachments associated with an ID aren't updated correctly (so the attachments effectively "disappear"..) There is no reason to keep the ID associated with a hash of the name, as the initial lookup is almost always based on the document's name... I think this is pretty important, especially with document renaming now possible. I was talking to Vincent about this, and I'll see if I can find a patch. This also seems to line up with a Google Summer of Code item: http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Storage+Improvements Erin -- 'Waste of a good apple' -Samwise Gamgee

17 years, 4 months

[RFC] minor edit feature

by Artem Melentyev

Hi. I work on minor edit feature (http://en.wikipedia.org/wiki/Minor_edit): http://jira.xwiki.org/jira/browse/XWIKI-1447 (patches attached) I would like to hear your opinions about it. Here is my solution: The major change is document versioning: major document edits(default) increase 1st version number (1.2->2.1) minor document edits(selected by checkbox) increase 2nd version number (2.1->2.2) New checkbox "Minor edit" will be added to document edit form Minor changes will be hidden in history UI by default (Show only latest minor versions before major version. ex: 1.2, 2.1, 3.3) It will be stored as normal changes with special mark (doc.isMinorEdit) Adding objects,attachments,comments,rights to document is minor changes. Implementation is like XWIKI-114 1. Is it OK, to change document versioning? Or how to mark minor changes otherwise? 2. How edit and history UI would be? (you may see My UI in patches, attached to jira issue or at http://212.193.74.172/xwiki/bin/view/Main/WebHome ) -- Artem Melentyev

17 years, 4 months

Is the Maven2 build for Curriki ok?

by Vincent Massol

Hi Curriki developers, I haven't worked on Curriki so I'm not the best person placed to verify if the new Maven2 build works fine. Could someone check that all is fine? Thanks -Vincent

17 years, 4 months

XEM releases?

by Vincent Massol

Hi, JIRA says XEM 1.0M1 should be released on 14th of June and 1.0M2 on 29th of June. Obviously JIRA is lying! :) JV, you're the Release Manager for XEM. Could you please let us know the new dates and update JIRA accordingly? (or remove any date if we don't know...) Thanks -Vincent

17 years, 4 months

Questions about the ID assigned to documents, etc.

by Erin Schnabel

17 years, 4 months

[ANN] XWiki Top level POM and XWiki Platforms tools released

by Vincent Massol

Hi, Just to inform you that I have released the following packages: - XWiki Top Level POM in version 1 - XWiki Platform Tools in version 1.0 All using Maven2 (a first for XWiki ;)). They are available in our new release repo at http://maven.xwiki.org/releases/ Thanks -Vincent

17 years, 4 months

Adding stuff to Maven build to create a plugin

by Radu Danciu

I've been told that the Google Docs functionality should be built as a plugin, yet there is no documentation about building plugins for xwiki. I need to start adding code to the build to test it, but I need to know how I should go about it. Also, what was the decision regarding the migration to JDK 1.5? I need to add some libs to the build that require it. The libs are provided by google as source that is supposed to be built, and then the jars imported, which I'm told Maven can handle... how? I'd like it if somebody could take the time guide me through the process. Thanks, Radu

17 years, 4 months

Re: Build XWiki Platform Tools::Maven2 #16 failing

by Vincent Massol

Sorry about all these failures. This is the first time we're doing releases and the first run is always a bit chaotic. I'll get better. Anyway, I have everything under control now and all should be fixed and working by now ;) Thanks -Vincent On Jul 5, 2007, at 2:40 PM, teamcity(a)xwiki.org wrote: > Build XWiki Platform Tools::Maven2 #16 failing > Agent: Default agent > Build results: http://teamcity.xwiki.org/viewLog.html? > buildId=481&buildTypeId=bt4 > > Changes included (1 change) > ==================================================== > Change 3824 by vmassol (1 file): > Prepare for the XWiki Tools 1.0 release > > see more information about changed files: http://teamcity.xwiki.org/ > viewLog.html?tab=buildChangesDiv&buildId=481&buildTypeId=bt4 > > > ====================================================================== > ====== > Configure email notifications: http://teamcity.xwiki.org/ > profile.html?init=1#notifications

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