Hi,
Does anyone know why we have the following LANG property defined in
our startup scripts:
#!/bin/sh
export LANG=fr_FR.ISO8859-1
JETTY_HOME=.
JETTY_PORT=8080
JAVA_OPTS=-Xmx300m
java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT -
Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar
I think this is bad as it's french and I don't think we should set it
for the user.
That said, if it's there its probably because it was required in the
past, hence my question here.
To summarize: anyone sees any issue if I remove that "export LANG" line?
Thanks
-Vincent
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
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
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
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
Hi,
We need to organize a bit better the different JIRA projects. Right
now there are:
- XWiki
- XWiki Applications
- XWiki Clients
We need to clean the XWiki Applications and XWiki Clients projects.
For this we need to define a strategy for where to put xwiki plugins,
applications, etc.
Here are some facts:
* A JIRA project has the same versions for all components. This means
one JIRA project per release lifecycle.
And here's my proposal in term of JIRA projects:
* "XWiki":
- We put everything here that is tied to the XWiki Core release
(1.0 RC2, 1.1 B1, etc). Right now there are several plugins that are
still tied to the XWiki release (all the core plugins). So they
should go in there for now. When we'll move out the plugins later on,
we will then move their JIRA issues.
* "XWiki Applications":
- We remove this JIRA project
* "XWiki Default Wiki":
- We create this new JIRA project. Corresponds to xwiki-
applications/wikis/default.
- We move all issues from current XWiki JIRA project that have a
"Default Wiki" component to it.
- We define a version scheme for it. I propose to use the same
versions as for XWiki core for now. But in the future it'll be
possible to release the default wiki independently of XWiki Core.
- We create components for the various XWiki applications that we
haven't separated from the xwiki-applications/wikis/default yet (i.e.
all except the Panels which has been moved out)
* "XWiki Panels Application":
- We create this JIRA project. Corresponds to xwiki-applications/
xarlets/panels
- We define a version scheme for it. I propose to use the same
versions as for XWiki core for now. But in the future it'll be
possible to release the default wiki independently of XWiki Core.
- We release the panels application on the forge instead of just
releasing it as an attachment to http://www.xwiki.org/xwiki/bin/view/
Code/PanelsApplication. We'll continue to reference the download from
that page but it'll point to OW's forge. We ensure it's also
referenced from the main Download page on xwiki.org
* "XWiki Selenium Application":
- We create this JIRA project. Corresponds to xwiki-applications/
xarlets/selenium
- We define a version scheme for it. I propose to start at 0.1 as
it's still early stuff
- Release it as 0.1 on the forge and, as above, modify xwiki.org to
point to it (from the code zone).
* "XWiki <plugin name> Plugin":
- Where <plugin name> is: "Adwords", "Alexa", "Email Notification",
"IP Resolver", "Laszlo", "Task Manager", "Terraserver"
- The strategy is that once a plugin is moved out of the core to
the xwiki-plugins/ dir, we create a JIRA project for it
- We define a version scheme for them. I propose to start at 0.1 as
we haven't released them yet. We shouldn't release any of them until
we've tested it works with the latest version of XWiki Core.
* "XWiki Clients":
- We remove this JIRA project and move all current clients to the
sandbox. Namely they are: "foxwiki", "anyedit", "p2pxwiki", "wiked"
Others:
* I'm not entirely sure what to do with these projects in xwiki-
tools: build tools, package and cryptpasswords.
* I think they're too small and not well-defined enough to warrant a
JIRA project each. I'm proposing to create a Tools component in the
main XWiki JIRA project for now to see how they develop in the future.
WDYT?
If you're ok I'm proposing to do the reorganization work.
Thanks
-Vincent
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
Hi,
We thought RC3 would be the last RC before the final release. However
we have discovered regressions in the WYSIWYG module :(
Thus I'd like to propose a RC4 release as soon as the problem listed
below are fixed.
Here are some issues that I think need to be fixed ASAP for a RC4
release (please add more if you think they are critical for a 1.0
release):
- XWIKI-1152 Wysiwyg loosing content when copy pasting and switching
to list
- XWIKI-1151 Wyswiyg editor has problem with lists and carriage returns
I think we need to all do a thorough review of the WYSIWYG editor to
try to find any other big issues that would need to be fixed before
the 1.0 release. Minor issues will have to wait for 1.1B1 or later.
Proposal:
- RC4 release for Wednesday
- 1.0 final postponed to the 9th of May
Is that ok with everyone?
Thanks everyone
-Vincent
PS: It should be clear by now that we need to spend more time on
functional testing...
Hi,
I don't understand how to create plugin with my own tags in xwiki.
I would like to create some tags - something like {table} .... {table},
but I don't know how to render xwiki text with plugin.
Can anybody help me?
In fact is it even possible to write this plugin with
XWikiDefaultPlugin/XWikiPluginInterface?
It would be great if somebody be able to publish plugin which implementing
new tags
or write me the instruction what I have to do.
Thank you.
--
View this message in context: http://www.nabble.com/How-to-create-own-tags-in-xwiki--tf3504145.html#a9786…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hello,
I made a simple example using XWiki XML/RPC API, and I'm facing
something bizarre.
The example is located at:
http://www.xwiki.org/xwiki/bin/view/UserGuide/XMLRPCExample
It's a work in progress; is it OK to put it on www.xwiki.org user guide?
The idea is to make it a reusable example of XML/RCP API use.
The archive contains the source code, an Ant build file to compile and
run the example, an Eclipse project.
I do the following:
1- I run 'ant login': result is ok
2- I run 'ant create': result is ok, seen from the XML/RPC client side
3- I visit Sandbox.WebHome using firefox: Test page appears in Sandbox
space pages, but as a link to a non existing page; clicking on the link
brings to editing an empty page
4- I run 'ant get': the page is received ok, with same content as when
created (i.e. "This content was created by XMLRPC")
5- I visit Sandbox.WebHome using firefox: same as before. Clearing the
cache, quitting firefox does not change anything
6- I run 'ant edit': the page is edited ok
7- I run 'ant get': the content is correct w.r.t. previous editing
8- I visit Sandbox.WebHome with firefox: idem as before (page
Sandbox.Test is non existant)
9- I restart Tomcat
10- I visit Sandbox.WebHome with firefox: page is there
11- I visit Sandbox.Test with firefox: content is correct
Looks like a cache problem, but where?
The source code of the example may seem unnecessarily complicated (use
of properties, separation in several classes), but the idea is to move
it to Ant task easily.
Any idea?
François
