Hi,
In order to integrate Shindig with the XWiki datastore, 4 interfaces have to
be implemented: PersonService, AppDataService, ActivityService and
MessagesService (javadocs here [0]). To this end, I have created the
xwiki-social-opensocial module [1].
While implementing PersonService (PersonServiceXW - [2]), I have encountered
the following problem:
As I needed to access the datastore, I also made PersonServiceXW a XWiki
Component in order to gain access to the DocumentAccessBridge Component.
BUT, here is the problem, the DocumentAccessBridge never gets initialized
and at runtime is null.
The reason this might happen, as Sergiu suggested, is that Shindig uses
Guice to bind the services implementations in its code, thus the
PersonServiceXW component never gets to be registered with XWiki's Component
Manager.
My question is how do I get data in and out XWiki's datastore from the
PersonService implementation, if I cannot use the DocumentAccessBridge this
way? Can it be registered to the Component Manager somehow, or is there a
completely different way this could be achieved?
I will continue with some integration details (about the patch on
xwiki-web-standard and the OpenSocial XWiki Application). At the end I
included some instructions on how to build and test them.
***xwiki-web-standard patch (apply on xwiki-platform-web), consisting of:
- in standard/src/main/webapps/templates:
* added 3 .vm files which handles getting/adding/deleting friends:
addfriend.vm, getuserfriends.vm, deletefriend.vm
- in standard/src/main/webapps/resources/xwiki/opensocial:
* added javascript and css files necessary for the Shindig container
- in standard/src/main/webapps/WEB-INF:
* modified web.xml to include all shindig servlet mappings and necessary
Guice modules
- in standard/src/main/webapps/WEB-INF/classes:
* added container/default/container.js and shindig.properties - default
Shindig container configurations. I put them in the classpath as they
required modifications from the original files
- in standard:
* modified pom.xml, to include as a dependency xwiki-social-opensocial
module
***Open Social XWiki Application, consisting of:
- OpenSocial.GadgetContainerClass - the simplest OpenSocial Gadget
container; has a single url property (the url of the gadget); in view mode
it displays/renders it
- OpenSocial.GadgetContainerClassSheet
- OpenSocial.GadgetContainerClassTemplate
- OpenSocial.HelloWorld - hello world Gadget (only displays a String) - NO
OpenSocial features - works
- OpenSocial.LabpixiesTodo - Gadget with NO OpenSocial features 1 - works
- OpenSocial.Horoscope - Gadget with NO OpenSocial features 2 - works
- OpenSocial.ListFriends - SHOULD list the friends of the currently logged
in user. The friends are retrieved using the XWiki implementation of the
Shindig's PersonService, which is located in the xwiki-social-opensocial
module (PersonServiceXW). The service TRIES to use DocumentAccessBridge
component in order to retrieve the necessary data from the XWiki datastore.
- OpenSocial.TestingGadgetsSource - used to attach gadgets XML files to the
page. Their URLs can be used for GadgetContainerClass objects (e.g.
ListFriends gadget)
- Panels.My Friends - panel, displays the friends of the currently logged in
user
- Panels.Navigation
- XWiki.FriendClass - A friend; objects of this type can be attached to user
profiles; has as a single property friendName, which contains the name of
the friend
- XWiki.FriendClassSheet
- XWiki.FriendClassTemplate
- XWiki.XWikiUserSheet - to add the list of friends to profile
- XWiki.MyResources
- XWiki.XWikiPreferences
Instructions for testing (one possible way at least):
1. Patch xwiki-platform-web (changes are only in xwiki-web-standard), with
the patch from JIRA - [3]
2. Build xwiki-web-standard
3. Build xwiki-enterprise in offline mode (-o), so it will use
xwiki-web-standard from the local repository build at step 2
4. Run XWiki Enterprise. I always use
xwiki-enterprise-jetty-hsqldb-2.0-SNAPSHOT from the generated distributions
5. Import opensocial XAR - [4]
What to look for while testing (working stuff):
- Gadgets:
- see all/add new gadgets
http://localhost:8080/xwiki/bin/view/OpenSocial/GadgetContainerClass
- http://localhost:8080/xwiki/bin/view/OpenSocial/HelloWorld
- http://localhost:8080/xwiki/bin/view/OpenSocial/LabpixiesTodo
- http://localhost:8080/xwiki/bin/view/OpenSocial/Horoscope
- http://localhost:8080/xwiki/bin/view/OpenSocial/ListFriends (social
features) --> as specified before, not working
- While you're here, you could also:
- Log in as Alice (password 'alice')
- Go to profile page and edit friends list; You should have 2 friends:
Jane and Bob (they have as passwords 'jane', and 'bob')
- See My Friends Panel, with the friends of the current logged in user
displayed
[0] -
http://incubator.apache.org/shindig/shindig-1.1.x/apidocs/org/apache/shindi…
[1] -
https://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/opensocial/xwiki-social-op…
[2] -
https://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/opensocial/xwiki-social-op…
[3] -
http://jira.xwiki.org/jira/browse/XSANDBOX-36?focusedCommentId=43674&page=c…
[4] -
http://jira.xwiki.org/jira/browse/XSANDBOX-64?focusedCommentId=43675&page=c…
Other helpful links:
- Guice module configuration for my service implementations
https://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/opensocial/xwiki-social-op…
- Exemple of PersonService being injected by Guice in Shindig's code
http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api/src…
Thanks,
Anamaria
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.9.3.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is a bug fix and enhancement release mainly around security and
the tag and mailsender applications.
Changes since XWiki Enterprise 1.9.2.
Improvements:
* XWIKI-4065 New Footnote macro
Important Bugs fixed:
* XWIKI-4109: Guest users are sometimes logged in with another user account
* XWIKI-3827: GWT wysiwyg editor has dark background with Albatross skin
* XPMAIL-17: Wrong characters in non-ascii emails
* XATAG-21: List documents with tag, rename/delete tag fails with
specific versions of MySQL5
* XATAG-22: Rename and delete actions fail with tag containing non-ascii chars
* XABLOG-27: Article date not displayed properly in IE6
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise193
Thanks,
The XWiki dev team
Hi,
Please give feedback on the menu iteration. You can view the mockups at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20Menu
1. We need to decide the way we handle the actions we are able to do
(depending on the rights we have): enable/disable them or hide them.
2. You can select to have an simple or advanced menu (View and Edit submenus
affected)
Thanks,
Caty
Hi devs,
I would like to introduce a first partial beta of the event network
distribution system in the 2.0M3.
Note that the module itself is complete what will need to be done with
debugging is making everything in core use the new Observation Manager
instead of the old notification service.
For this release i plan to:
- add the remote observation manager module (disabled by default)
- implement a EventConverter for documents events (event convert has a
generic converter for Serializables events but documents converted has
XWikiDocument and XWikiContext we want to filter before sending it to
the network).
- make XWiki cache store listen to remote doc event to invalidate the
cache accordingly (this is the main thing that will bring event based
clustering support to XWiki, all the rest is already supposed to
update its cache based on events remote or not)
Here is my +1
--
Thomas Mortagne
Hi
I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0).
There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3.
One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working?
Cheers
Andreas Schaefer
Hello,
Could you please consider writing a short tutorial on creating /
modifying skins?
For example, how to use a custom logo?
Right now I'm trying to replace standard Toucan logo with my own with a
couple links below it, I tried replacing <div id="companylogo"> fragment
in global.vm, but I'm completely stuck with the css part. The logo and
the links are there all right, but the layout is wrong. And I can't
simply search-and-replace all 220s and 80s, because it's not a single
picture but a table with 2 pictures and 5 links inside. I'd probably
manage to do it by trial and error, but then I'd have no idea if it
looks the same on other systems.
It's probably easy, but my knowledge of css is rudimentary (basically I
know what it is, how to apply it, and how to use it for fonts, sizes and
colors; layouts are beyond me).
It would be nice to have a basic tutorial like "if you want to replace
the logo with your own picture enter it's size here, here and here, if
you want to replace it with arbitrary html change this, this and this so
the height of the logo area isn't hardcoded".
Greetings, Lilianne
Hello Community,
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is the
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex, dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best results
and doesn't depend on an external service. SnuggleTeX is configured as a
backup (safe) renderer which kicks in when the default one isn't working
(missing tex subsystem, or communication error with the remote server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for this
component.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
We have some rules on http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle#HPackagenames
I'd like to clarify it with this:
* A module's package name should be of the form
org.xwiki.....<modulename>
* Thus the internal package should start at
org.xwiki.....<modulename>.internal.*
* Default modules (*-default) should use the same package root as the -
api module they're implementing.
WDYT?
Thanks
-Vincent