June 2012 - xwiki-devs@xwiki.org

[xwiki-devs] Current document vs. current wiki
by Marius Dumitru Florea 08 Jun '12

08 Jun '12

Hi devs, Following Anca's comments on http://jira.xwiki.org/browse/XWIKI-6058 I realized that the current document and the current wiki (database) are completely independent: you can have "someWiki" as the current wiki (context.setDatabase("someWiki")) and otherWiki:Space.Page as the current document (document.setAsContextDoc(context)). This means that it's not enough to set the current document if you want relative references to be resolved relative to that document. You also need to set the current wiki, Is this the desired behaviour? Should setAsContextDoc also set the current wiki? WDYT? Thanks, Marius

2 1

[xwiki-devs] [UX][Idea] Render Switches
by Ecaterina Moraru (Valica) 08 Jun '12

08 Jun '12

Hi, One of the big problems for simple users when trying to use XWiki is the mix we have between text content and syntax/code content. If the user wants to edit the title of the WebHome he will see "$msg.get('xe.home.title')". Same happens for other use cases, like editing the title of the 'Welcome' gadget, etc. This is an idea for having a switch for rendered/syntax content for inputs: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/RenderSwitches… Read the full proposal at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RenderSwitches Thanks, Caty

4 5

[xwiki-devs] New Maven Copy plugin usage
by Vincent Massol 08 Jun '12

08 Jun '12

Hi devs, Just a quick mail to let you know I've started using the Maven Copy plugin (http://evgeny-goldin.com/wiki/Copy-maven-plugin) ATM it's used only in the generic installer module: https://github.com/xwiki/xwiki-enterprise/blob/master/xwiki-enterprise-inst… It's very nice. At some point we'll need to decide if we wish to use it more throughout our build. It completely replaces the Assembly plugin, the Dependency plugin and the Remote Resources one. Thanks -Vincent

2 4

[xwiki-devs] [Release] 4.1-rc-1 is now in staging, testers wanted.
by Caleb James DeLisle 08 Jun '12

08 Jun '12

3 4

[xwiki-devs] [PROPOSAL] Release process/dates for 4.1-rc-1
by Caleb James DeLisle 08 Jun '12

08 Jun '12

In order to try meet a release date, I would like to use the process as documented here: http://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans#H4.1RC1 Synopsis: June 4th: * send 2 day warning mail, ask if anyone needs to block the release. * branch stable-4.1.x to allow 4.2 development to continue. June 6th: * build staged release. * send out call for testing. * do release on jira with release post-dated to the 11th. June 11th: * release from staging. * publish release. I know this is a tight schedule but realistically we need 2 days for warning/stabilization and 2 (working) days for testing. WDYT? Caleb

4 5

[xwiki-devs] [VOTE] Remove the ancient wikiwiki rendering engine from the platform
by Sergiu Dumitriu 07 Jun '12

07 Jun '12

Hi devs, Most of the devs know about the new xwiki-rendering engine which provides the support for the new xwiki/2.x syntaxes, and the old Radeox-based rendering engine which provides support for the xwiki/1.0 syntax, but I wonder who knows about the Oro-based wikiwiki engine that provides support for an even older undocumented wiki syntax? That one has been in the oldcore sources before I came in contact with XWiki, and it has been disabled for a very long time. One thing that we still use from that basic rendering engine is the support for {pre}{/pre} code escaping, and that one will have to be preserved even if we remove all the rest. The advantages of removing it include: - less ancient, unused, buggy code -- thus slightly less PermGen memory required and faster startup - one less Oro dependency (a long term goal is to remove Oro and ECS from our dependencies) - fewer WTFs from people stumbling over that code Does anybody know of any users of that syntax? Is anybody still running 0.1.x versions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

8 11

[xwiki-devs] tab character displays null in xwiki syntax 1.0
by Paul Libbrecht 06 Jun '12

06 Jun '12

Hello fellow developers, it occurred to us that using a number followed by a dot then a tab character actually renders with a nested list and the word "null" is displayed. Is this something known? I could not find this on the bug base, we have opened: http://jira.xwiki.org/browse/CURRIKI-5815 I'm fearing, as anything syntax 1.0 that fixing that is going to be quite delicate. thanks for hints. Paul

3 2

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 06 Jun '12

06 Jun '12

