June 2008 - xwiki-devs@xwiki.org

[xwiki-devs] Releasing spacemanager 1.0.1
by Jerome Velociter 04 Jun '08

04 Jun '08

Hello devs, Just a short note to inform you I'm about to release spacemanager 1.0.1 version. This is a bug fix version that is mainly needed for the curriki project (spacemanager 1.0 branch rely on core 1.3). It has the following release notes : http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10301&… Regards, Jerome.

1 0

[xwiki-devs] Tip for writing new component depending on xwiki-core
by Vincent Massol 04 Jun '08

04 Jun '08

Hi, Just wanted to share this tip. Imagine that you need to write a new module but it requires some dependency on xwiki-core and xwiki-core also needs to use this new module... This is often the case since we haven't moved the model to a new module yet. So how do you solve this circular dependency? Solution: * In your new module, create a component interface to isolate the new code from xwiki-core * Use component to lookup the implementation. This will only be resolved at runtime. * Implement the component interface in xwiki-core Hope it'll help someone -Vincent

1 0

[xwiki-devs] [gsoc] syntax highlighting and code assistance
by malaka ekanayake 04 Jun '08

04 Jun '08

hi fabio, It will get another 2 days to get my new internet connection.So what should I do till I get my connection.Unfortunately I will not be able to look at the new XE release.:-( Should I look in to implement syntax assistance for one language (xwiki syntax) or should I need to think of all the syntax at the first since xwiki pages will include a mix of several syntaxes .The article I have found explains how to implement syntax for SQL.I think by getting help from you I will be able to implement syntax asistance for one laguage.So what path I should take. -- Malaka Ekanayake CSE UOM

2 1

[xwiki-devs] n umber of maximum BLOGS in xwiki
by Vivian Richard 04 Jun '08

04 Jun '08

Hello Devs, is there any limitations on how many BLOGS can be created on one installed XWiki. Some one told me that the maximum six person can create six different blogs in one XWiki. Is it true? Best regards Viv

4 10

Re: [xwiki-devs] Refactoring Administration and Preferences
by Jean-Vincent Drean 04 Jun '08

04 Jun '08

On Wed, Jun 4, 2008 at 11:05 AM, Evelina Slatineanu <evelina.slatineanu(a)xwiki.com> wrote: > Hi all, > > I have a question: should we also keep the old interface for users, groups > and rights in the new Administration application? (the current interface is > now set from xwiki.cfg but the default one is the new UI). Is there a point > to keep the old one (for older customers, no js browsers??) > AFAIK we've added this option because the new rights UI hasn't been tested enough at that time, I think we can consider it as stable enough to be the only rights editor now. OTOH it won't work with javascript disabled, but the object editor will .. I'm not sure about this one. XWikiers WDYT ? -- Jean-Vincent Drean

2 1

Re: [xwiki-devs] [xwiki-notifications] r177 - in components/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/block xwiki-rendering-api/src/main/java/org/xwiki/rendering/macro xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser xwiki-rendering-api/src/main/java/org/xwiki/rendering/transformation xwiki-rendering-api/src/test/java/org/xwiki/rendering xwiki-rendering-doxia xwiki-rendering-doxia/src/main/java/org/xwiki/rendering/doxia/internal xwiki-rendering-doxia/src/main/java/or
by Sergiu Dumitriu 04 Jun '08

04 Jun '08

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-06-03 20:58:01 +0200 (Tue, 03 Jun 2008) > New Revision: 177 > > Log: > XWIKI-654: Rewrite the Rendering engine > > * Renamed Document into DOM. This is a better name and not in conflict with the XWiki Document. The other option was to name it DocumentAST or AST. Jean-Vincent preferred DOM and I agreed with him, although it was a close call ;) I'm not sure DOM is a good name, as it already stands for something else. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 3

[xwiki-devs] [VOTE] Move new rendering code to the platform core?
by Vincent Massol 04 Jun '08

