- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Move xwiki-application-invitation to platform-applications and include in XEnterprise
by Caleb James DeLisle 07 Jun '10

07 Jun '10

Hello all, First my proposal: I propose we add the invitation application to platform/applications and give it a jira top level project name, I further propose we add a dependency to the Enterprise pom.xml and merge the UI tests which I have wrote into the Enterprise UI tests. I would rather not move the translation keys into the default document bundle until nearer release time because it would be nice to use the new internationalization module if possible and as development is still going fast, there will be changes to translations. The state of the invitation application: All major refactoring is finished and I am now just squashing bugs and adding new features. Lately I have been debugging using tests rather than manual debugging, So far I have 7 UI tests which with framework comprise 1207 lines in 8 files. Maintaining a fork of the UI tests is becoming burdensome and I think the invitation application is ready to be included. Improvements since the version which is on the incubator: * Each message has a "history", a list of status changes, the user who made the change and a log (if any) which they left regarding the change. * An invitation sent to multiple addresses is handled as a group of invitations each of which may be accepted/declined individually, the sender or admin can view the group and see all of the messages in it as a table. * Users see an info macro at the bottom of the screen telling them how many pending invitations they have (if any). * Admins see a warning macro at the bottom of the page telling them how many message have been reported as spam (if any have). * Templates are translatable and (should be) compatible with more email clients. Tasks still to be done include: * A means by which invitees can be allowed into a closed wiki. * Invitation of a mailing list. * Handling "join requests". * Use javascript to make it easier to use and implement livetable * Improve CSS. WDYT? Caleb

2 1

[xwiki-devs] footer
by Sales, G. (Grant) 04 Jun '10

04 Jun '10

If we invoke it twice in a row: {{hello greetUser="true" /}} {{hello /}} The second invocation will not print "Hello World!" as we'd expect. But it will print the same result as the first invocation. The reasons are: * Macro parameters are implemented as global parameters. So, they remains the same across multiple macro invocations. * If $context.macro.params.greetUser contains "null", it will not be assigned to $greetUser. This is different from C/C++ or Java. So in order to get around it, you can use: #set($greetUser="$!context.macro.params.greetUser") Tags: [+] <http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial?showTag…> Created by Asiri Rathnayake <http://www.xwiki.org/xwiki/bin/view/XWiki/asiri> on 2009/07/20 08:30 Last modified by Thomas Mortagne <http://www.xwiki.org/xwiki/bin/view/XWiki/ThomasMortagne> on 2010/05/12 19:42 How can I add the Last Modified by in the bottom by the Created by like on Xwiki.org? Should be an easy way but I can't seem to figure out how to add code below the page like that. Is it in the Admin tools? If so where in there? Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. ® --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

1 0

[xwiki-devs] Nested spaces and right service implementation
by Andreas Jonsson 04 Jun '10

04 Jun '10

Hi, I have almost finished writing a new right service implementation and have some questions about nested spaces. I am using the EntityReference classes for representing the document hierarchy, with the addition for using the main wiki as the parent of a virtual wiki. XWikiRightServiceImpl is using the parent field in the space's preferences to form a space hierarchy. The EntityReference classes support a list of spaces, but this does not seem to be implemented yet. Can a right service implementation assume that the nested space hierarchy was resolved externally and was inserted into the DocumentReference as a list of spaces? Will the list of spaces in an EntityReference correspond to following parent fields in the space preferences or does a right service implementation need to resolve these parent fields for backwards compliancy? Best Regards, Andreas Jonsson

2 2

[xwiki-devs] Calling only one property
by Sales, G. (Grant) 03 Jun '10

03 Jun '10

Here is how you filter out one dead property (or hide it) #foreach($prop in $class.properties) #if($prop.getName() != "unused_author") ; $prop.prettyName : $doc.display($prop.getName()) #end #end How can you call just the properties you want with out using a for each loop? Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

3 5

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution
by Vincent Massol 03 Jun '10

03 Jun '10

On Jun 3, 2010, at 1:01 PM, Ludovic Dubost wrote: > Le 03/06/10 12:48, Vincent Massol a écrit : >> On Jun 3, 2010, at 12:20 PM, Ludovic Dubost wrote: >> >> >>> Le 03/06/10 11:33, Vincent Massol a écrit : >>> >>>> On Jun 3, 2010, at 10:31 AM, Vincent Massol wrote: >>>> >>>> >>>> >>>>> Hi devs, >>>>> >>>>> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >>>>> >>>>> Some ideas: >>>>> - java macros are much easier to test >>>>> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >>>>> - java macros can obey styling rule, such as checkstyle passing >>>>> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >>>>> >>>>> Proposal >>>>> ======= >>>>> >>>>> - If the macro is a generic macro then it should be written as a Java macro >>>>> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >>>>> >>>>> WDYT? >>>>> >>>>> >>>> ok, I've been convinced that there's no simple solution and thus that we need to decide whether a macro should be implemented in java or as a wiki page on a case by case basis. >>>> >>>> Thus I propose that when a macro is implemented as a wiki macro, we put in SVN in platform/applications as an application by itself (ie a XAR). In the same manner as java macros are a JAR by themselves. >>>> >>>> >>> We should avoid having one application per macro, otherwise it's going to be a mess. >>> >> In what sense? >> >> JIRA-wise? Release-wise? >> >> > It's going to be way to segmented in SVN, JIRA and in terms of multiple XARs > I think we should see it as a package of Macros more than a package of each macro Actually I agree that it's better to have a single application for wiki macros. We release all java macros as one so we can also do the same for wiki macros. We can put these wiki macros in a separate application or inside the wiki-macro-bridge application since they depend on it. I'm more for the latter. Thanks -Vincent > Ludovic > >>> I think we should categorize the wiki macros so that we have one application by big category. >>> >> Also we'll soon have the ability to download and install them from the internet, making it easy to install extensions. Providing superpackages is possible with the new extension manager, simply by having an extension that has dependencies on individual artifacts. >> >> But yes I agree we need to think about macro explosion and how we handle this, whether we want a single JIRA module for macros for exemple and release them all together. JIRA + release are the only issues I can think of since we're talking about macros bundled by default. >> >> Note: We also need to agree on a space where to put them. >> >> Thanks >> -Vincent