Hi Jerome & Community, Here is the design page for the Responsive Skin [1]. * I'd like we start with a phase of "paper" design (I mean with gimp > or photoshop or whatever tool to produce images). This is available in the design page, or, alternatively phone [2], tablet [3], desktop [4] * I think we should limit the feature set of the skin ; not trying to > do everything right away (there are potentially a lot of features to > work on, from livetables to data editors, to applications, etc.) * For a start, focus should be given on content and navigation. With a > mobile-first approach, expanding up to large-screens desktop. * I think it's OK to have semantic break points (like "phone", > "tablet", etc.) as long as the skin is actually responsive and adapt > to whatever real estate is available. We should be able to "drag the > corner" of a browser window and have the skin display well at all > sizes. Agreed. Also, current questions (c&p) from other e-mail regarding gsoc: 1. Specific support for non-javascript capable browser? I feel like it is not necessarily since browser which can not support javascript will fall back by itself. More over, it would not be capable of carrying out media-queries required for responsive design and some XWIKI features (such as live tables?) anyway. 2. Is the community ok with trying to use "true (html)" drop downs / forms in order to fully utilize functions built in to phone/tablets [5]? 3. Pressable Links: should they be bigger on mobile to help facilitate touching on words, or would it be better to use a "background" to create a "touch area"? Both are in the phone mock up [6]. Former demonstrated in quicklinks, latter in the "Spaces" section. [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin [2] http://jssolichin.com/public/mobile.jpg [3] http://jssolichin.com/public/tablet.jpg [4] http://jssolichin.com/public/desktop.jpg [5] http://css-tricks.com/convert-menu-to-dropdown/ [6] http://jssolichin.com/public/mobile.jpg

3 3

[xwiki-devs] [GSoc] XDroid Platform
by sasinda rukshan 06 Jun '12

06 Jun '12

Hi all, I am starting this thread for my XWiki Android Platform Project. Please check whether following are OK. [1] INFO I tried to start my new modules with the de.akquinet.android.archetypes: android-quickstart:1.0.8. (added eclipse plugins m2e, m2e-android[a.k.a *Android Configurator* ]). But this seems buggy in eclipse. Any way the earlier project has not followed the above archtype either. So I am going to write pom.xml manually for my each module. [2] ADVICE NEEDED xwiki-rest-model module contains 2 submodules |-- xwiki-rest-model-gson ( gson should be corrected to json) |-- xwiki-rest-model-simplexml I think the xwiki-rest-model-gson is redundant. The classes in xwiki-rest-model-simplexml is added with simple xml annotations, otherwise both modules have same classes. There is no problem with the added annotations for using the same model objects for Json REST web services. And I intend to add my JPA (ORMLite library for persistence) annotations on top of it. Shall I re-factor them to a single module xwiki-rest-model. [3] INFO I had to change some pom.xml s. As the current project at: https://github.com/xwiki-contrib/android-client.git does not build. Error with parent pom.xml coordinates. Thank you Best Regards. Sasinda Rukshan

4 10

[xwiki-devs] Choosing the default component implementation [take 2]
by Sergiu Dumitriu 06 Jun '12

06 Jun '12

Hi devs, Hmm, time flies, I realized that it's been a month and a half since I started this thread, but didn't get to counter-argument so far. Because I wanted to give more compelling reasons after I wrote the initial draft of the original proposal, I got slammed with counter arguments centering mostly on why our current implementation already allows to work around the technical difficulties that I presented, although those technical difficulties were just extra arguments that weren't actually that important. Let's start from scratch. I believe that using "default" as a component hint is in most cases wrong, since it doesn't actually say anything about the particular implementation. Let's take some examples: EntityReferenceSerializer, with its many implementations: - "compact", which creates compact representations that don't repeat the parts that are the same as the current document - "compactwiki" that only skips the wiki part when not needed - "path" which creates references usable as a path on the filesystem or in URLs - "uid" which creates non-ambiguous representations - and "default", which does a... default representation... whatever that means... So, while the meaning of the other hints can be guessed from their name, that's not true for "default". WikiModel, with its only implementation, XWikiWikiModel, labeled as "default". First, this "default" is defined in xwiki-platform instead of xwiki-rendering, like the components that actually use that component, which means that we're defining a component interface without any implementation in our "standalone rendering engine", and thus we're using "exceptions as normal decision code" which is wrong. Second, this "default" actually means "xwiki default". Why can't the hint be "xwiki" instead of "default", since that what that implementation is actually doing: "this is the model used in XWiki", and not "this is the default model that most wiki engines use". When looking up an instance of the WikiModel component, we don't request "the default wiki model", but "the wiki model currently in use, whichever that is". ConfigurationSource and its implementations: - "space" which looks into space preferences - "wiki" which looks into wiki preferences - "user" which looks at user preferences - "xwikiproperties" which looks in xwiki.properties - "all" which looks into all the above - "void" which is always empty - "memory" which stores settings explicitly set by code - and "default" which does... stuff... let me get back at you after I look into its code to check what it actually does. XHTMLLinkTypeRenderer is an example where "default" does make sense, since we have special treatment for "doc"ument, "attach"ment, "mailto", "unc", "interwiki", and then there's a "default" that handles all the others, like "url" and "path". I was writing a component called UploadedFileManager, which is supposed to parse uploaded files from a request, and the implementation for it was called CommonsFileUploadManager, since it used the Apache commons-fileupload library for the actual request parsing. I don't think that calling it "default" is appropriate, since in the 3.0 servlet specification the upload behavior is embedded in the specification, in the ServletRequest interface, and that seems more "default" than using a particular library to do the job. A more appropriate hint is "commons", since that's what it actually does: "this implementation handles file uploads by using the apache commons library that does that", and not "this implementation handles file upload in the default way, which everyone should know what it actually is". So, I strongly feel that what the component manager returns when looking up a component without a hint shouldn't be the implementation labeled "default", but one of the existing implementations, as configured somehow. I'm not yet sure how that configuration takes place, that would be the subject of another discussion, but I'd like to get a consensus on whether we need this change or not. -- Sergiu Dumitriu http://purl.org/net/sergiu/

4 6