Hello.
I would like to discuss about some aspect of my work on XWIKI-543
(recycle bin) and XWIKI-1459 (new history storage).
1. [Proposal] Use common.lang.builders & AbstractSimpleClass
When i write simple entity classes (POJO), i wouldn't like to implement
equals, hashcode, toString by hand for first time (it has too much
duplication). commons.lang.builders has fine builders for this. These
builders can do these tasks via reflections.
http://commons.apache.org/lang/api-release/org/apache/commons/lang/builder/…
Can i create class "com.xpn.xwiki.util.AbstractSimpleClass" (maybe
another name?) with these methods implemented via common.lang.builders
(via reflections) for extending in my entities? I think it will be
useful for others too.
Implementation: http://rafb.net/p/G0OcJ427.html
as +:
+ we will get equals(), hashCode() and nice toString() for free :).
+ we can always override these methods later if we will have some issues
+ we can easy switch toString() style in all extended classes
- note: it is only for simple entities with no not-store specific
fields. (So XWikiDocument is inapplicable i think)
WDYT?
2. While i designed how to store history and recycle bin entities i
found similar problems.
I have following data in my entities:
- id
- metadata (several fields)
- content (one field)
One use case is fetch many metadatas for display. (i.e. history summary)
Another use case is load one or several content to some hard work. (i.e.
load old document from history, restore document from recycle bin)
So problems is separate fetching metadata and content. How can i do it?
1) If i put all data in one class, i have to fetch all data via
session.load and hql query.
2) It is possible to configure hibernate with 2 separate entity-name for
one class and one table. So if we use specific entity-name, we fetch
only metadata and content will be null. But i haven't tested it yet. It
looks like hack.
3) solution i have for now is following:
divide entity to EntityInfo and EntityContent. Both has id. You can
see my solution it in patches at XWIKI-1459.
Only defect is increase number of entities.
Maybe there is another way? Or another design?
--
Artem Melentyev
Hi devs,
As previously agreed, I have created a branch for work on 1.1RC1/RC2
in the following modules:
* platform/core
* platform/web
* products/enterprise
* platform/applications/panels
For all those modules trunk becomes 1.2-SNAPSHOT.
This means that if you make a change to the 1.1 branch you MUST also
merge that change to the trunk or it'll be lost forever...
Thanks
-Vincent
Hi,
We have delayed the 1.1M4 release so the 1.1RC1 release is now too
close I think (planned for the 20th).
I propose we move it to the 27th. We'll then see if we have many more
bugs to fix for RC2 and take a call then if we have to delay the
final release by a few day or not.
WDYT?
Thanks
-Vincent
Hi,
I'd like to release those 2 projects in preparation for the release
of the other modules.
Changes for XWiki Tools v1.2:
** Bug
* [XTOOLS-4] - Shutdown the database only for the HSQLDB database
** Improvement
* [XTOOLS-6] - Move the Jetty container files to a module so
that they can be reused by the different products without duplication
** Task
* [XTOOLS-5] - Move the License files to the XWiki Configuration
Resources JAR
Here's my +1
Thanks
-Vincent
Hi,
As Sergiu pointed out I am currently working to improve the
implementation of the XML-RPC API. The discussion is going on
xwiki-dev:
http://www.nabble.com/Proposal%3A-XML-RPC-API---True-Interoperability-with-…http://www.nabble.com/Why-do-we-throw-exceptions-in-the-ConfluenceRpcInterf…
This JIRA issue is also relevant: http://jira.xwiki.org/jira/browse/XWIKI-1560
There are many changes which I will commit after the M4 release, and
any additional help on testing them would be appreciated (especially
if you can provide us automated tests).
On 8/13/07, diaga(a)nomade.fr <diaga(a)nomade.fr> wrote:
> Hi,
> I am still testing the XMLRPC interface. This the first result I have noticed:
>
> 1.There are some messages that are not implemented:
> -public Map getUser(String token, String username);
> -public void addGroup(String token, String group);
> -public Object[] getUserGroups(String token, String username);
> -public void addUserToGroup(String token, String username, String groupname);
>
True, they are not yet implemented. But there are many others as well:
http://jira.xwiki.org/jira/browse/XWIKI-1559
> 2.To make the update or the creation of a page work normally, I have to get the content of a page and to modify his element to have the result I want. This is linked with the fact that we have to use a Map Object to define a page or Map is an interface. So the other solution I haven't tested is to implement the interface Map instead of getting a page and modifying it.
I don't follow you here. Can you please explain better what bothers
you here. Or maybe just give the code you had to write now, and how
you would like it to be.
> 3.For "public Object[] getComments(String token, String pageId);" I have some problem to make it work normally.
I would advise you to wait a couple more days and try the new
implementation of this method from the SVN repository.
> 4.Another result is that I have to flush the cash very often in order to make the Update and creation of a page work. If I don't do that I have to restart my server to see the changes. When all work correct with a login/logout, we see the changes.
There were some complaints before that the modifications through
xmlrpc don't work well with the caches:
http://www.nabble.com/Trouble-with-refresh-after-update-from-xmlrpc-tf39287…http://www.nabble.com/XML-RPC-oddities-tf3607425.htmlhttp://www.nabble.com/On-Which-Features-Should-I-Focus-When-Testing--tf3890…
Since xmlrpc does not use any sort of caching I always thought that
the problem should be somewhere else :) ... But well, maybe we should
do something to use those caches. Any suggestions what to do?
> 5.When I try to get the content of a document created by a Class, I get the content of the Template linked to the Class. I don't know if this is normal or not.
I don't know either. What else would you expect ?
Regards,
Catalin
Hi,
I'd like us to stop committing stuff now and focus on testing and
committing fixes for regressions and errors in what we have committed
(no more patch applications for stuff in 1.1M3).
We need to stabilize now and release 1.1M4 but we can't done that
with a minimum of testing.
WDYT? Is that ok for everyone?
What would be nice is that each of us takes some issues from the 1.1
release notes, test that the implementation works and report it in
JIRA as such. Preferably pick issues that you haven't done yourself
as it'll be more effective.
WDYT?
Thanks
-Vincent
Hi,
We need to start releasing 1.1M4.
Here's a tentative release date:
* Code freeze tonight (Monday, 23:59PM)
* I start doing the release tomorrow morning. Will take me 1 full day
I think, meaning 1.1M4 can be released Tuesday night.
* I create the 1.1 branch on tuesday too. Bug fixes for RC1 and RC2
go there.
* Work on 1.2 trunk can start on Wednesday (I'm not sure how to
release from a branch with maven yet as otherwise I could have
branched right now - I need to check this out).
WDYT?
Thanks
-Vincent
Hi,
We need to release 1.1M4. However there are a few things to finish
before being able to release it. Here's my list:
1) Do some testing on the new features introduced recently:
- nested style macros
- history table and related modifications
- full screen
- wysiwyg new features
If everyone could help here that'd be great.
2) Fix code macro as my changed has been rolled back is it was
causing problems with other macros coming after.
3) Finish fixing TC so that we can have a full clean build
4) Assess scheduler plugin state and verify it works fine. It's
missing some feature (like restart jobs when the server restarts) but
that's ok if they are documented and jira issues created for fixing
this later on
5) Finish testing the installer
6) Restore xwiki.org clean to remove vandalism + write release notes
for 1.1M4
Anything more?
Thanks
-Vincent
Hi JV,
On Aug 12, 2007, at 9:13 PM, Jean-Vincent Drean wrote:
[snip]
> +#if($query != "")
> + #set($lucene = $xwiki.getPlugin("lucene"))
> + #if($lucene)
[snip]
> + #else
> + Error: Lucene plugin not found.
I think it would be nice to tell the user that the Lucene plugin is
not enabled in xwiki's configuration and add a link to the old search
here.
Also what happens if the lucene plugin isn't found? It seems to me
the rest of the code below will get executed, no?
> + #end
> +#end
> +
> +#set($doRebuild = $request.getParameter("rebuild"))
> +#if($doRebuild=="yes")
> + #set($lucene = $xwiki.getPlugin("lucene"))
> + #if($lucene)
> + #set($documentCount = $lucene.rebuildIndex($xwiki,$context))
> + #if(${documentCount}>=0)
> + #info("Started index rebuild with $documentCount documents.\\
> + Will take some time depending on
> the number of pages/attachments.")
> + #else
> + #error("Error: Index rebuild failed.")
> + #end
> + #end
> +#else
> + #if($xwiki.hasAdminRights())
> + #info ("[Rebuild the lucene index>${doc.web}.${doc.name}?
> rebuild=yes]")
> + #end
> +#end
> +
> +#warning("This is the new lucene search engine.\\
> + You can still use the XWiki [default search
> engine>WebSearch?text=$query]..")</content>
There's an extra dot ("."). Shouldn't this be an "info" rather than a
warning? Or it could stay a warning but in that case it might be
better to tell the user that this is an experimental feature, WDYT?
Thanks
-Vincent