2.1.1 of course :)
JV.
On Mon, Dec 21, 2009 at 3:23 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
> Hi,
>
> I'd like to release XE and XEM 2.1.1 tomorrow. 4 important bugs have
> been fixed since 2.1:
>
> - XWIKI-4575 : Horizontal ruler breaks the display of the WYSIWYG
> menu bar and toolbox
> - XWIKI-4681 : Attachments deletion has no effect before a restart
> - XWIKI-4679 : Can't select the macro after inserting it (WYSIWYG)
> - XWIKI-4688 : Macro disappears after editing its properties (WYSIWYG)
>
> Here's my +1.
>
> Thanks,
> JV.
>
Hi,
I'd like to release XE and XEM 2.1.1 tomorrow. 4 important bugs have
been fixed since 2.1:
- XWIKI-4575 : Horizontal ruler breaks the display of the WYSIWYG
menu bar and toolbox
- XWIKI-4681 : Attachments deletion has no effect before a restart
- XWIKI-4679 : Can't select the macro after inserting it (WYSIWYG)
- XWIKI-4688 : Macro disappears after editing its properties (WYSIWYG)
Here's my +1.
Thanks,
JV.
Hi devs,
I'm still working on the Model Reference domain. We've brainstormed
with Thomas and we'd like to propose replacing the current
ModelContext.getCurrentDocumentName() by
ModelContext.getCurrentEntityReference() (which returns an
EntityReference).
The idea is that a URL could target a document but also a wiki only
(e.g the REST API odes that), or a given space only, or even an object
or a property. This would mean we would need to have
getCurrentDocumentReference() in addition to all the others:
getCurrentWikiReference(), getCurrentSpaceReference(). It would also
mean a lot of them would be set to null. Last it would mean different
ways to access the same information (e.g.
getCurrentDocumentReference.getWikiReference() vs
getCurrentWikiReference()).
We would also add a EntityReference.extractReference(EntityType type)
method in order to make it easy to extract information from the a
reference path.
For example to extract the Wiki from an entity reference:
WikiReference wikiRef =
context.getCurrentEntityReference(EntityType.WIKI);
if (wikiRef != null) ....
WDYT?
Thanks
-Vincent
Hi devs,
Currently the getDocument method always goes to the storage to retrieve
the document, even if the same document has just been retrieved. This
means that the following code will not work:
#set($d = $xwiki.getDocument('X'))
$d.setTitle('the title')
$xwiki.getDocument('X').getTitle() # will not print 'the title'
I'd like to change getDocument so that it first searches in a map of
used documents in the current context. This means the following:
- getDocument searches in XWikiContext.usedDocuments (or better, in the
ExecutionContext)
- if found, return the value from there
- if not, go to the storage, return it to the caller
- when the document is changed for the first time, i.e. when
api.Document.getDoc() is called, clone the original document and put it
in usedDocuments
- as a special case, PreviewAction also puts the updated context
document in usedDocuments
This means that consecutive calls for retrieving a (changed) document
will always return the same object. This prevents possible preview bugs,
like http://jira.xwiki.org/jira/browse/XABLOG-14 or
http://jira.xwiki.org/jira/browse/XWIKI-4689
Yet this is an important behavior change. Do you think anybody is using
this "feature", and actually expects the above code example to work as
it does now?
Also, we must be careful with the performance, since this new map could
get big, holding all the documents in the database. Perhaps a LRU
fixed-size map would be better, although this breaks the uniqueness
guarantee.
So, WDYT?
1. Should we introduce this cache?
2. Should it be limited in size?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi:
I'm updating from 2.1M1 to 2.1 Final release, and encountered an
error. Please someone help me out. Many thanks.
I did the following things.
1. Export everything from 2.1M1 to backup.xar
2. Import backup.xar to 2.1Final
3. Import official XE XAR, effectively overwrite the things in
backup.xar, with the exception of XWiki.XWikiPreference and
***.WebPreference.
4. So far so fine. But after restarting the server, I encounter the
following error:
HTTP ERROR 500
Problem accessing /xwiki/bin/view/Main/. Reason:
Error number 3 in 0: Could not initialize main XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager
from param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Could not create a DBCP pool. There is an error in
the hibernate configuration file, please review it.
--
-- Zhaolin Feng
-- www.mapbar.com
-- Currahee! We stand alone together!
On 12/18/2009 01:36 PM, Reto Hotz wrote:
> Hi,
>
> FYI: We have experienced problems running XWiki 2.1 on Glassfish 2.1.1
> (see stacktrace at the end).
> Our final solution was to replace the bundled cglib-2.1_3.jar with the
> newest cglib-2.2.jar
So the solution is to also update it in the default distribution, right?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hello Devs,
Currently xwiki-officeimporter contains logic for mainly two different
tasks:
1. Manage the back-end openoffice process (and provide document conversion
facilities).
2. Perform the actual transformation from office documents to wiki pages.
(depends on point 1)
xwiki-officeimporter module's code might appear a bit complex because of
this mix up. Also I believe openoffice related code might have to be reused
once we introduce an office-exporter module.
I was wondering if it would be beneficial (in the long run) to extract out
openoffice related code into a separate module (xwiki-openoffice). The main
concern I have is that currently openoffice related code is inside
org.xwiki.officeimporter.openoffice package which have to be changed to
org.xwiki.openoffice if we are to extract out a xwiki-openoffice module,
this could break a few things in public API.
Even if we decide to do so, I don't think any of us (devs) would be able to
do this within 2.2M1 time period. But I thought it's better to discuss about
it a little now.
Let me know what you think.
Thanks.
- Asiri
Hi All,
I would really like to be able to mimic one to many relations through
classes somehow?
I noticed there have been a few posts about how one might go about such a
thing using dblists, it's not clear yet to me how I could implement such a
thing? I'm wondering if any demo application exist that might give me more
of a clue?
Let's say I want to set up a simple one to many relationship between
information about a company and then individuals who worked for that
company. How would I go about such a thing?
Do I setup a companyclass and a personsclass and then link them somehow with
the dblist?
What's the best user interface setup for this too so it's easy for users to
enter company and people data?
Are there any examples of HQL queries about how one would then search to
display individuals details along with elements of their companies details?
Referencing the relationship?
Or is there another way to do this? Any pointers would be very much
appreciated?
Thanks
Helen
--
View this message in context: http://n2.nabble.com/mimic-relational-database-one-to-many-relations-tp4185…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Devs,
I just realized that I've been having a velocity bridge class inside an
*.internal package for sometime.
I think this is wrong because velocity bridges are part of our public API
(?). Moving this bridge to a non-internal package would not harm because it
would not break any existing velocity scripts.
WDYT?
- Asiri