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
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.
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
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
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
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
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...
--
'Waste of a good apple' -Samwise Gamgee
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
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
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
