July 2012 - xwiki-devs@xwiki.org

[xwiki-devs] [Brainstorming] Colocated Functional Test (CFT)
by Vincent Massol 22 Nov '12

22 Nov '12

Hi devs, I've started an experiment to have colocated functional tests (CFT), which means having the functional tests located where the functional domain sources are located instead of in XE. For example for the linkchecker module we have the following directories: xwiki-platform-linkchecker/ |_ xwiki-platform-linkchecker-refresher (JAR) |_ xwiki-platform-linkchecker-ui (XAR) |_ xwiki-platform-linkchecker-tests (functional tests) The rationale for this was: * Have everything about a functional domain self-contained (source and all tests) * Making it easy to run only tests for a given functional domain * Move page objects to the functional domain too Here are some findings about this experiment: A - It takes about 30 seconds to generate the adhoc packaging and start XWiki. This would be done for each module having functional tests compared to only once if all tests were executed in XE B- The package mojo created to generate a full packaging is quite nice and I plan to reuse it in lots of other places in our build (distributions, database, places where we need XWiki configuration files) C- We will not be able to run platform builds in Maven multithreaded mode since it would mean that several XWiki instance could be started at the same time on the same port D- The colocated functional test module Solutions/ideas: * One idea to overcome A and C would to have the following setup: ** Keep functional test modules colocated but have them generate a test JAR ** Still allow running functional tests from the colocated module (this makes it easy to verify no regression was introduced when making changes to a given domain) ** Have functional tests in XE depend on the colocated functional test module JARs and configure Jenkins to run all functional tests from XE only * Another solution to overcome C is to auto-discover the port to use in our XWiki startup script (and save it in a file so that the stop script can use it). I think the first proposal is the best one and brings the best of the 2 worlds. WDYT? Thanks -Vincent

4 10

Re: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
by Denis Gervalle 14 Nov '12

14 Nov '12

Le 9 mars 2012 16:59, "Vincent Massol" <vincent(a)massol.net> a écrit : > > > On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote: > > > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <vincent(a)massol.net> wrote: > > > >> Hi, > >> > >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote: > >> > >>> Hi devs, > >>> > >>> Since I plan to move some stuff from platform to commons I would like > >>> to know what you think of the history in this case. > >>> > >>> Pros including history: > >>> * can access easily the whole history of a moved file. > >> > > > > This is really an important matter, especially for those joining the > > project. When you follow XWiki from "outside", and not in a continuous > > manner, the history is of great value to understand why stuffs are like > > they are, and what you may do, or not when moving forward. > > The history is not lost. If you do a join (all active repos) you still have it. I do not know what you means by joining all repos, but I would be surprise to see the IDE find its way between them. I even wonder how it could be possible. > > >> But sometimes > >>> changing packages etc make too much difference for git to see it's > >>> actually the same file so you loose it anyway. > >> > > > > If you simply change the package name, and nothing else, it is really > > unlikely to happen. > > > > > >>> > >>> Cons including history: > >>> * double the history which make tools like ohloh indicate wrong > >> informations > >> > > > > Sure, the stats will be broken, but what is the matter. This is not > > cheating, just a misfeature in Ohloh, since the commit are just identical, > > something they may notice. IMO, this is the matter of the statistical tools > > to improve that. > > Can you tell me how to implement this because right now my GitHub tool doesn't do that and I don't know how to do it? If I had to implement it, I will probably use some hashing method to be able to recognize similar commits, since there effectively no link between them. But my main remarks that the statistics are broken, not the way we use git. > > >>> * it's a lot easier to move without history > >> > > > > There should be some tools to improve that point or we may write one, once > > for all. So this is not a real cons either. > > It's really hard to copy history in Git. It's almost impossible to do it right. You have to remember the full history and it's just too hard. I would be really disappointed to have to conclude that. There is probably some edge cases, but most of the time there is clever work around. You have to talk to Sergiu :-) > > >>> WDYT ? > >>> > >>> Even if it was looking a bit weird to me at first I'm actually +1 to > >>> not move the history in this case. > >> > >> +1, FTR I'd be -0, close to -1 to move it. If/when the source repository > >> is removed for one reason or another, then we might want to import its > >> history somewhere. > >> > > > > Seems we are really opposite on this one, since I am close to -1 to not > > move it. > > Sorry but that's the current practice :) It's also the easiest one. Until we have Git, there were no better way. This does not means that we should not improve our practice. By the way, it was not my thread, if Thomas has asked, it means that the current practice was not so current. > > > Statistics is really less valuable IMO, it is a small interest compare to > > code history, that I have use a lot, especially when I have join the > > project and follow sparingly. > > I can say exactly the same thing as you said above. It's just a question of tools since the history is not lost. It's still there in our active repos. There is absolutely no link between these histories. It is not only a question of tools. Moreover, requiring querying all active repositories to have a proper history completely defeat the purpose of having separate repositories. I do not see the comparison with my remark above. Git has been made for versionning, not for statistics, it is not my fault. > > > So the general rule for me is: Copy history when the source repository is > >> removed/deleted/not used anymore. > > How many times have you done this? I believe 0 times since I don't think you'd be so much in favor if you had tried it. I suggest you try it a few times on your own projects first :) It's really hard to do it right and very time consuming. When I have copied the security component from contrib, I have done so. I hope that I am not alone. And, frankly, it was not so hard, compare to the advantage you have. > > > You never know what will happen to a repository in the future, so this > > rules is somewhat a hope on the future, no more. And remembering that we > > may loose history if we do some change in the old repository, is for me > > like hoping you will remember my birthday ;) > > I don't agree with this at all. Again we're not loosing history. If a repo is removed then its history is copied I agree about that. I would like to know how you do that after the facts? > > >>> Eduard was proposing to include in the first commit of the new > >>> repository the id of the last commit containing the files (basically > >>> the id of the parent of the commit deleting the files) in the old > >>> repository so that it's easier to find it. I'm +1 for this. > >> > > > > But you loose all the benefits of the IDE tools that brings history of a > > selection automatically and that are really useful. > > A huge majority of xwiki's history is already lost to IDEs (when we moved from SVN) even though the SVN history was moved. Even Git itself doesn't follow the history when you move stuff around. Said differently it's alwasy possible to find the history but the IDE and "standard" tool don't follow it. It does so far better since we move to Git and it is really a valuable tool. Do you means that because in a few case, the history may be broken, that we should not try to have it as complete as possible? > > > Moreover, if the history is rewritten due to a change in structure later, > > the hash may be broken. > > Not sure I understand this one. In Git, nothing is fully permanent, that is all I say. > > You should really measure the cost of what you propose Denis. It's really hard to do. Prove me that is more cost than the one newcommers has to enter the project. Maybe you do not value history so much because you have by your own experience of the project a good knowledge of what happen in the past. When I dig in some code, I always found history valuable to understand why that piece of code is not written the way I may have expected and why I should not got that way. If Thomas conclude it is too hard to be done, and not just some developer's lazyness, I would understand; but I do not agree that it should not be done just because it breaks statistics or we think it is too hard. This is why I suggest a tools that do it once for all. I would be really disappointed of Git if we had to conclude this. Thanks, Denis > > Thanks > -Vincent > > > So having a broken history is hardening the task of those who want to > > participate. A great value compare to the statistics IMO. > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > eGuilde sarl - CTO > > _______________________________________________ > > 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

5 8

[xwiki-devs] [VOTE] REST API Changes not passing CLIRR. Ignore errors
by Ludovic Dubost 19 Oct '12

19 Oct '12

