xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [VOTE] Allow to filter query result lists with QueryFilter (new API)

by Jean-Vincent Drean

Hi, I'd like to introduce a new API in QueryFilter: ====================8<==================== /** * Filter a list of query results. The result list can be returned without modification. * * @param results the original result list. * @param <T> expected type of elements in the result list. * @return a filtered result list. */ <T> List<T> filterResults(List<T> results); ====================8<==================== In addition to QueryFilter#filterStatement(), this method would be called from the QueryExecutor and it would allow the filter to mofidy the result list of a query. We talked about this one before with Thomas and Vincent but the use case we were thinking about wasn't achievable (permission checking) because of performance issues. Now I need this method to fix an issue with the "unique" (distinct) filter. When using "unique", a HSQLDB limitation [1] forces us to put the columns present in the "order by" clause in the "select" clause. This currently causes a lot of queries to fail when using the "unique" filter. The fix consists to add the columns from the "order by" clause in the "select" clause and then to remove the added columns from the query results. I think this new API fits well in the QueryResult interface, here's my +1. [1] This is considered invalid when backed by HSQLDB (and Oracle AFAIK): "select distinct doc.fullName from XWikiDocument order by doc.language" The reason is that the order can't be undoubtedly determined, for example with the following data: XWD_FULLNAME, XWD_LANGUAGE Main.Page1, de Main.Page1, fr Main.Page2, en Main.Page2, it -- Jean-Vincent Drean, XWiki.

12 years, 8 months

Re: [xwiki-devs] JSON Velocity Tool (Reloaded)

by Marius Dumitru Florea

On Fri, May 4, 2012 at 1:32 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote: > Hello Marius, > > What has been the final decision here? > I'm about to need an upgrade to JSON-lib used in Curriki because that library doesn't stream the json objects out... so I'd better use the same library. Was Jackson used? JSON.simple? > In the xwiki-4.0 download, I only see json-lib 2.4. As you can see from https://github.com/xwiki/xwiki-commons/commit/ac22d47d0f826c93b019d9a7f6fe1… I've used json-lib in the end but the JSONTool API (method signatures) is not bound to any JSON implementation so we could change the JSON library later. Hope this helps, Marius > > thanks in advance > > Paul > > Le 14 mars 2012 à 13:14, Marius Dumitru Florea a écrit : > >> On Wed, Mar 14, 2012 at 12:26 PM, Guillaume Delhumeau >> <gdelhumeau(a)xwiki.com> wrote: >>> Hi. >>> >>> Can't you add a parser function too ? >> >> A parser function needs to return an object: >> >> * either the JSON object from some JSON library, but that means >> binding the Velocity tool to a specific JSON library and I tried to >> avoid this for the moment until we reach an agreement regarding the >> JSON library to use >> * a wrapper for the JSON object from some JSON library to hide the >> JSON implementation, but that's a lot of work and I don't have time >> for it right now >> * a Java object, but for this you need a JSON-Java mapping, which is >> specific to the JSON library used and it requires some work to make a >> generic binding method >> >>> >>> Right now, we have to use groovy for JSON parsing. It would be better to >>> have it in velocity directly, don't you think ? >> >> Yes, but I don't have time for it right now. >> >> Thanks, >> Marius >> >>> >>> Thanks, >>> >>> Guillaume >>> >>> 2012/3/14 Andreas Jonsson <aj(a)member.fsf.org> >>> >>>> +1 >>>> >>>> 2012-03-14 09:08, Marius Dumitru Florea skrev: >>>>> Hi devs, >>>>> >>>>> Following the discussion on >>>>> http://lists.xwiki.org/pipermail/devs/2012-March/049889.html I'd like >>>>> to add a JSON Velocity tool that has (for now) just one method: >>>>> >>>>> /** >>>>> * Serialize a Java object to the JSON format. >>>>> * <p> >>>>> * Examples: >>>>> * <ul> >>>>> * <li>numbers and boolean values: 23, 13.5, true, false</li> >>>>> * <li>strings: "one\"two'three" (quotes included)</li> >>>>> * <li>arrays and collections: [1, 2, 3]</li> >>>>> * <li>maps: {"number": 23, "boolean": false, "string": "value"}</li> >>>>> * <li>beans: {"enabled": true, "name": "XWiki"} for a bean that has >>>>> #isEnabled() and #getName() getters</li> >>>>> * </ul> >>>>> * >>>>> * @param object the object to be serialized to the JSON format >>>>> * @return the JSON-verified string representation of the given object >>>>> */ >>>>> public String serialize(Object object) >>>>> >>>>> This method is able to do what both of the initially proposed methods >>>>> were able and it doesn't expose the JSON library used (so that we can >>>>> change it later if we want). I'll use json-lib for the initial >>>>> implementation and we can move to Jackson or other JSON library later. >>>>> >>>>> WDYT? I'd like to commit this ASAP. >>>>> >>>>> Thanks, >>>>> Marius >>>>> _______________________________________________ >>>>> devs mailing list >>>>> devs(a)xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> . >>>>> >>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >

12 years, 8 months

[xwiki-devs] [GSoC] Responsive Skin

by Jerome Velociter

Hi Jonathan, everybody, As you may know the "Responsive Skin" project has been accepted for the GSoC 2012. I will be mentoring the project, together with Ecaterina and everyone that wants to get involved. Jonathan Solichin is the student who will realize the project. Jonathan, I'd like you start telling us about your plans and an expected timeline proposal for the realization of the project. Then the next step is to create a page on the design page in the development wiki [1] and start the work here. I'll lay here some of my thoughts on the project, and what I personally consider conditions for success (for the moment) : * I'd like we start with a phase of "paper" design (I mean with gimp or photoshop or whatever tool to produce images). * 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. Of course all those points are open for discussion, those are just my views on the topic. Feedback from the community welcomed. Jonathan, looking forward hearing from you, Cheers, Jerome [1] http://dev.xwiki.org/xwiki/bin/view/Design/WebHome

12 years, 8 months

[xwiki-devs] [GSOC] Welcoming our GSoC students

by Eduard Moraru

Hello community, Hello Google Summer of Code students, First of all, congratulations on your applications and your activity during the selection period, and welcome in the XWiki development team. Before guiding the accepted students to their next steps, we'd like to thank again all those who showed interest in XWiki for this Summer of Code. We had a lot of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose only 3. Unfortunately, some very good students, with great potential, were not accepted. So, to those interested in getting involved anyway, without Google's implication, I renew the invitation to put your ideas in practice under the guidance of the community. Even though the money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, etc [1]. If you would like to do that, please let us know by replying to this mail. For the accepted students, here are some getting started hints: = Community bonding period = According to the program timeline [2], the next month (until - May 21st) is to be used for community bonding. The first thing to do, sometime this week, is to present yourself and your project on the dev list, so that everyone knows who you are and what to expect from you (a precondition is to be subscribed to the list, which you *need to do ASAP* if you haven't already). Also, you should continue getting acquainted with the code, the practices and the developers. Please make sure you all read and understand the following - very useful - documents: - [3] http://purl.org/xwiki/community/ - [4] http://purl.org/xwiki/dev/ - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC, while the design decisions, important progress announcements and testing/feedback requests go on the list. This way, the community is informed on the evolution of your project, and other developers can come up any time with useful ideas and suggestions. Moreover, if your mentor is hit by a bus (the bus factor [6]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a bad approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid wasting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to subscribe to the users list, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [7] We invite you to adopt a test driven development [8][9][10] approach and to experience agile development [11]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). Since our code is now hosted on GitHub [12], you should register an account there and fork some xwiki repositories, so that you can try to build XWiki from sources, and be able to contribute bugfixes. We'll add you to the xwiki-contrib organization [13], and we'll create dedicated repositories for each project. We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. A simple way of having something functional in the first week is to prepare the maven build for your modules, which will give you the first unit test for the first class. = Next steps, in a nutshell = - Get more familiar with the code and development process and try to master Maven, JUnit, Selenium, component driven development, ... - Continue fixing a few small issues, chosen so that they are __related to your project__. You can ask on IRC for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues [14] -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (you can use the Drafts space [15]), and write several use case scenarios. - Start writing the first piece of code for your project. At the end of the community bonding period, you should have a clear vision of the project, well documented on the xwiki.org wiki, you should have the build infrastructure ready, and you should be pretty familiar with the existing code you will need to interact with. And, of course, you should be familiar with the community and the way we communicate. Good luck, and may we all have a great Summer of Code! -The XWiki Development Team ---------- [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ [2] http://www.google-melange.com/gsoc/events/google/gsoc2012 [3] http://purl.org/xwiki/community/ [4] http://purl.org/xwiki/dev/ [5] http://platform.xwiki.org/xwiki/bin/view/Features/ [6] http://en.wikipedia.org/wiki/Bus_factor [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [8] http://en.wikipedia.org/wiki/Test-driven_development [9] http://www.amazon.com/dp/0321146530/ [10] http://www.amazon.com/dp/0201485672/ [11] http://www.amazon.com/dp/0596527675/ [12] https://github.com/xwiki/ [13] https://github.com/xwiki-contrib/ [14] http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1… [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/

12 years, 8 months

[xwiki-devs] Pull requests

by Fabio Mancinelli

Hi everybody, I've stumbled upon this interesting blog post from the GitHub team where they explain how they use pull requests to build GitHub (https://github.com/blog/1124-how-we-use-pull-requests-to-build-github) I think this is not exactly the meaning we give to pull requests that, AFAIU, are open only when the feature is complete and is asked to be merged. What I've found interesting in the article was the first point: "Open a Pull Request as early as possible". Which is something surprising to me. Basically they are using pull requests as we use mailing list discussions. Which is very interesting and, maybe, more effective (because you have the actual code inlined). The only downside is the traceability and indexability of the discussions. Are comments easily exportable from GitHub (i.e. retrieving all the comments that have been made on a project during all its lifetime) ? A sort of "data liberation" à la Google. My 2 cents, Fabio

12 years, 8 months

[xwiki-devs] [VOTE] Allow anyone to use org.xwiki.query.Query#setWiki

by Thomas Mortagne

Hi devs, When Query Manager as been introduced by Artem I suggested to add a setWiki to make easier to execute request on another wiki. For me it was supposed to be usable by anyone and I discovered recently that it was allowed only when the user has programming right. Since I really don't see the point I propose to remove this check. * all the users without programming right can do is to list documents names so it's not very dangerous * api;XWiki#searchDocumentsNames(String wikiName, String parameterizedWhereClause, int maxResults, int startOffset, List< ? > parameterValues) does not have any check so what the query manager prevent is doable anyway WDYT ? Here is my +1. -- Thomas Mortagne

12 years, 8 months

[xwiki-devs] [PROPOSAL] Use relative URLs instead of external URLs with sendRedirect

by Thomas Mortagne

Hi devs, In HTTP specifications a redirect is always absolute URL which is probably why we use absolute URL with sendRedirect. However sendRedirect does not produce direct HTTP response but allows relative URL and delegate to the application server the job of producing proper absolute URL. IMO XWiki should always use relative URL everywhere it can so I propose to change our practice to use relative URL instead of absolute URL with HttpSevletResponse#sendRedirect when possible. The only reasons I see to use external URLs are: * interwiki URL in a domain based multiwiki * html/pdf export for links pointing on not exported pages or non view actions WDYT ? Here is my +1. We very often fix bugs in the way to produce external URL and it's still not OK (see http://jira.xwiki.org/browse/XWIKI-7632) so lets reduce the scope for this need as much as possible. -- Thomas Mortagne

12 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-enterprise] 6e0258: [misc] Display hidden documents for Admin user bec...

