November 2012 - xwiki-devs@xwiki.org

[xwiki-devs] Set javascript variable to velocity variable
by firmusoft.xwiki 11 Nov '12

11 Nov '12

How can we set javascript variable to a velocity variable? Please reply with a solution for this. If you have sample it would be more helpful. Thanks, Firmusoft

2 1

[xwiki-devs] [Contrib] xwiki-task-executor
by Fabio Mancinelli 10 Nov '12

10 Nov '12

Hi, while working on a project I developed this simple system for managing the execution of long running execute-once tasks. It uses the scheduler and it provides a nice framework for logging and error reporting. The main use case for this extension is batch import of data, but also execute-once maintenance operations. Basically every task that is too long or heavy to be carried on in a single request, and doesn't really qualify to be a scheduler job. You can think of this system as a task queue that is processed in the background. I am contributing it to xwiki contrib. Thanks, Fabio

3 6

[xwiki-devs] [PROPOSAL] Allow servlets to be registered with the ComponentManager.
by Caleb James DeLisle 10 Nov '12

10 Nov '12

Hi, I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest") Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav. * If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't. * Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets. The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features. If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets. WDYT? Are there reasons not to do this which I missed? Caleb

3 6

[xwiki-devs] [VOTE] Dynamically registered wiki translations
by Thomas Mortagne 10 Nov '12

10 Nov '12

Hi devs, Following the discussion about general architecture of the new localization module here is a more detailed proposal for the dynamically registered wiki translations pages. Here is how I propose to indicate that a document contains key=value pair translations: * put an object of class "XWiki.TranslationDocumentClass" * set the "visibility" field to "Global", "Current wiki", "Current user" As for the content of the document it will stay the same as in preferences based documents for now. I have other fields in mind for later (on demand, translation message syntax, etc.) but this is a 4.3 proposal here. WDYT ? Here is my +1. -- Thomas Mortagne

9 19

[xwiki-devs] [VOTE] merge branch 'feature-solr-search' into 'master' for 4.3M2
by Eduard Moraru 09 Nov '12

09 Nov '12

Hi devs, I would like your vote on merging the 'feature-solr-search' branch with 'master' for 4.3M2 as planned in the Roadmap. Merge Notes: - A first version of the Solr search is bundled by default as experimental with XE, but Lucene is still the default search engine. --- Lucene has been upgraded to 3.6.1 [1] and Solr has been downgraded to the same (3.6.1) version in order to achieve the peaceful cohabitation between the 2 search versions. If we want Solr 4.0, we need to work a bit more on the Lucene search, since Lucene 4.0 comes with a considerable number of refactorings. ----- I have just noticed Jerome's feature-lucene-4.0.0-upgrade [2] branch. - The admin needs to use the Search Administration to switch from Lucene to Solr and back. (each engine has its own index) - The back-end contains a SolrIndex for add/delete operations and a QueryExecutor to query the index trough XWiki's Query API using the 'solr' language. - Indexing is only manually performed for now, from the Search Administration, blocking the request until the operation is complete. - Search highlighting is available - The default search looks only for Documents. Filtered/Advanced search options can be used to change some of the search parameters. - Lucene/Solr syntax is supported in the query string - Faceted search is currently hidden because it is not yet in an usable state. - SearchSuggest is still using Lucene, no matter what the configuration in Search Administration says - The merge also contains a fix for a pretty nasty yet easily fixable Lucene deadlock [3] (introduced 10 months ago) and some Search Admin UI improvements [4] The pull requests [5][6] are available for reviewing so start shooting :) Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-8407 [2] https://github.com/xwiki/xwiki-platform/tree/feature-lucene-4.0.0-upgrade [3] http://jira.xwiki.org/browse/XWIKI-8406 [4] http://jira.xwiki.org/browse/XWIKI-8408 [5] https://github.com/xwiki/xwiki-platform/pull/73 [6] https://github.com/xwiki/xwiki-enterprise/pull/34

7 9

Re: [xwiki-devs] [xwiki-users] Paste picture/image from clipboard
by Paul Libbrecht 09 Nov '12

09 Nov '12

There are several such features related to copy and paste (and drag-and-drop) which a newer trends could choose to follow. I'd be more than happy to advise on a GSoC project for such. But maybe there's an interest before. It's almost exclusively JS work. paul Le 9 nov. 2012 à 12:05, Guillaume Lerouge a écrit : > No. You have to save it first, then upload it to the wiki page. > > Guillaume > > On Fri, Nov 9, 2012 at 11:59 AM, Hamster <teunham(a)hotmail.com> wrote: > >> Is it possible to paste an image from MS Paint directly into an xwiki page?

1 0

[xwiki-devs] [VOTE] New release dates for the 4.3M2/RC1/Final releases
by Eduard Moraru 07 Nov '12