As part of rest improvements to display pretty names of users and other improvements, I'm getting CLIRR errors because of API changes of the model and of public class: 1/ Model CLIRR error because the version field has been moved to PageSummary from Page. Page extends PageSummary. I need the version field also in representations sending back only PageSummaries. Unfortunately CLIRR does not realize that the version field is still there when moved to the super class. I believe it's safe to ignore this error. Howerver I've put ignore all errors on the Page class as I don't have a way to ignore this specific error 2/ CLIRR errors because of parameter additions to objects that are used (I think) only internally by the REST server API. Here are the errors: [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Attachment createAttachment(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Attachment, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Attachment createAttachmentAtVersion(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Attachment, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Comment createComment(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Document, com.xpn.xwiki.api.Object)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.HistorySummary createHistorySummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, java.lang.String, java.lang.String, java.lang.String, java.lang.String, org.suigeneris.jrcs.rcs.Version, java.lang.String, java.util.Date)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Object createObject(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.XWikiContext, com.xpn.xwiki.api.Document, com.xpn.xwiki.objects.BaseObject, boolean)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.ObjectSummary createObjectSummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.XWikiContext, com.xpn.xwiki.api.Document, com.xpn.xwiki.objects.BaseObject, boolean)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Page createPage(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, java.net.URI, com.xpn.xwiki.api.Document, boolean, com.xpn.xwiki.api.XWiki)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.PageSummary createPageSummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Document, com.xpn.xwiki.api.XWiki)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseAttachmentsResource: In method 'protected org.xwiki.rest.model.jaxb.Attachments getAttachmentsForDocument(com.xpn.xwiki.api.Document, int, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List search(java.util.List, java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchObjects(java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchPages(java.util.List, java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchSpaces(java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.ModificationsResource: In method 'public org.xwiki.rest.model.jaxb.History getModifications(java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String, java.lang.Long)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachmentsAtPageVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.attachments.AttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentResource: In method 'public org.xwiki.rest.model.jaxb.Comment getComment(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentVersionResource: In method 'public org.xwiki.rest.model.jaxb.Comment getCommentVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentsResource: In method 'public org.xwiki.rest.model.jaxb.Comments getComments(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentsVersionResource: In method 'public org.xwiki.rest.model.jaxb.Comments getCommentsVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.AllObjectsForClassNameResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Object getObject(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Properties getObjectProperties(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertiesResource: In method 'public org.xwiki.rest.model.jaxb.Properties getObjectProperties(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Property getObjectProperty(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertyResource: In method 'public org.xwiki.rest.model.jaxb.Property getObjectProperty(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectResource: In method 'public org.xwiki.rest.model.jaxb.Object getObject(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsForClassNameResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageChildrenResource: In method 'public org.xwiki.rest.model.jaxb.Pages getPageChildren(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageHistoryResource: In method 'public org.xwiki.rest.model.jaxb.History getPageHistory(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageResource: In method 'public org.xwiki.rest.model.jaxb.Page getPage(java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationHistoryResource: In method 'public org.xwiki.rest.model.jaxb.History getPageTranslationHistory(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageTranslation(java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationVersionResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageTranslationVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PagesResource: In method 'public org.xwiki.rest.model.jaxb.Pages getPages(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.spaces.SpaceAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.spaces.SpaceSearchResource: In method 'public org.xwiki.rest.model.jaxb.SearchResults search(java.lang.String, java.lang.String, java.lang.String, java.util.List, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.tags.PagesForTagsResource: In method 'public org.xwiki.rest.model.jaxb.Pages getTags(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.wikis.WikiAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.wikis.WikiSearchResource: In method 'public org.xwiki.rest.model.jaxb.SearchResults search(java.lang.String, java.lang.String, java.util.List, java.lang.Integer)' the number of arguments has changed Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

6 18

[xwiki-devs] [Proposal] XWiki Days every month?
by Vincent Massol 18 Sep '12

18 Sep '12

Hi devs, We've had several special days in the past: * Deprecation day ** 26 April 2012: http://markmail.org/thread/c5oytyvgw6fcimqq * Bug fixing days: ** 11 june 2008: http://xwiki.markmail.org/thread/oyfxis3umqrvutxm ** 18 June 2008: http://xwiki.markmail.org/thread/brfx6gme37vgr3m5 ** 25 Jun 2008: http://markmail.org/message/nrobo3x4ppgssklk ** July 2008: http://xwiki.markmail.org/thread/mn5veblndbtgcsm5 ** 10 Feb 2011: http://xwiki.markmail.org/thread/rierrb2wk72dkpqy and result http://www.xwiki.org/xwiki/bin/view/Blog/BugFixingDayFebruary2011 * DocHour days: ** 5 March 2008: http://xwiki.markmail.org/thread/dyypju5dn23wkwr2 I think it's a good concept and I'd like to propose that we regularly (once every month?) have an XWiki Day. Ideas for such days: * Bug fixing day: Reduce bug count * Doc day: improve xwiki.org * Deprecation day: reduce # of deprecated calls. Around 1700: http://nemo.sonarsource.org/drilldown/violations/XWIKI?&rule=squid%3ACallTo… * Violation day: reduce # of violations. 10274 right now: http://nemo.sonarsource.org/drilldown/violations/XWIKI * Javadoc Day: Add missing javadocs in our code and remove checkstyle excludes * Code Coverage Day: Add as many tests as possible (unit and functional) * Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them! I propose that whenever a day is over, we send a mail with the Date and Topic for the next day and it has to be about 1 month from the date of the mail. To get this started I volunteer to be responsible for sending Day emails for now, unless someone else is interested to do this. WDYT? Thanks -Vincent

6 9

[xwiki-devs] What applications should we list in the "Applications" panel?
by Ecaterina Moraru (Valica) 10 Sep '12

10 Sep '12

Hi, For the 4.2 Roadmap there are several issues related to accessibility of applications inside the wiki. One of these issues is http://jira.xwiki.org/browse/XWIKI-7927 "Create an entry point for all available applications inside the wiki ". There are multiple ways to represent such a place (panel, special directory, gadget, etc.) but the most easy (not sure how scalable, especially if the user will create lots of spaces using AppWithinMinutes) is to use a panel. The problems remaining are: - If we have a dedicated place to list applications what will remain in the {{Spaces}} gadget on "Dashboard"? What we still consider to be a content space? (Main, XWiki, Sandbox)? http://jira.xwiki.org/browse/XWIKI-7926 or we should still display visible spaces in it? - What we consider to be an application? We list just spaces or even feature pages like "Document Index" or "User Directory"? http://jira.xwiki.org/browse/XWIKI-7925 - What about 'special' spaces like Scheduler, Stats? we let the entry point to be just the Administration (at least for now)? What about Invitation functionality? etc. So I've created a doodle and the question is what space/page do you think we should have in this dedicated "Applications" panel: http://www.doodle.com/uav7triciuf4kxpd You can use the doodle or you could respond in this main if you have other suggestions or observations. Thanks, Caty

4 7

[xwiki-devs] Backup of Xwiki via Command Line
by echocoder 07 Sep '12

07 Sep '12

Is it possible to backup the Xwiki via command line using the export feature? -- View this message in context: http://xwiki.475771.n2.nabble.com/Backup-of-Xwiki-via-Command-Line-tp757998… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 4

[xwiki-devs] [UX][Proposal] Improvements on editing welcome block
by Ecaterina Moraru (Valica) 27 Aug '12

27 Aug '12

Hi, I have received numerous complains that simple users have problems in editing the content and title of the Welcome block ("Welcome to you wiki" gadget) from the homepage. There are multiple factors that influence the editing of that particular gadget and that make the job especially harder for beginners. One of these factors is that the gadget used to display the Welcome content is an "include" gadget. Without some custom actions for the gadget that would let the user navigate to the included page or without some auto-redirect mechanism, the simple users have difficulties in understanding where the welcome content is coming from and what actions they need to do in order to edit that content. Also the "include" macro has a lot of advanced properties that can be scary and confusing for users (context, reference, section, type, etc.). My proposal is to create a new "text" gadget. This gadget will be very-very simple and will contain just the gadget's title and the gadget's content. Its only purpose will be to let users add textual information inside a dashboard. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/EditingWelcomeMess… Right now we have specialized gadgets for HTML content, velocity content, code in general, boxes, success messages, etc. but no way to put just a simple text inside the dashboard. Let me know what you think. Thanks, Caty

5 11

[xwiki-devs] [vote] improvements for the REST api
by Ludovic Dubost 19 Aug '12

19 Aug '12

While working on a prototype on a HTML5 mobile and desktop application I've hit a few limitations of the REST APIs. This is why I propose some enhancements to the current REST APIs to give more flexibility, particularly: Support for start and order parameter in queries returning large list of pages Support order parameter in page list Adding page version, author information and data information when missing Hidden documents filter activation or deactivation in REST APIs Adding pretty display of title and author names Support queries using XWQL, HQL and Lucene The rendered content should be accessible from REST apis The details of the proposal is here: http://dev.xwiki.org/xwiki/bin/view/Design/RESTApiImprovements A pull request for a prototype implementation of these requirements is available here: https://github.com/xwiki/xwiki-platform/pull/56/files#r1040052 Not everything has an implementation (hidden docs and rendered content is not implemented yet). Other are not implementing according to this specification as some comments have already been made. Particularly the following votes are required: VOTE to accept supporting "start" and "order" parameters only on queries having only one unique scope VOTE in search queries for just adding the descendent date order or add more order possibilities using order and orderdir param VOTE in page list queries for just adding the descendent date order or add more order possibilities using order and orderdir param VOTE to add page version and author fields to page and other resources VOTE for adding the additional fields with or without a parameter "pagedetails=1" VOTE for adding a parameter to show/hide hidden documents independent of user setting VOTE to add the displayTitle field with or without the pagedetails=1 parameter or with it's own parameter displayTitle=1 VOTE to add the author display names with or without the displayPrettyNames parameter VOTE for supporting the searchQuery API at the wiki level with multi wiki support at the lucene level VOTE for adding rendered content using the withrenderedcontent=1 param VOTE for having absolute URLs in the rendered content using withabsoluteurls=1 param Thanks Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 7

Re: [xwiki-devs] [GSoC] [Request] Responsive Skin - data for extensive testing/bug finds/feature requests
by Jonathan Solichin 08 Aug '12

08 Aug '12

I think that's a great idea, it would make the skin more extensible. Right now I am exploring creating a xar to create a page where there can be options-- right now for the colors, like you did with the "fluid" option on lyrebird. As I am separating the codes, i am wondering how far i should separate the core? Should i just leave enough css that there is a sidebar, the header, and the main content area? Thank you, Jonathan Solichin On Mon, Jul 30, 2012 at 1:09 PM, Jonathan Solichin <j.s.solichin(a)gmail.com>wrote: > I think that's a great idea, it would make the skin more extensible. Right > now I am exploring creating a xar to create a page where there can be > options-- right now for the colors, like you did with the "fluid" option on > lyrebird. > > As I am separating the codes, i am wondering how far i should separate the > core? Should i just leave enough css that there is a sidebar, the header, > and the main content area? > > Thank you, > Jonathan Solichin > > > On Thu, Jul 26, 2012 at 1:42 AM, Jonathan Solichin <jssolichin(a)gmail.com>wrote: > >> Hi Jerome, >> >> All the advise you mentioned should now be fixed on github. Ajax search >> is now implemented. >> >> I will be working on color themes, while still trying to ensure >> consistency through out XE UI. >> >> Thank you again! >> Jonathan Solichin >> >> >> On Tue, Jul 17, 2012 at 11:50 AM, Jonathan Solichin <jssolichin(a)gmail.com >> > wrote: >> >>> Hello Friends, >>> >>> As you may or may not know, I have been working on a responsive skin for >>> XWiki for GSOC (http://23.21.87.183:8080/xwiki/bin/view/Main/WebHome) >>> As I continue to add further details and refinements into the skin, I would >>> like to kindly ask for your help in doing so. In order to make sure that I >>> did not miss anything and the skin is as complete as possible, I would like >>> to, if possible, request a XAR of an existing wiki (or complex pages) so >>> that I may see the result of implementing the skin on more than the default >>> wiki data. >>> >>> If this is not a possible, I would like to still enlist your help in >>> testing some basic/your favorite functionality/features of xwiki. There are >>> several ways to do this: >>> >>> - By downloading the current skin and testing it on your XWiki: >>> https://github.com/jssolichin/xo5 >>> - By playing around with the live instance (uses default admin >>> user/password): http://23.21.87.183:8080/xwiki/bin/view/Main/WebHome >>> - By letting me know of your favorite applications (so that I may >>> look into implementing them) >>> >>> Anything you want to note is fine. Bug and feature request are both >>> welcome, as I think communal ideas are often better than one. Even if you >>> did not have a chance to play too much with the skin, go ahead and let me >>> know what you think I should check on (based on your experience) and/or >>> give me any suggestions that may have come up while reading this. >>> Technicality permitting, I will check myself. >>> >>> Helping with this process will help make the skin better, and maybe help >>> it to be tailored to your (/type of) wiki and the community surrounding the >>> platform in general. >>> >>> Thank you in advance for your time! >>> Jonathan Solichin >>> >> >> >

3 5

[xwiki-devs] export to pdf: the content is not carried on the next page
by Elena Roman 02 Aug '12

02 Aug '12

Hi, I am developing a script on groovy which compiles a table of content "manually" and then includes the children documents before exporting to PDF. So finally compiled document content looks like " =={{{ }}}[[1. Software Requirements Specification>>#H1.SoftwareRequirementsSpecification-1]]== ==={{{ }}}[[1.1. Use cases>>#H1.1.Usecases-1]]=== ===={{{ }}}[[1.1.1. Bite registration and occlusal clearance UC ...... ...... == 1. Software Requirements Specification== {{include document="Polaris.SoftwareRequirementsSpecification" context="new"/}} === 1.1. Use cases=== {{include document="Polaris.Use cases" context="new"/}} ...... " But when I export the document to PDf my compiled TOC(which is rather large) is not carried on the next page, it is just cut in the middle. The Export to RTF passes ok with carrying the TOC on the next page. Could somebody help to understand where is the problem? Thanks, elena

2 3