by Vincent Massol

Hi Marius, On May 2, 2012, at 7:10 PM, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-enterprise > Commit: 6e0258a75e0e666db2f48672bcdb41bbefe0b717 > https://github.com/xwiki/xwiki-enterprise/commit/6e0258a75e0e666db2f48672bc… > Author: Marius Dumitru Florea <marius(a)xwiki.com> > Date: 2012-05-02 (Wed, 02 May 2012) > > Changed paths: > M xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > > Log Message: > ----------- > [misc] Display hidden documents for Admin user because various WYSIWYG tests use hidden documents. > > > diff --git a/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java b/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > index 690daf1..97689c4 100644 > --- a/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > +++ b/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > @@ -55,6 +55,9 @@ protected void setUp() throws Exception > return; > } > > + // Make sure the hidden documents are displayed to the Admin user. > + displayHiddenDocumentsForAdmin(firstXWikiTest); > + > // Set up the WYSIWYG tests using the first WYSIWYG Test case for Selenium and skin executor API. > enableAllEditingFeatures(firstXWikiTest); > } > @@ -82,14 +85,28 @@ private AbstractWysiwygTestCase getFirstWysiwygTest(Test test) > } > > /** > + * Sets the Admin user preference to display the hidden documents. > + * > + * @param helperTest helper {@link AbstractWysiwygTestCase} instance whose API to use to do the setup > + */ > + private void displayHiddenDocumentsForAdmin(AbstractWysiwygTestCase helperTest) > + { > + helperTest.loginAsAdmin(); > + helperTest.open("XWiki", "Admin", "edit", "editor=object"); > + String propertyId = "XWiki.XWikiUsers_0_displayHiddenDocuments"; > + if (!"1".equals(helperTest.getSelenium().getSelectedValue(propertyId))) { > + helperTest.setFieldValue(propertyId, "1"); > + helperTest.clickEditSaveAndContinue(); > + } > + } Shouldn't this API be added to the UserProfile PageObject instead? Thanks -Vincent