07 Nov '12

Hi devs, Since last week was light on development (due to various holidays) and today we are already past the release date for 4.3M2, after talking with Vincent, we propose to postpone the 4.3 releases by a couple of days, as follows: Current dates: 4.3M2: 5 Nov 4.3RC1: 12 Nov 4.3final: 19 Nov Proposed postpone dates: 4.3M2: 9 nov 4.3RC1: 14 nov 4.3final: 21 nov Here's my +1 and I will be Release Manager for 4.3M2. We are still looking for Release Managers for the next releases, so please feel free to propose your selves Thanks, Eduard

6 9

[xwiki-devs] Fwd: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension.
by Ludovic Dubost 07 Nov '12

07 Nov '12

This should have been for devs Envoyé de mon iPhone Début du message transféré : > Expéditeur: Ludovic Dubost <ludovic(a)xwiki.com> > Date: 23 octobre 2012 09:19:55 UTC+02:00 > Destinataire: XWiki Users <users(a)xwiki.org> > Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. > > Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's > > Not sure it's a good thing. I'm sure Vincent will agree > > Ludovic > > > Envoyé de mon iPhone > > Le 23 oct. 2012 à 04:17, Caleb James DeLisle <calebdelisle(a)lavabit.com> a écrit : > >> One other thing, please report the features which you want and what you imagine as >> best on the github tracker, it's easier to close an issue as "won't fix" than it is >> to remember an important issue which nobody wrote down ;) >> >> Thanks >> Caleb >> >> On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>> Hi, >>> >>> Thanks for the complement. >>> >>> I just updated it and fixed issue #1. Thanks for reporting it. >>> Somehow showing who else is editing, showing where they are editing in the document >>> and allowing the user to spawn a chat window with other editors on the page are all >>> interesting possibilities. Right now I think the thing to do is decide where there >>> is the most bang for your buck in terms of feature value and get an idea of what's >>> most natural for the user. >>> >>> Thanks, >>> Caleb >>> >>> >>> On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>> Great work! >>>> >>>> It looks like good starting point to give xwiki the main (at least for >>>> me) feature, that makes googledoc sometimes more suitable for >>>> collaborative editing. It would be really great, if your editor would >>>> show somehow, where the other editor (person) is now, where is his >>>> cursor. Maybe a highlight (the whole line) showing the other's cursor >>>> placement? >>>> Do you plan to work on such improvements? >>>> >>>> R. >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> users mailing list >>> users(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >> >> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users

5 18

[xwiki-devs] [VOTE] Clirr difference for fixing content dirty flag.
by Andreas Jonsson 07 Nov '12

07 Nov '12

Hi, I am requesting a vote for adding the following clirr difference: <difference> <className>com/xpn/xwiki/objects/ListProperty</className> <field>list</field> <differenceType>6006</differenceType> <justification>Elemenents must be added to the wrapping NotifyOnUpdateList to ensure that the property is marked 'dirty' when updated. To avoid that this mechanism is circumvented, the field is made final.</justification> </difference> The flag isContentDirty in XWikiDocument is currently always true when a document is loaded from the database. This means that a script that just load and save a document without modifying it will generate a new version, and the point of the flag is completely lost. It is also a blocker for my work in the feature-authorization-context branch. Fixing this was non-trivial. It is assumed everywhere that the content dirty will be set, not only when the document content changes, but also when a property, the xclass or any attachment changes. But there were no code that actually set the flag on updates (because it was always true anyway). What's worse is that we have API methods that returns lists that are live updateable. I have added a wrapper list class to detect the updates in these lists. Hibernate refuse to store elements from my wrapper list for some reason which forced me to add a workaround for hibernate. Surprisingly, Clirr doesn't require any exception for the below methods which I have added, but I will list them here for your information: In BaseClass: public void setOwnerDocument(XWikiDocument ownerDocument) public void setDirty(boolean isDirty) In BaseProperty: public boolean isValueDirty() protected void setValueDirty(Object newValue) public void setValueDirty(boolean valueDirty) public void setOwnerDocument(XWikiDocument ownerDocument) In ListProperty: public void setUseHibernateWorkaround(boolean useHibernateWorkaround) In XWikiAttachmentContent: public void setOwnerDocument(XWikiDocument ownerDocument) New class: AbstractNotifyOnUpdateList<E> Best Regards, /Andreas

2 2

[xwiki-devs] Release Manager for 4.3M2 needed ASAP!
by Vincent Massol 06 Nov '12

06 Nov '12

Hi devs, We need a RM for 4.3M2 which should have been released yesterday... See the Roster to see if you'd be a good candidate: http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseManagerRoster If you haven't done a lot of releases yet then you're a good candidate ;) Thanks -Vincent

1 0