April 2009 - xwiki-devs@xwiki.org

[xwiki-devs] Status of OpenSocial specs and implementations (Shindig) for v0.8 and v0.9 versions
by Anamaria Stoica 29 Apr '09

29 Apr '09

Hi, I have made a little research about the current status of the OpenSocial specs and implementations (Shindig) for v0.8 and v0.9 versions. My findings resume to the following: Supported version by OpenSocial Containers: All OpenSocial containers listed on http://wiki.opensocial.org/index.php?title=Containers use at most version v0.8 Container Compliance Tests: A nice tool to check the compliance of the existing containers (including Shindig) against the open social specs is http://opensocial-compliance.appspot.com/. The test suits available are mostly for version v0.7 of the specs, and the test results are generated using the Compliance Gadget ( http://code.google.com/p/opensocial-resources/wiki/ComplianceTests) (all tests with priority P0 must pass in order for a container to be spec compliant). Note that a gadget for testing version v0.8 is available but there are no tests submitted by the containers (except one). v0.9 status: The final publication of the v0.9 version has been made on April 4th (2009), which is the last step in the OpenSocial Spec Process ( http://wiki.opensocial.org/index.php?title=Specification_Process) This page reflects the current status http://wiki.opensocial.org/index.php?title=Spec_Changes#Current_Status_At_a…. Other resources: Open Social Specification -- Implementing Version 0.9 http://sites.google.com/site/opensocialdraft/Home Open Social Specification -- Implementing Version 0.8.1 http://www.opensocial.org/Technical-Resources/opensocial-spec-v081#TOC-Comp… Release notes for v0.9 http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocia…: This page lists the improvements added by v0.9, many very helpful, like: - OpenSocial Templates and OpenSocial Markup Language - simplified JS API - proxied content - data pipelining - albums and media items - formal definition of the fetch/cache/invalidate model - IS_FRIENDS_WITH and set of mutual friends - etc. Applications and Gadgets: As v0.9 was just launched and all containers out there support v0.8, Applications and Gadgets are also implemented using the v0.8 version of the specs. New apps implementing the v0.9 will appear as containers also start implementing the new specs. Status of Shindig: Shindig includes all JavaScript APIs as described in OpenSocial API Reference ( http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/opensocia…) and Gadgets API Reference ( http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-r…) (versions 0.8) They are currently implementing the v0.9 specs. See the correspondence between Shindig versions and OpenSocial Spec versions here : http://cwiki.apache.org/confluence/display/SHINDIG/Index;jsessionid=2AAEBC0… By integrating Shindig we would support whatever version of the OpenSocial specs they are supporting. Next steps: Besides continuing to read about OpenSocial and Shindig, as next steps I was thinking of trying to follow the tutorial on how to integrate shindig with your site ( http://cwiki.apache.org/confluence/display/SHINDIG/The+rough+guide+to+deplo… ) and check out the example OpenSocial applications based on Java/PHP Shindig : SocialSite(https://socialsite.dev.java.net/) and maybe Partuza( http://code.google.com/p/partuza/) Thanks, Anamaria

1 0

Re: [xwiki-devs] [xwiki-notifications] r19186 - platform/core/branches/xwiki-core-1.8/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/openoffice
by Sergiu Dumitriu 29 Apr '09

29 Apr '09

asiri (SVN) wrote: > Author: asiri > Date: 2009-04-29 11:14:28 +0200 (Wed, 29 Apr 2009) > New Revision: 19186 > > Modified: > platform/core/branches/xwiki-core-1.8/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/openoffice/DefaultOpenOfficeServerManager.java > Log: > XWIKI-3721: Starting an already started openoffice server should be prohibited > Shouldn't the UNKNOWN state also be considered, like: if (ServerState.UNKNOWN != currentState && ServerState.RUNNING != currentState) > - if (ServerState.UNKNOWN != currentState) { > + if (ServerState.RUNNING != currentState) { -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 4

[xwiki-devs] It's translation time again :-)
by Guillaume Lerouge 29 Apr '09

29 Apr '09

