May 2012 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki Enterprise 4.1 Milestone 2 Released
by Caleb James DeLisle 31 May '12

31 May '12

The XWiki Development Team is pleased to announce the release of XWiki Enterprise 4.1 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the second and final milestone of the XWiki Enterprise 4.1 development cycle. Changes from Milestone 1: * Extension Manager now handles updates to configuration documents. * New localization through timezone settings. * Customization of chart colors. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks, The XWiki Development Team

1 0

[xwiki-devs] [VOTE] Merge the new diff API/service
by Thomas Mortagne 31 May '12

31 May '12

Hi devs, As I said in another mail I'm working on a diff/merge module to use in XWiki, the first target being Extension Manager and document history (since both are going to use the same code, see Marius mails). You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2. TODO/QUESTIONS: * improve the generic 3 ways merge to be at least as good as the List<String> 3 ways merge and get rid of JDiff * not sure where/if I should put String related helpers (things that do a diff on two String instead of having to cut List<String> or List<Character> and call the diff API etc.) I'm ready to merge it into master so I'm waiting your vote. Caleb is it OK to put new stuff in master already or should I wait the complete release to be done ? Here is my +1. Thanks, -- Thomas Mortagne

5 19

[xwiki-devs] [Proposal] Add notion of "Restricted" Configuration Source to XWiki Commons
by Vincent Massol 30 May '12

30 May '12

Hi devs, We have the need of a Configuration Source component hint for implementation that only looks in non-modifiable sources (e.g. xwiki.properties). More specifically there's a security issue in some cases in allowing to use the current "default" configuration source which looks in space preferences, wiki preferences and the only in xwiki.properties. For example the Environment's permanent directory should not be modifiable from wiki pages (see http://jira.xwiki.org/browse/XCOMMONS-182) So here's the proposal: * Introduce a new RestrictedConfigurationSourceProvider implementation (in configuration-api) that does the same as the current ConfigurationSourceProvider but when looking up the CS, it looks for a CS with hint "restricted" * Deprecate the current XWikiPropertiesConfigurationSource (hint = "default") * Add a new XWikiPropertiesConfigurationSource with hint = "restricted" * Modify DefaultEnvironmentConfiguration to use: @Inject @Named("restricted") private Provider<ConfigurationSource> configurationSourceProvider; WDYT? Thanks -Vincent

4 7

[xwiki-devs] [ANN] Releasing tomorrow, please reply if the release must be delayed.
by Caleb James DeLisle 30 May '12

30 May '12

Hi, I would like to release M2 early tomorrow, if any developer needs to hold the release to make a change, or has any questions, please reply to this mail before the end of today. Thanks, Caleb

1 0

[xwiki-devs] Newer versions of attachments are not indexed by Lucene
by marczi＠dev-labs.com 30 May '12

30 May '12

Hi, I know this is not a support list, but we found a bug that we consider serious related to searching: http://jira.xwiki.org/browse/XWIKI-7753 Since search is an often used function, we believe others have faced this so I'd like to ask the most experienced ones if this bug is a real bug, or we just misconfigured XWiki. Thanks in advance, Daniel Marczisovszky

1 0

[xwiki-devs] Best way to add buttons on wysiwyg toolbar
by Geo Du 30 May '12

30 May '12

Hi, all, I am trying to add buttons on the wysiwyg or inline form editor toolbar, I checked the wysiwyg gwt source code, and the wysiwyg.js file, I am more toward add javascript code in wysiwyg.js file to add javascript code for buttons on the toolbar, instead of adding java code for the plugin, any suggestions? Thanks in advance Dave

2 4

[xwiki-devs] the wysiwyg js api to use in client
by liujinlong5788 30 May '12

30 May '12

Hello ,I wander if there is the js api document about the wysiwyg which I can use in client .I need to add a very very simple function to the wysiwyg in client. but I only find some api I can use here!(I use xwiki 3.5) http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#… Is there api in detail ?.In fact ,The most important thing is to add some HTML elements (just as div or button)to the xwiki document .It is very easy no matter in javascript or gwt(It is unable to use here because of some problems, so I have to implement it in client with js). But I don't know how to operate the xwiki document w't ith js,I even can't get it ,so .. A poor student with poor English and programming knowledge who have to develop the system by himself need your help .Thanks ! Why can't we offer the download of apis ? of it's just I havn't fount theml

1 0

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 29 May '12

29 May '12

Hello friends, Thank you, glad to hear that I am getting somewhere Here is a better version of the sidebar: http://jssolichin.com/public/4/4.%20Home-alt.png The boxes with the x will be icons. having those I think will help inform the reader what is available, instead of the previous metro like overflow. It will also allow a space for numbers showing how much content is available in that section. When you hover over that section, it will still reveal the hover nav in the last mock up to allow for easier clicking and clarity (as to what the icons are): http://jssolichin.com/public/4/3.%20Home-navhover.png I know that the icons will not fit with longer section names like comments, so the icon might be placed above the section name, or be smaller. On that point, I would just like to mention that i'm hoping to also allow the reader to resize the sidebar size fluidly. So if they are reading the comments section, they can devote more space to it. This will, however, be disabled in the mobile version. * The way the navigation links are organized/grouped together is a bit > weird (the upper part with wiki/space/page links) > Visually, I'm not sure if it came through in the wireframe, but i'm imagining it like the iphone folder [1], where we have the breadcrumb/nav (wiki/space/pages) always visible, then when the user clicks it, it reveals the "watch page, access rights, etc." By iphone folder like i mean, it pushes everything down and visually seems to reveal something underneath. But that last point is trivial. More technically, since the navigation is vertical, the breadcrumb style is a bit unclear, and do need to be more refined. Right now i'm thinking maybe a folder esque structure: x wiki \_ x space \_x pages but I feel like that might get to cluttered. Maybe we should just remove the breadcrumb navigation and just have it like in the lyrebird where it appears as part of the content and not as a "global nav?" What does the community think? * On the desktop you probably don't want that inner scroller, but > rather have the right panel fixed and keep the page's natural scroll. You're right, that would make sense. I think the right solution would be to make the right sidebar scroll like the chatlist window on facebook where if you hover over the area, it will reveal a scroll bar indicator to show your vertical location and allow you to scroll that section using the mouse wheel. Do you guys think it will be ok that we do not have the up and down arrow? or would that be bad usability. I personally think it will be fine since even sites like gmail uses a non native scroll indicator without the up and down arrow--it's just prettier. The menu part still needs to be refined Did I address it earlier in this email, or am I still missing something? Can you clarify specifically which point for me to work at? > Putting the menu on the left would be more familiar to mobile users (the > > nav menu is usually on the right in all the mobile apps I regularly > use). > Maybe we don't want to be like every other app ;p > I don't know, I think we can try it out on the right and see how it > feels. Same for the desktop in fact ; though I think it's going to > feel more natural on the right in that case. I think both points are valid. I personally chose the right side because I feel like when you land on a page, you want to read content first. But I do know what you mean, left is the traditional side and is used in giant sites like gmail, facebook, hotmail and so forth. I think we should get more input on this. > Jonathan: I don't remember whether Jérôme pointed you to his lyrebird > work: > > > http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cs… > > it could be an additional source of inspiration for you. > I don't remember I did. > Let me fix the link : > > http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css > Also, sources are on github : https://github.com/jvelo/Lyrebird<https://github.com/jvelo/Lyrebird;cid=1338111304826-974> Thank you, this will be a wonderful resource! Let me know what you guys think. Best, Jonathan Solichin [1] http://media.tecca.com/2011/02/17/mh-630-iphone-folder-header-630w.jpg

2 1

[xwiki-devs] [GSOC] Solr Search component
by savitha sundaramurthy 29 May '12

29 May '12

Hi, I want to create a repository in XWiki contrib for Solr search implementation. So, I kindly request you to grant access. -- Thanks, Savitha.s

2 2

[xwiki-devs] [Proposal] Naming convention for new wiki macros
by Eduard Moraru 29 May '12

29 May '12

Hi devs, For the new messageSender macro [1][2], I chose the name using the "attachmentSelector" macro as a template: "<object><personified-action>" Vincent did not really like the "messageSender" name and proposed "message", "sendMessage" or "userMessage". Since AFAIK we don`t currently have a naming convention for wiki macro names, I`d like to propose that we stick to the patterns: 1) "<object><personified-action>" (attachmentSelector, messageSender) for action-oriented macros and 2) "<object(s)>" (documents, spaces, activity) for display-oriented macros For 2), it's pretty clear, but for 1), I personally prefer "<object><personified-action>" since overall it is a noun and, in english, the phrase "messageSender macro" sounds better to me than "sendMessage macro". Also, I think that the main action of the action-oriented macro should be reflected in its name. I`d like your opinion on the matter and also new proposals if you have any. Here's my +1 for 1) and 2). Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

5 4