12 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-commons] 6ecb13: XCOMMONS-162: Add start and end data to job status

by Vincent Massol

Hi Thomas, On May 2, 2012, at 6:48 PM, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-commons > Commit: 6ecb131081233764ed773eb84f9be34e23edb888 > https://github.com/xwiki/xwiki-commons/commit/6ecb131081233764ed773eb84f9be… > Author: tmortagne <thomas.mortagne(a)gmail.com> > Date: 2012-05-02 (Wed, 02 May 2012) > > Changed paths: > M xwiki-commons-core/pom.xml > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/AbstractJob.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/Job.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/JobManager.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/event/status/JobStatus.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobManager.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobStatus.java > > Log Message: > ----------- > XCOMMONS-162: Add start and end data to job status > XCOMMONS-163: Add join method to Job > > > diff --git a/xwiki-commons-core/pom.xml b/xwiki-commons-core/pom.xml > index 799f042..2251f94 100644 > --- a/xwiki-commons-core/pom.xml > +++ b/xwiki-commons-core/pom.xml > @@ -115,6 +115,8 @@ > <exclude>**/internal/**</exclude> > <exclude>**/test/**</exclude> >  > + <exclude>org/xwiki/job/Job</exclude>  > + <exclude>org/xwiki/job/event/status/JobStatus</exclude>  This goes against the deprecation/legacy strategy we have voted since we said we will not add *any* breakage. It's not allowed anymore to have any exceptions in CLIRR. (See http://markmail.org/message/tino4ngttflc5i3s). So you need to go through a deprecation strategy and move this to legacy. Alternatively you should make a new proposal to amend our backward-compatibility strategy for "young" apis. I'll start the thread for you but in the meantime all Release Manager need to be very careful to not perform new releases when there are CLIRR excludes since it means we have broken backward compatibility. Thanks -Vincent

12 years, 8 months

[xwiki-devs] [Brainstorm] What do we do with the AutoTag plugin?

by Vincent Massol

Hi devs, Sergiu has extracted the AutoTag plugin from oldcore in its own module. That's cool. However he's also marked it @deprecated while doing so. And he's stopped bundling it in XE. This raises several question: 1) Do we consider that what the plugin does it not useful? Because if we consider it's useful we might not want to deprecate it without offering an alternative. It's not because a technology is deprecated that we should deprecate stuff using that technology. Deprecated means: don't use this, instead use that. BTW it should be our rule that when we add the @deprecated tag we also mention what to use instead. 2) If we consider it's not useful anymore. We have 2 choices: 2a) Move it in legacy modules 2b) Move it to retired/contrib My opinion: * It could be useful but I'm not sure the XWiki Dev team wants to support it. IMO it should not be deprecated since it can still be useful and there's no replacement for it. * Since I don't think the XWiki Dev Team should support it, I'd move it to xwiki-contrib/retired and publish it on e.x.o. for users who want to still use it. * Since this is breaking our new rule regarding deprecations/legacy it requires a VOTE to move it to contrib/retired. It also needs to be clearly mentioned in the Release Notes as a breakage and explain how user can add it back to their wikis. Let me know what you think and I'll send a VOTE if you agree with what I said above. Thanks -Vincent

12 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs