July 2012 - xwiki-devs@xwiki.org

[xwiki-devs] Pretty Time library
by Vincent Massol 11 Jul '12

11 Jul '12

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

5 7

[xwiki-devs] Velocity format date
by Hamster 11 Jul '12

11 Jul '12

I'm overlooking something small... How can I format dates with velocity? {{velocity}} #set($myDate = $doc.getContentUpdateDate()) Last updated at $date.format('medium',$myDate) Last updated at $date.format('yyyy-MM-dd',$myDate) {{/velocity}} Both $date.format are not working! -- View this message in context: http://xwiki.475771.n2.nabble.com/Velocity-format-date-tp7580272.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 12

[xwiki-devs] Overall Release Manager stats
by Vincent Massol 10 Jul '12

10 Jul '12

Hi devs, I've computed overall Release Manager stats at http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseManagerRoster Our total # of release after 0.9 is: 173 RM ordered by # of releases: * ThomasMortagne: 49 * jvdrean: 40 * VincentMassol: 33 * sdumitriu: 26 * mflorea: 11 * cjdelisle: 10 * marta: 2 * dgervalle: 1 * rstavro: 1 Well done Thomas and JV! Marius and Caleb you have some catching up to do :) (Well Caleb arrived later in the project so it's not completely fair :)). Denis, you know what you have to do too! Andreas, when are you next? We still need a RM for 4.2M1 and later. Any volunteer? :) Thanks -Vincent

1 2

[xwiki-devs] [VOTE] Change the Class Fan-Out Complexity maximum value in our checkstyle configuration
by Sergiu Dumitriu 10 Jul '12

10 Jul '12

Hi devs, Short version: I'd like to increase the allowed maximum value for the Class Fan-Out Complexity checkstyle rule from 20 to 25, since a bare component already uses 1 to 4 imports, and the 20 rule was set before we had components. Long version: The Class Fan-Out Complexity metric measures how many other classes are used by a class. Keeping this to a small value is a good goal, since it favors loose-coupling, small and independent classes, and makes it harder to put more than one responsibility in a single class. However, there are several problems: One is that this counts utility classes and interfaces, such as java.util.List, and a fairly complex class uses more than one such utility class; they usually come in pairs (the interface and the implementation). And more and more classes are using apache-commons utilities like StringUtils or IOUtils, which are just shortcut helper methods that could be implemented in a few lines of code, so we're trading one import for reduced code complexity, which is a good thing, even though apparently it's increasing the Fan-Out measure. Another is that a bare Initializable component implementation will import: - its component role interface - Initializable and InitializationException - Logger And since good libraries also follow the "many small classes" paradigm, barely using some of our dependencies will add a lot of imports. For example, the LucenePlugin has 25 org.apache.lucene.* imports just for initializing the server and sending search requests. While the current maximum, 20, is enough for the majority of our classes and interfaces, I've found myself often enough trying to refactor a class to get down from 23 or even 21 imports, and usually I find myself doing ugly tricks, keeping the actual code complexity the same or even worse. Best case is that I extract an extra class that just contains the non-public utility methods that were initially in the component implementation, but that class is meaningless out of the context of its parent class, so that is also a bad decision, IMHO. So, I propose to increase the Fan-Out limit to 25, while keeping the requirement that classes should be kept as small as possible. -- Sergiu Dumitriu http://purl.org/net/sergiu/

6 10

Re: [xwiki-devs] [GSoc] Responsive Skin - markup semantics
by Jonathan Solichin 10 Jul '12

10 Jul '12

Hello friends, For example a blog application could want to present a list of > <article>. But maybe nesting <article> inside a main <article> element is > just fine. For a blog homepage, or the blog archive, each > blog article should have its own <article> wrapper, though. Yes, I think Sergiu is right in that html5 allows for nesting of articles. Thank you for the input. On Tue, Jul 10, 2012 at 12:14 AM, Jonathan Solichin <j.s.solichin(a)gmail.com>wrote: > Hello friends, > > For example a blog application could want to present a list of >> <article>. But maybe nesting <article> inside a main <article> element is >> just fine. > > > For a blog homepage, or the blog archive, each >> blog article should have its own <article> wrapper, though. > > Yes, I think Sergiu is right in that html5 allows for nesting of articles. > Thank you for the input. > > On Sat, Jul 7, 2012 at 1:50 AM, Jonathan Solichin <jssolichin(a)gmail.com>wrote: > >> Hi Jerome, friends, >> >> > * Would it make sense to use <aside> for the right sidebar ? >> >> The aside is actually only for the comments, attachments, history and >> info sections of the sidebar only. The reason behind this is that according >> to html5 specs: >> > >> > The aside element represents a section of a page that consists of >> content that is tangentially related to the content around the >> asideelement, and which could be considered separate from that content. >> Such sections are often represented as sidebars in printed typography. ( >> http://html5doctor.com/understanding-aside/) >> >> which I thought is appropriate for those sections. >> >> > >> > * I've seen you've used <article> as an overall wrapper. Wouldn't >> <section> >> > be more appropriate, with articles implemented within the content of >> the >> > document ? (BTW this leads to the question of how this would translate >> in >> > wiki syntax. So far there is no such notion built right in - though .it >> > could be implemented with macros). >> >> The reason I used article as an overall wrapper for the "main content" >> (the stuff with the white background), according to the html5 specs: >> > >> > "The article element represents a component of a page that consists of >> a self-contained composition in a document, page, application, or site and >> that is intended to be independently distributable or reusable, e.g. in >> syndication. This could be a forum post, a magazine or newspaper article, a >> blog entry, a user-submitted comment, an interactive widget or gadget, or >> any other independent item of content." ( >> http://html5doctor.com/the-article-element/) >> >> I thought this is appropriate since the entire "main content" is the self >> contained part of the page that can be independent of the other parts (like >> menu, asides, sidebars etc.) >> The use of section I thought is appropriate because each gadgets is in a >> way a section/part of the overall article, and of the sidebar. >> > >> > "The section element represents a generic document or application >> section" (http://html5doctor.com/the-section-element/) >> >> These are just my thoughts on the components of a webpage of xwiki, >> however. Do you think this is not the correct interpretation of the xwiki >> parts? >> >> Thanks for looking into the code! >> Jonathan Solichin >> > >

1 0

[xwiki-devs] [Proposal] Additional properties for xwiki.properties in configuration resource template
by Jerome Velociter 10 Jul '12

10 Jul '12

Hi devs, For adding additional configuration keys at build time to xwiki.cfg, we have the $xwikiCfgAdditionalProperties velocity variable available. I would like to propose the equivalent for xwiki.properties : $xwikiPropertiesAdditionalProperties WDYT ? My +1 Jerome -- Jérôme Velociter Winesquare http://www.winesquare.net/

5 4

[xwiki-devs] [GSOC] [REMINDER] Mid-term evaluation deadline
by Eduard Moraru 09 Jul '12

09 Jul '12

Hello GSoC students and mentors, I would like to remind you that this week (9-13 July) is the mid-term evaluation where it is decided if the student is on track and if (s)he should pass or fail. The deadline [1] is 19:00 UTC on 13 July. = Students = 1. Please make sure that your project's page [2] is updated and that the *progress* field contains an up to date description of your current progress/status/etc. This is important for those that did not follow your evolution closely and it is also useful for you to better manage your work/time. It might also contribute to your evaluation, so please do not neglect it. 2. Please make sure that you fill in the mid-term evaluation form on Google's melange [3]. Google is being pretty strict about it this year, so make sure you don`t forget to do it before the deadline. = Mentors = 1. Please make sure that you evaluate your student's current work on Google's melange [3]. I hope you`ve enjoyed the first part of GSoC at XWiki. Hope to see you for the second one with shiny and successful projects ;) Thanks, Eduard ---------- [1] http://www.google-melange.com/gsoc/events/google/gsoc2012 [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HSelectedPro… [3] http://www.google-melange.com

1 0

[xwiki-devs] [GSoc] XWiki Android
by sasinda rukshan 09 Jul '12

09 Jul '12

Hi, I updated the documentation for XWiki Android project at, http://dev.xwiki.org/xwiki/bin/view/Design/XWikiAndroid. Sorry for the little formatting errors. Thanks Sasinda.

2 6

[xwiki-devs] [Proposal] Adding JS behaviors to dynamically inserted HTML
by Sergiu Dumitriu 09 Jul '12

09 Jul '12

Hi devs, Short story: Whenever adding new HTML content to the document, like loading the content of a modal popup, or refreshing the Activity stream, an 'xwiki:dom:updated' event should be fired, sending the list of added elements in the even memo. All standard behaviors should also monitor these events and enhance the newly inserted HTML content, for example adding support for the suggestDocuments, withTip or maximizable behavior classnames. Long story: One of the good features of XWiki is that we have the notion of "behavior classnames", CSS class names that attach a certain behavior to the affected element. This usually works by looking for such elements when the DOM is loaded ('xwiki:dom:loaded' event) and enhancing them with the requested behavior. The problem is that this behavior isn't automatically added for elements inserted in the DOM after the initial xwiki:dom:loaded event, which means that the code that inserted those new elements in the DOM tree must also take extra steps to add the desired behavior, usually with copy/paste, firing custom events or by re-sending the xwiki:dom:loaded event (which is wrong). I'd like to propose a new standard, the 'xwiki:dom:updated' event. This works in two ways: 1. All the code that inserts new elements will fire such an event, sending the list of new HTML elements in the 'elements' field of the event memo. For example: > document.fire('xwiki:dom:udated', {'elements': [dialog.dialogBox._x_contentPlug]}); The 'elements' field must always be a list, even if only one root element is inserted, so that adding a set of items (<li> or <tr> elements, for example) is well supported. 2. All code that adds behavior to classnames must also listen to this event and enhance the sub-elements that have been inserted. For example: > document.observe('xwiki:dom:udated', function(event) { > event.memo.elements.each(function(element) { > $(element).select('input.withTip').each(function(input) { > input.observe... > }); > }); > }); I wonder if we should also list the removed elements. In general this would be needed to cleanup resources, but as far as I know Prototype can take care of its own cleanup, without any manual steps needed. -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 3

[xwiki-devs] Change to the commons test framework for Mocking Component Test Cases
by Vincent Massol 09 Jul '12

09 Jul '12

Hi devs, Over the weekend I've brought one change to xwiki-commons-test. Now by default when you write a unit test that extends AbstractMockingComponentTestCase there will be no component registered against the component manager except those mocked automatically by the @MockingRequirement annotation. This has 2 advantages: * This is the spirit of AbstractMockingComponentTestCase since they're supposed to mock all dependencies and define their behaviors * It makes the tests up to 10 times faster If you really need to register some components, use the {@link ComponentList} annotation and if you really really need to register all components (it takes time) then use {@link AllComponents}. Thanks -Vincent

3 5