1 0

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution
by Vincent Massol 03 Jun '10

03 Jun '10

On Jun 3, 2010, at 12:20 PM, Ludovic Dubost wrote: > Le 03/06/10 11:33, Vincent Massol a écrit : >> On Jun 3, 2010, at 10:31 AM, Vincent Massol wrote: >> >> >>> Hi devs, >>> >>> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >>> >>> Some ideas: >>> - java macros are much easier to test >>> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >>> - java macros can obey styling rule, such as checkstyle passing >>> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >>> >>> Proposal >>> ======= >>> >>> - If the macro is a generic macro then it should be written as a Java macro >>> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >>> >>> WDYT? >>> >> ok, I've been convinced that there's no simple solution and thus that we need to decide whether a macro should be implemented in java or as a wiki page on a case by case basis. >> >> Thus I propose that when a macro is implemented as a wiki macro, we put in SVN in platform/applications as an application by itself (ie a XAR). In the same manner as java macros are a JAR by themselves. >> > We should avoid having one application per macro, otherwise it's going to be a mess. In what sense? JIRA-wise? Release-wise? > I think we should categorize the wiki macros so that we have one application by big category. Also we'll soon have the ability to download and install them from the internet, making it easy to install extensions. Providing superpackages is possible with the new extension manager, simply by having an extension that has dependencies on individual artifacts. But yes I agree we need to think about macro explosion and how we handle this, whether we want a single JIRA module for macros for exemple and release them all together. JIRA + release are the only issues I can think of since we're talking about macros bundled by default. Note: We also need to agree on a space where to put them. Thanks -Vincent

2 1

[xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution
by Vincent Massol 03 Jun '10

03 Jun '10

Hi devs, We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. Some ideas: - java macros are much easier to test - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) - java macros can obey styling rule, such as checkstyle passing - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR Proposal ======= - If the macro is a generic macro then it should be written as a Java macro - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro WDYT? Thanks -Vincent

3 4

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution
by Vincent Massol 03 Jun '10

03 Jun '10

On Jun 3, 2010, at 10:37 AM, Ludovic Dubost wrote: > Le 03/06/10 10:31, Vincent Massol a écrit : >> Hi devs, >> >> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >> >> Some ideas: >> - java macros are much easier to test >> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >> - java macros can obey styling rule, such as checkstyle passing >> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >> >> Proposal >> ======= >> >> - If the macro is a generic macro then it should be written as a Java macro >> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >> >> WDYT? >> > > I believe there is some other cases where it should be a wiki macro, it's when the macro is highly presentational and when there is a good chance the advanced user would like to be able to change the macro to add parameters or modify it's presentation. > In this case it's very important to make the macro easily modifiable and that's what Wiki macros allow. Indeed anything related to presentation/style (colors, fonts, texts, etc) should be modifiable by the user so that part needs to be externalized from the java macro somehow. One idea is to have these macros provide a cssLocation/jsLocation parameter pointing to place where to put custom css/js. When not specified the macro would use default css/js. Ideally we would have a full-fledged IDE in the wiki and we would write everything as wiki macros but this is not the case and we're a few years away from this so I'm not sure it's a good idea to do so right now. BTW this is a bit similar to the discussion as to whether the Blog application should have a Java module that implements its code logic and only keep the presentation part in wiki page vs what we have right now, i.e. the whole application in wiki pages. > For testing, I believe we should make a simple testing framework that allows to test a simple wiki macro (which does not use jsx or other stuff). Making a wiki macro testing framework that works without a running XE is probably quite a lot of work. Need to think more about it. Thanks -Vincent

2 1

[xwiki-devs] Wanted Macros
by Vincent Massol 03 Jun '10

03 Jun '10

Hi XWiki lovers, If you're interested in seeing some macros developed and available for your wiki, please edit this page and add macros you'd like to see: http://dev.xwiki.org/xwiki/bin/view/Design/NewMacros Thanks -Vincent

1 0

[xwiki-devs] Introducing Sorin Burjan
by Sorin Burjan 03 Jun '10

03 Jun '10

Hello. My name is Sorin Burjan, and I started working at XWiki two days ago. I came to XWiki as a software tester, technical writer, but as the time goes by, I'd like to get involved in dev too. For the moment, I'm working with Silvia on updating the documentation on the web site, and creating a set of rules/standards on how to write and maintain the documentation. The document will be posted on the comunity site, so you can give me your feedback. Regards, Sorin B.

2 1