xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-notifications] r19162 - platform/core/trunk/xwiki-core/src/main/resources

by Vincent Massol

Warning, warning... The merge is wrong.... I had made some changes, see below On Apr 28, 2009, at 5:46 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-04-28 17:46:00 +0200 (Tue, 28 Apr 2009) > New Revision: 19162 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties > Log: > XWIKI-3718: Update french translations > > Modified: platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties 2009-04-28 14:29:14 UTC (rev 19161) > +++ platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources_fr.properties 2009-04-28 15:46:00 UTC (rev 19162) [snip] > -XWiki.XWikiPreferences_smtp_server=Serveur > -XWiki.XWikiPreferences_smtp_port=Port > +XWiki.XWikiPreferences_smtp_server=Serveur SMTP This is not correct for example. There are other places too probably. You need to check the merge. Thanks -Vincent

15 years, 9 months

[xwiki-devs] In-wiki macros : generic wiki macro, or bridged script macros or selectable implementation ?

by Jerome Velociter

Hi devs, I'm going to continue the work on allowing users to write syntax 2.0 macros inside the wiki (http://jira.xwiki.org/jira/browse/XWIKI-3213) We have several implementations possible for this: 1. Having only one generic wiki macro implementation. This means macro authors will have to call explicitly the velocity macro inside if they need velocity scripting (same for other script languages) * Pros: - You can use wiki syntax in your macro. This is cool, it enables doing things like wikipedia templates (http://en.wikipedia.org/wiki/Help:Template) - We can easily provide the GWT-WYSIWYG to macro authors. This is an idea I like - It sound pretty natural to do it this way * Cons: - We'll have to put macro parameters in the XWiki context so that they are available to all script macros used in the macro. It means authors will have to refer to parameters using $context.get("parameterName") instead of $parameterName that would be doable with 2. 2. Writing one implementation per script language. This means authors will create a velocity macro and will write directly velocity code in the code are of the macro. * Pros: - Parameters don't need to be passed in the XWiki context (at least I think, if I'm wrong please explain me/us why) * Cons: - We'll have several XWiki classes, one per supported scripting language (XWiki.VelocityMacroClass, XWiki.GroovyMacroClass, etc.) - We cannot use wiki syntax in any implementation, so we cannot do the wikipedia templates-like thing 3. Keep for ourselves the ability to chose from the wiki the implementation class of the macro, but default on 1. the generic script macro. This means we will have a "class" field in the XWiki.MacroClass which allows to chose which implementation should be the code rendered against. If we do that I think this field should be hidden in the class sheet, and only be accessible using the object editor. This is similar to the way Scheduler Job objects works right now. * Pros: - Best of both world, we can have 1. and 2. - Leaves open the door for new macros implementations we could want in the future, or that developers would want just for their wiki * Cons: - Probably a little more code to handle that Right now, I tend to think we should do 3. with only one implementation available at first, being the generic wiki macro described in 1. WDYT ? Thanks in advance for your feedback. Cheers, Jerome.

15 years, 9 months

Re: [xwiki-devs] [xwiki-users] Links, WYSIWYG 2.0 (1.8.2)

by Anca Paula Luca

hel-o wrote: > Hi, > > the link dialog works much better than in 1.8.1, but one thing i found: > > i don't use the space for the page parent when i add the parent manually > (which i had to, since it wasn't added automatically in the new syntax) > because i found, that it's not needed to work (as it is in links when the > link is in the same space). > > Now when i want to create a link to a wiki-page i get the tree-view (which > is great) but it seems i cant see all those pages where no space is > provided. Hi Hel, thanks for reporting this behaviour! Of what I experimented just now, this seems to be caused by the REST API (used by the tree) for getting pages and the way it uses the passed "parent" parameter. Specifically, it does not interpret the value of the document parent field wrt the document's space. I see 2 solutions: 1/ either we change the panel to set the parent field to a fully qualified name (when a user inserts only a document name in the parent field, we append the space) 2/ either we fix the REST API. Solution 1 might cause problems when it will come to multiwikis, when the parent can be prefixed by the wiki name as well (wiki:Space.Page). Or: 3/ we change the parent-child relation in the explorer tree so that we make it survive such situations. Happy coding, Anca Luca > > hel. > > > > ----- > ---- > hel(a)hel.at >

15 years, 9 months

[xwiki-devs] [Proposal] Inline mode for XWiki Syntax 2.0

by Vincent Massol

Hi, We need to have automatic inline edit mode for XWiki Syntax 2.0 (http://jira.xwiki.org/jira/browse/XWIKI-2891) I'd like to implement this quickly since it prevents to use the xwiki syntax 2.0 as the default syntax (for ex if you create a user in 2.0 syntax and click edit you'll edit it in wysiwyg mode instead of inline mode). A quick solution I have: * Use the XWikiDocument template field to set the sheet to use * When a page has the template field set, when the user clicks on the edit button it goes automatically in inline edit mode * Add a new field in the information edit panel to set the template (only for advanced users I think) WDYT? Thanks -Vincent

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r19154 - in platform/core/trunk/xwiki-rendering: . xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rendering-tests/src/test/resources/group

by Vincent Massol

On Apr 28, 2009, at 2:04 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-04-28 14:04:43 +0200 (Tue, 28 Apr 2009) > New Revision: 19154 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/group/group11.test I'd have put put in the same test file we already have for testing parameters for groups (ie group9.test). Otherwise it doesn't sounds obvious why and we should add some comments anyway in group9.test saying that we test group parameters. [snip] Thanks -Vincent

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r19131 - in xoffice/trunk/xword: XWikiLib/XWiki XWord

by Sergiu Dumitriu

fciubotaru (SVN) wrote: > Author: fciubotaru > Date: 2009-04-27 15:00:12 +0200 (Mon, 27 Apr 2009) > New Revision: 19131 > > + Space exstngWithUnpubPagesSpace = wiki[sp.name]; I prefer to keep away from such shorted names, as they don't provide any real benefits, but reduce readability. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

[xwiki-devs] [VOTE] getCurrentDocumentName method to DocumentAccessBridge

by Thomas Mortagne

Hi dev, My use case is http://jira.xwiki.org/jira/browse/XWIKI-3418 WDYT ? Here is my +1 -- Thomas Mortagne

15 years, 9 months

[xwiki-devs] Implementing pseudoversions

by Sergiu Dumitriu

Hello devs, Auto-saving the content during long edit sessions, to prevent the complete loss of data in case of browser or OS crashes, (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful feature that people have been asking for. For 1.9 there will be the possibility to enable autosave. However, the implementation is pretty basic, more of a hack on top of the current architecture: an asynchronous JavaScript calls periodically save & continue, marking the saved versions as minor and setting the version comment to "(Autosaved)". This approach has some obvious disadvantages: - A lot of minor versions are created during the editing - Cancel does not undo the changes (a revert could be done to the version at the beginning of the editing session, which creates yet another document version) ... but at least it's a start. For properly implementing this in the future, some important changes are needed. In particular, the support for pseudoversions (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document. These pseudoversions will be memorized in a new table, similar to the document table or the recycle bin. Along with introducing pseudoversions, several behaviors should be changed, improving the user experience. For instance: - In all editors, "Save & Continue" should become "Save draft" and should create pseudoversions that can be canceled, and "Save and View" should become simply "Save" (these texts are also much easier to understand by the user). - In class editing, properties are added in the pseudoversion, and these changes can be canceled when the user presses the "Cancel" button. (canceling property addition is not possible ATM, unless the document is reverted). - In the object editor, objects can be added in the pseudoversion, and all changes can be saved at once. These changes are pretty substantial, from the data management and user experience point of view, but I believe it is worth making the step. Please tell me what you think. Should we try to get this done before 2.0? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

[xwiki-devs] Welcoming our GSoC students

by Sergiu Dumitriu

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 an impressive number of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose only 6. 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 [http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/]. 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 [http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline], the next month (April 20th - May 23rd) 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. 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: - http://purl.org/xwiki/community/ - http://purl.org/xwiki/dev/ - 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 anytime with useful ideas and suggestions. Moreover, if your mentor is hit by a bus (the bus factor [http://en.wikipedia.org/wiki/Bus_factor]), 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 waisting 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. We have set up a wiki on the community farm for you to organize your ideas and log your progress: http://gsoc.myxwiki.org/ . Each student must register on this wiki, create and organize a space for the project, with a blog where the evolution will be described. Currently the wiki is pretty empty, but it will grow. Development process The project's lifecycle is NOT design -> implementation -> testing -> documentation. [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/] We invite you to adopt a test driven development [http://en.wikipedia.org/wiki/Test-driven_development][http://www.amazon.com…] approach and to experience agile development [http://www.amazon.com/dp/0596527675/]. 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). We will create the proper projects in the xwiki sandbox, and 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, 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__ -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (use the wiki), 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 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! -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r19122 - platform

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-04-27 09:25:39 +0200 (Mon, 27 Apr 2009) > New Revision: 19122 > > Added: > platform/xwiki-core/ > Log: What's this? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 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