Hi, The XWiki translation tool located at http://l10n.xwiki.org/ has been upgraded yesterday. Starting today, new message strings are automatically loaded into the translation tool every night at 2:00 am Paris time. This means that whenever a developer commits a new portion of code that requires to be translated, it will show up on http://l10n.xwiki.org/ the next day. The immediate effect of this change is that approximately 120 new messages to translate have been added for XWiki Enterprise since yesterday. Some of the languages that used to be finished (such as german, romanian or spanish) are no longer complete. You can check the actual numbers here: http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources Additionally, some contributions have not been reviewed yet. Reviewing translations helps finding & fixing typos and other mistakes. It would be great if members from the community could look at it and review translations where applicable. Since we're close to the release date of XE 1.8.3 (and soon XE 1.9 M2) it would be awesome if some of you guys could update the tool with missing translations and reviews. I'm done with French already, 15 languages to go ;-) Many thanks in advance on behalf of the community, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

1 0

Re: [xwiki-devs] [xwiki-notifications] r19183 - in platform/core/trunk/xwiki-officeimporter: . src/main/java/org/xwiki/officeimporter/internal/openoffice
by Sergiu Dumitriu 29 Apr '09

29 Apr '09

asiri (SVN) wrote: > Author: asiri > Date: 2009-04-29 09:52:15 +0200 (Wed, 29 Apr 2009) > New Revision: 19183 > > Modified: > platform/core/trunk/xwiki-officeimporter/pom.xml > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/openoffice/DefaultOpenOfficeServerManager.java > Log: > XWIKI-3711: Upgrade officeimporter to use jodconverter-3.0-beta-2 > Could this port be taken from a configuration? I don't like magic numbers. > + OfficeConnectionMode connectionMode = OfficeConnectionMode.socket(8100); -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

Re: [xwiki-devs] [xwiki-notifications] r19164 - xoffice/trunk/xword/XWikiLib/Clients
by Sergiu Dumitriu 28 Apr '09

28 Apr '09

fciubotaru (SVN) wrote: > Author: fciubotaru > Date: 2009-04-28 18:39:39 +0200 (Tue, 28 Apr 2009) > New Revision: 19164 > > Modified: > xoffice/trunk/xword/XWikiLib/Clients/XWikiHTTPClient.cs > xoffice/trunk/xword/XWikiLib/Clients/XWikiXMLRPCClient.cs > Log: > XOFFICE-67 Implement the XmlRpc client using the CookComputing proxy > Modified: xoffice/trunk/xword/XWikiLib/Clients/XWikiXMLRPCClient.cs > =================================================================== > --- xoffice/trunk/xword/XWikiLib/Clients/XWikiXMLRPCClient.cs 2009-04-28 15:46:05 UTC (rev 19163) > +++ xoffice/trunk/xword/XWikiLib/Clients/XWikiXMLRPCClient.cs 2009-04-28 16:39:39 UTC (rev 19164) > @@ -2,20 +2,52 @@ This should be configurable, since not all instances use /xwiki/ > + private const string XML_RPC_PATH = "/xwiki/xmlrpc"; Typo: > + /// <param name="password">The passowrd used to authenticate.</param> You forgot to implement this: > + /// <summary> > + /// G > + /// </summary> > + /// <param name="docName"></param> > + /// <returns></returns> > public System.IO.Stream GetWikiPageAsPlainHTML(string docName) > { > throw new NotImplementedException(); > } -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

Re: [xwiki-devs] [xwiki-notifications] r19162 - platform/core/trunk/xwiki-core/src/main/resources
by Vincent Massol 28 Apr '09

28 Apr '09

Warning, warning... The merge is wrong.... I had made some changes, see below On Apr 28, 2009, at 5:46 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-04-28 17:46:00 +0200 (Tue, 28 Apr 2009) > New Revision: 19162 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties > Log: > XWIKI-3718: Update french translations > > Modified: platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties 2009-04-28 14:29:14 UTC (rev 19161) > +++ platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties 2009-04-28 15:46:00 UTC (rev 19162) [snip] > -XWiki.XWikiPreferences_smtp_server=Serveur > -XWiki.XWikiPreferences_smtp_port=Port > +XWiki.XWikiPreferences_smtp_server=Serveur SMTP This is not correct for example. There are other places too probably. You need to check the merge. Thanks -Vincent

1 0

[xwiki-devs] In-wiki macros : generic wiki macro, or bridged script macros or selectable implementation ?
by Jerome Velociter 28 Apr '09

28 Apr '09

Hi devs, I'm going to continue the work on allowing users to write syntax 2.0 macros inside the wiki (http://jira.xwiki.org/jira/browse/XWIKI-3213) We have several implementations possible for this: 1. Having only one generic wiki macro implementation. This means macro authors will have to call explicitly the velocity macro inside if they need velocity scripting (same for other script languages) * Pros: - You can use wiki syntax in your macro. This is cool, it enables doing things like wikipedia templates (http://en.wikipedia.org/wiki/Help:Template) - We can easily provide the GWT-WYSIWYG to macro authors. This is an idea I like - It sound pretty natural to do it this way * Cons: - We'll have to put macro parameters in the XWiki context so that they are available to all script macros used in the macro. It means authors will have to refer to parameters using $context.get("parameterName") instead of $parameterName that would be doable with 2. 2. Writing one implementation per script language. This means authors will create a velocity macro and will write directly velocity code in the code are of the macro. * Pros: - Parameters don't need to be passed in the XWiki context (at least I think, if I'm wrong please explain me/us why) * Cons: - We'll have several XWiki classes, one per supported scripting language (XWiki.VelocityMacroClass, XWiki.GroovyMacroClass, etc.) - We cannot use wiki syntax in any implementation, so we cannot do the wikipedia templates-like thing 3. Keep for ourselves the ability to chose from the wiki the implementation class of the macro, but default on 1. the generic script macro. This means we will have a "class" field in the XWiki.MacroClass which allows to chose which implementation should be the code rendered against. If we do that I think this field should be hidden in the class sheet, and only be accessible using the object editor. This is similar to the way Scheduler Job objects works right now. * Pros: - Best of both world, we can have 1. and 2. - Leaves open the door for new macros implementations we could want in the future, or that developers would want just for their wiki * Cons: - Probably a little more code to handle that Right now, I tend to think we should do 3. with only one implementation available at first, being the generic wiki macro described in 1. WDYT ? Thanks in advance for your feedback. Cheers, Jerome.

2 1

Re: [xwiki-devs] [xwiki-users] Links, WYSIWYG 2.0 (1.8.2)
by Anca Paula Luca 28 Apr '09

28 Apr '09

hel-o wrote: > Hi, > > the link dialog works much better than in 1.8.1, but one thing i found: > > i don't use the space for the page parent when i add the parent manually > (which i had to, since it wasn't added automatically in the new syntax) > because i found, that it's not needed to work (as it is in links when the > link is in the same space). > > Now when i want to create a link to a wiki-page i get the tree-view (which > is great) but it seems i cant see all those pages where no space is > provided. Hi Hel, thanks for reporting this behaviour! Of what I experimented just now, this seems to be caused by the REST API (used by the tree) for getting pages and the way it uses the passed "parent" parameter. Specifically, it does not interpret the value of the document parent field wrt the document's space. I see 2 solutions: 1/ either we change the panel to set the parent field to a fully qualified name (when a user inserts only a document name in the parent field, we append the space) 2/ either we fix the REST API. Solution 1 might cause problems when it will come to multiwikis, when the parent can be prefixed by the wiki name as well (wiki:Space.Page). Or: 3/ we change the parent-child relation in the explorer tree so that we make it survive such situations. Happy coding, Anca Luca > > hel. > > > > ----- > ---- > hel(a)hel.at >

1 0

[xwiki-devs] [Proposal] Inline mode for XWiki Syntax 2.0
by Vincent Massol 28 Apr '09

28 Apr '09

Hi, We need to have automatic inline edit mode for XWiki Syntax 2.0 (http://jira.xwiki.org/jira/browse/XWIKI-2891) I'd like to implement this quickly since it prevents to use the xwiki syntax 2.0 as the default syntax (for ex if you create a user in 2.0 syntax and click edit you'll edit it in wysiwyg mode instead of inline mode). A quick solution I have: * Use the XWikiDocument template field to set the sheet to use * When a page has the template field set, when the user clicks on the edit button it goes automatically in inline edit mode * Add a new field in the information edit panel to set the template (only for advanced users I think) WDYT? Thanks -Vincent

6 19

Re: [xwiki-devs] [xwiki-notifications] r19154 - in platform/core/trunk/xwiki-rendering: . xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rendering-tests/src/test/resources/group
by Vincent Massol 28 Apr '09

28 Apr '09

On Apr 28, 2009, at 2:04 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-04-28 14:04:43 +0200 (Tue, 28 Apr 2009) > New Revision: 19154 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/group/group11.test I'd have put put in the same test file we already have for testing parameters for groups (ie group9.test). Otherwise it doesn't sounds obvious why and we should add some comments anyway in group9.test saying that we test group parameters. [snip] Thanks -Vincent

1 0