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
Hello.
I have a strange bug then building xwiki-enterprise-database by maven2
indirectly (by pom <modules>):
$ cd xwiki-product-enterprise
$ mvn clean; mvn install
result:
database files in xwiki-product-enterprise/target/database but not in
xwiki-product-enterprise/database/target/database
so xwiki-enterprise-database-1.1-SNAPSHOT-hsqldb.zip is empty
(if I directly building database (`cd xwiki-product-enterprise/database;
mvn install;`) - all is fine)
environment:
maven-2.1-SNAPSHOT(29 june)
sun-jdk-1.6
xwiki trank (29 june), unchanged
gentoo linux
all configs looks normally
I looked all configs, looked at mvn -X and found nothing strange.
I created simple m2 project like xwiki-product-enterprise but with only
the database as m2 module - the same error.
Why it can be?
--
Artem Melentyev
Hello all,
What is $msg variable, and where can I read more about it? (is not in xwikivars.vm...) And how does $msg.get() works?
Please, I really need some help. I want to include support for languages in my datepicker and Sergiu told me to put the strings in ApplicationRessources.properties and now I'm trying to get them in a js file with $msg.get("core.datepicker.somethingdefinedbymehere"), but it seems that the server does not know how $msg is, but it knows who $xwiki, $context and all other are....
So please, please, I would like to know more about this variable or how to get the strings from ApplicatonRessources.
I'd really appreciate some help because I'm stuck on this....
Thank you very much,
Evelina
Hi Stephane,
Maybe a quick word of what this is so that others know? Maybe a
README dropped in there would be good too.
Thanks
-Vincent
On Jun 22, 2007, at 4:05 PM, St??phane Lauri??re wrote:
> Author: slauriere
> Date: 2007-06-22 16:05:06 +0200 (Fri, 22 Jun 2007)
> New Revision: 3720
>
> Added:
> xwiki-sandbox/org.xwiki.model/
> Log:
> Initial import.
Hi All
I am new to XWiki and want to set it up on my local workstation (using
MySQL as the DB) , then modify the code and re-build it. I have the copy
of the code taken from the following SVN
URL:(**svn://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk**)
.Please suggest the methods for the following:
1. Ant targets for building XWiki (in all the modes)
2. deploy targets for XWiki
3. Changes in the code for MySQL other than the db properties in the
hibernate config (if any).
4. any other suggestions/precautions
Thanks
Gaurav
Hi,
I think we need an easy way for everyone to build only the product
he's working on. Thus I'd like to propose the creation of a new
svn:externals for the platform only and to move externals in a
specific dir:
/svnroot/xwiki
|_ externals/
|_ trunks-devs/
|_ trunks-users/
|_ trunks-platform-devs/
|_ trunks-platform-users/
This will achieve the following use cases:
Use case 1: I'm working on product XX and I'm not making any change
to the platform
- checkout just the product's trunk. For example /svnroot/xwiki/xwiki-
products/xwiki-watch/trunk
Use case 2: I'm working on both the platform and XWiki Enterprise but
not the other products
- checkout /svnroot/xwiki/externals/trunks-platform-devs/
- checkout XWiki Enterprise: /svnroot/xwiki/xwiki-products/xwiki-
enterprise/trunk
Caveat: you can't build both at the same time but you can build each
one with a single command.
Use case 3: I'm working on everything
- checkout /svnroot/xwiki/externals/trunks-devs/
Another option would be to create one externals per product but it's
a little bit of a pain to maintain. It's possible though. Actually
this would allow to fine tune the build to that only platform
components required for the product are built. For example, only the
plugin used by the product and only the applications built by the
product would be built. Actually this probably makes sense. In that
case we would have:
/svnroot/xwiki
|_ externals/
|_ trunks-devs/
|_ trunks-users/
|_ trunks-platform-devs/
|_ trunks-platform-users/
|_ trunks-enterprise-devs/
|_ trunks-enterprise-users/
|_ trunks-enterprise-manager-devs/
|_ trunks-enterprise-manager-users/
|_ trunks-watch-devs/
|_ trunks-watch-users/
|_ trunks-curriki-devs/
|_ trunks-curriki-users/
A last option would be to put the full platform under the same trunk/
but I don't think this is right as we should be able to release
platform modules separately.
WDYT?
Thanks
-Vincent