04 Jun '08

Hi, I'm ready to move the new rendering code currently located in the sandbox to the platform core. I have succeeded in doing some basic integration in the core and I think it's time to commit this too. This is how it works: * I've introduced a new syntaxId database field for documents * When the syntaxId value is null/empty or has a value of "xwiki-1.0" the old rendering is used * When it has a value of "xwiki-2.0" the new rendering is used I'm working on providing a way (for admins only for now) so that in edit mode you can choose the syntax id to use for the page. Right now I'd just like us to vote to move the new rendering code to the platform core. Here's my +1 Thanks -Vincent

6 5

[xwiki-devs] Refactoring Administration and Preferences
by Sergiu Dumitriu 04 Jun '08

04 Jun '08

Hi devs, This is somewhat in response to the discussion about the new Administration page design. Behind the scenes, there was a discussion about where should the Import page put the uploaded xar, in XWiki.Import (as it is done now), or in XWiki.XWikiPreferences. Both sides agreed that the administration should automatically find and use administration pages, but didn't agree on what "use" means. So, how should things work? A. The main administration page contains links to other pages B. The main administration page includes other administration sheets Option A means that each administration topic uses its own page to store configuration, which somehow breaks the current configuration mechanism, where all (global) settings go into the XWiki.XWikiPreferences page. Option B means that each administration document is used only as a sheet, so all objects will be in XWiki.XWikiPreferences. If we choose B, then the best thing to do is to attach imported xars to the XWikiPreferences page, instead of Import. Doing otherwise will either be very hard or would break the convention. So, the main question is: Do we keep all settings in the same document? Or do we allow each application/component to have its configuration in its own document? I think it would be better to have all the configuration in one place, instead of spreading it all over the wiki. And since we're touching the configuration part, I think we should completely rewrite this part, as the current system is sooo bad (I mean the XWiki#get[User/Web/XWiki]Preference[AsSomething] methods and the giant XWikiPreferences class). This was supposed to be a Configuration proposal that I was thinking about, but didn't have the time to write until now. So here it is: Requirements: 1. We should allow an application/component to be configured at the farm, wiki, space, user and document level (the specificity can be configured for each setting), with static values in the component's xml configuration and default values in the java class file or in the template/wiki document using the configuration (depending on whether there is a component/java/template part). 2. An application should be able to define its own customization xclasses, the same class being usable for all levels of customization (now, some settings go both in XWikiUsers class and XWikiPreferences class). In fact, XWikiPreferences should disappear completely. 3. Global (farm) settings should go in [mainwiki]:Admin/GlobalPreferences, wiki settings should go in Admin/WikiPreferences, space settings should go in <Space>/SpacePreferences, user settings should go in the user profile. The current locations are inappropriate (WebPreferences??). [I'm not sure if Preferences is a good name, as the list of blog categories is not exactly "preferences", but more like "settings"] 4. The settings pages include an administration sheet, which later lists all customization pages in the wiki that are customizable at that level (for the moment, using an explicit search, later using Interface Extensions). 5. The configuration should be accessible using a simple API, which should find the right settings, internally taking care of all the details: consider the lowest level for that setting (some settings are valid only at the wiki level, or even global, so don't search or allow settings at a lower level), security (some settings should only be taken into consideration if the author is trusted), in-wiki and in-file settings. This means that the application should call one method, and not have a complicated code combining getUserPreference, getWebPreference, getXWikiPreference and Param. 6. All this should be done without changing the data model (meaning that we use the classic xclasses/xobjects for this). How things work: An application lists one or several wiki documents in its application description as customization classes. Administration sheets (also from the application) are then autoincluded in the global, wiki or space Administration page, and in the user settings page. Such a sheet would check if the class allows customization at the current level, and if not, warns about this. If there is no instance of the target class, it provides a link for creating one (doing it automatically is another option, but I don't think it is a good idea, as this pollutes the wiki with unused objects). The sheets should follow a common guideline, for consistency. All options should be documented in the sheet. The application code then calls the settings component API to check the settings that apply for the current document/user. Of course, all this with lots of caching for good performance (this is not the case in the current core, as a lot of time is spent cloning XWikiPreferences in HibernateCacheStore). The hard part is deciding how to configure these classes and sheets. Since we shouldn't use different Property types, we can't add a customizationLevel metaproperty. A feasible solution would be to require all properties in the same class to have the same level of configuration, and either specify in the application description, or use a tag for that. The best would be to have a document property, but the current data model does not have that. Proposed API variant 1: /* Gets the current setting for an application, from the specified class. */ String getSetting(applicationName, className, settingName); /* Same as above, when the application has only one settings class defined. */ String getSetting(applicationName, settingName); /* If the current document is known to belong to a certain application, get a setting for that application */ String getSetting(settingName); /* Stops at a specified level, instead of the default one. */ String getSettingForLevel(applicationName, className, settingName, maxLevel); /* Returns the setting at a specified level, with no inheritance. */ String getSettingAtLevel(applicationName, className, settingName, exactLevel); Proposed API variant 2: /* Search for the setting name in the attached objects. */ String getSetting(settingName); /* Gets the current setting, from the specified class. */ String getSetting(settingName, className); /* Stops at a specified level, instead of the default one. */ String getSettingForLevel(settingName, className, maxLevel); /* Returns the setting at a specified level, with no inheritance. */ String getSettingAtLevel(settingName, className, exactLevel); - I don't know if we need methods returning other types, like int or double, since we can use velocity tools for converting the returned string - I don't know if we should have the applicationName in the parameter list, or just the className; my take is that specifying the application name is a bit more semantical and less technical - maxLevel should be an enum, but we need a custom introspector for this to work - maxLevel assumes a fixed order of levels, which is an obvious one, except for the User level. Where should that be in this order? Is the user preference the most important one? So, WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 5

Re: [xwiki-devs] [xwiki-notifications] r10099 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/stats/impl
by Vincent Massol 04 Jun '08

04 Jun '08

On Jun 4, 2008, at 4:52 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-06-04 04:52:41 +0200 (Wed, 04 Jun 2008) > New Revision: 10099 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > stats/impl/StatsUtil.java > Log: > [misc] Don't use a local variable to hide the class member. > > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/stats/impl/StatsUtil.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > stats/impl/StatsUtil.java 2008-06-04 02:51:14 UTC (rev 10098) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > stats/impl/StatsUtil.java 2008-06-04 02:52:41 UTC (rev 10099) > @@ -590,7 +590,7 @@ > cookie.setMaxAge(time); > > String cookieDomain = null; > - String[] cookieDomains = StatsUtil.getCookieDomains(context); > + getCookieDomains(context); btw this is a badly named method if it has some side effects other than getting cookie domains... -Vincent > > if (cookieDomains != null) { > String servername = context.getRequest().getServerName(); > for (int i = 0; i < cookieDomains.length; i++) {

1 0

Re: [xwiki-devs] [xwiki-notifications] r10097 - xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/src/main/resources
by Vincent Massol 04 Jun '08

04 Jun '08

I remember why it was 98 and not 100 below for Eclipse. That's because with 100 sometimes it failed to cut the line at 100 and went beyond it. Let's see what it does now. Thanks -Vincent On Jun 4, 2008, at 4:32 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-06-04 04:32:10 +0200 (Wed, 04 Jun 2008) > New Revision: 10097 > > Modified: > xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/src/ > main/resources/checkstyle.xml > xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/src/ > main/resources/codestyle-eclipse.xml > xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/src/ > main/resources/codestyle-idea.xml > Log: > XTVERIFICATIONS-3: Increase the maximum line length in java source > files to 120 > Done. > > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-verification- > resources/src/main/resources/checkstyle.xml > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/checkstyle.xml 2008-06-04 01:27:17 UTC (rev 10096) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/checkstyle.xml 2008-06-04 02:32:10 UTC (rev 10097) > @@ -200,8 +200,8 @@ > </module> > > <module name="LineLength"> > - <property name="ignorePattern" value="(@version|@see| > ^import)"/> > - <property name="max" value="100"/> > + <property name="ignorePattern" value="(@version|@see|@link| > ^import)"/> > + <property name="max" value="120"/> > </module> > > <module name="LocalFinalVariableName"/> > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-verification- > resources/src/main/resources/codestyle-eclipse.xml > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/codestyle-eclipse.xml 2008-06-04 01:27:17 UTC > (rev 10096) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/codestyle-eclipse.xml 2008-06-04 02:32:10 UTC > (rev 10097) > @@ -70,7 +70,7 @@ > <setting > id > = > "org > .eclipse > .jdt > .core > .formatter > .insert_space_before_opening_angle_bracket_in_type_parameters" > value="do not insert"/> > <setting > id > = > "org > .eclipse > .jdt.core.formatter.insert_new_line_in_empty_type_declaration" > value="insert"/> > <setting > id > = > "org > .eclipse > .jdt.core.formatter.comment.clear_blank_lines_in_block_comment" > value="true"/> > -<setting id="org.eclipse.jdt.core.formatter.lineSplit" value="98"/> > +<setting id="org.eclipse.jdt.core.formatter.lineSplit" value="120"/> > <setting > id > = > "org > .eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_if" > value="insert"/> > <setting > id > = > "org > .eclipse > .jdt > .core > .formatter.insert_space_between_brackets_in_array_type_reference" > value="do not insert"/> > <setting > id > = > "org > .eclipse > .jdt > .core > .formatter > .insert_space_after_opening_paren_in_parenthesized_expression" > value="do not insert"/> > @@ -184,7 +184,7 @@ > <setting > id > = > "org > .eclipse > .jdt.core.formatter.insert_new_line_before_while_in_do_statement" > value="do not insert"/> > <setting > id > = > "org > .eclipse > .jdt.core.formatter.alignment_for_arguments_in_enum_constant" > value="20"/> > <setting > id="org.eclipse.jdt.core.formatter.comment.format_javadoc_comments" > value="true"/> > -<setting id="org.eclipse.jdt.core.formatter.comment.line_length" > value="100"/> > +<setting id="org.eclipse.jdt.core.formatter.comment.line_length" > value="120"/> > <setting > id > ="org.eclipse.jdt.core.formatter.blank_lines_between_import_groups" > value="1"/> > <setting > id > = > "org > .eclipse > .jdt > .core > .formatter.insert_space_before_comma_in_enum_constant_arguments" > value="do not insert"/> > <setting > id="org.eclipse.jdt.core.formatter.insert_space_before_semicolon" > value="do not insert"/> > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-verification- > resources/src/main/resources/codestyle-idea.xml > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/codestyle-idea.xml 2008-06-04 01:27:17 UTC (rev > 10096) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/ > src/main/resources/codestyle-idea.xml 2008-06-04 02:32:10 UTC (rev > 10097) > @@ -34,7 +34,7 @@ > <option name="BLANK_LINES_AROUND_FIELD" value="1" /> > <option name="CLASS_COUNT_TO_USE_IMPORT_ON_DEMAND" value="99" /> > <option name="NAMES_COUNT_TO_USE_IMPORT_ON_DEMAND" value="99" /> > - <option name="RIGHT_MARGIN" value="100" /> > + <option name="RIGHT_MARGIN" value="120" /> > <option name="CALL_PARAMETERS_WRAP" value="1" /> > <option name="METHOD_PARAMETERS_WRAP" value="1" /> > <option name="EXTENDS_LIST_WRAP" value="1" />

1 0