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

[xwiki-devs] Logging architecture proposal

by Jonas von Malottki

Hello X-Wikians, I am currently browsing the Xwiki Code and thus found the current handling of the logging to catch my eye. I filed a jira idea (XWIKI-2437) to use slf4j as logging abstraction. it wasn't until this mornig though that I found the new logging Architecture in the component sub part, and also Vincent pointed me 20 minutes later to it. Still even with the logging pushed through the org.xwiki.component.logging.Logger interface I have a suggestion. A very good thing at the slf4j and particularly one of the implementations is that building of the logging strings can be deferred to the logger. I will explain that with an example: Current Logger interface you will have to do this (or something similar) LOG.debug("my debug message is " + var1 + " " + var2 + ": " + var3 ); This will force the Java VM to build the string and then call the function to realize later that the string will not be logged. Now one could introduce an if statement with log.isDebugEnabled() before any such statement, but that is kind of tedious and clutters the code. In slf4j you would write something like this: LOG.debug("my debug message is {} {}: {}", var1, var2, var3); Thus the function will be called but the string operation can take place iff the string will really be logged. (see http://www.slf4j.org/manual.html) So my proposal is to give the logging interface a little bit of slf4j flavor and introduce log statements with varargs or Object arrays like: public void debug(String msg, Object... args); /* plus all the other loglevels */ If one wants to use log4j then a simple wrapper could be written to format those args before log it depending on the loglevel. Thinking a bit further, slf4j does already that what it is intended with the new component logger since the implementations are deploytime pluggable (currently logback, simple logger, log4j and jcl can be used as backend) and slf4j is just a facade to the logging system, thus fulfilling the component based approach. Since reuse is better than reinvent... cheers Jonas

17 years, 3 months

2
3
0 0

[xwiki-devs] SX questions

by Vincent Massol

Hi (Sergiu), I finally read your SX design doc yesterday night and I have some questions: * It's called Skin Extensions (SX) but it seems to be missing vm extensions, right? AFAIU this is in IX. I would have expected Skin extensions to include vm. Maybe just a problem of terminology. * How do you manage CSS/JS that depend on the skin used. For ex you took the example of usersandgroups.css in your doc but that CSS is different for Albatross and for Toucan. How do we handle this? * Now that it's implemented, would be nice to move the doc to the developer's guide and add some examples. Also do you know where in the code this is used right now? * Has there been some measurements to see how performance is affected? Thanks a lot, sounds very cool. -Vincent

17 years, 3 months

2
1
0 0

[xwiki-devs] Setting TAGs in XWiki workspaces

by Vivian Richard

Hello Vincent, Pressing EDIT button on XWiki Enterprise wiki page shows the TAG list attached to a page aloowing them to be changed. I do not see it here in workspaces. How do I get that in XWiki workspaces so that I may set/reset TAG values. Best Regards, Viv

17 years, 3 months

2
1
0 0

[xwiki-devs] New Rendering in core, what can you expect?

by Vincent Massol

Hi, Just committed the new rendering mechanism in xwiki core. Please note that this is a work in progress and it's missing a LOT of things. However we can now all work together on finishing it. Here's how it works: * Each document has a syntax id, which defaults to XWiki 1.0 * In edit mode (Toucan skin), you can change the syntax for a page using the Document Information panel on the right What's supposedly working in the new syntax: * basic wiki syntax, lists, paragraph. Not everything is done yet and there are some bugs in the WikiModel XWiki parser * velocity macro, xhtml macro and include macro Try it out and have fun, just don't expect too much yet... ;) -Vincent

17 years, 3 months

2
3
0 0

Re: [xwiki-devs] Refactoring Administration and Preferences

by Evelina Slatineanu

Hi all, Besides working on the new Administration, I also did some clean up for the existing apps (blog, photos, calendar), making them platform applications. The question is: should I place the pages in app. specific spaces (ex. Blog, Calendar, Photos) and also update all the links to the new apps in all xwiki docs (I have already a 80% finished version of this kind) or should I leave the files in the XWiki space? (as Jv mentioned, we might need to keep the compatibility for older clients because most of the pages which need updates are classes, so this could break possible hand-made queries) Thanks, Evelina

17 years, 3 months

1
0
0 0

[xwiki-devs] exception when saving wiki in editor(wiki)

by CarrollJ

Hi all, I have a problem when saving a wiki in the wiki editor. When it is saved an exception occurs (below). When i then view the page after the exception it works fine. Does anyone have any suggestions on what i can do to fix it? Thanks, John Carroll A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 3201 in 3: Exception while saving document StageGate.WebHome Wrapped Exception: Error number 13012 in 3: Exception while saving links Wrapped Exception: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xpn.xwiki.objects.LargeStringProperty#] -- View this message in context: http://www.nabble.com/exception-when-saving-wiki-in-editor%28wiki%29-tp1766… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 3 months

2
2
0 0

[xwiki-devs] [GSOC][WebDAV] Status ...

by Asiri Rathnayake

Hi All, I thought it's better to keep you all updated about what i'm doing. I've finally managed to free myself from academics and now i'm working on WebDAV interface. * I have gone through Ludovic's sample XWikiWebDAV implementation and except for few parts now i understand the code base and what i need to do. And i should mention that this sample implementation was very useful, i would have lost otherwise ;) * I've put up an eclipse project with WTP (Web Tools Platform) support which let me test the DAV implementation easily. Also, using M2Eclipse i have created a pom as well. * Currently, with a back-end xwiki database, i can test the DAV interface via nautilus (linux file explorer) embedded WebDAV client. Only browsing is functional at this point. * I would like to commit this test framework (currently it doesn't have any of my own code) into sandbox along with a README file so that anyone can test it. But i need instructions on how to do it. Please feel free to make comments and suggestions. I'm really sorry this mail took so long, i was bit busy. Thank you all. - Asiri

17 years, 3 months

2
7
0 0

[xwiki-devs] XWikiLDAPAuthService

by Fabien

Hi again, During my search into LDAP code, I found that the xwiki.cfg check_level was removed in the new XWikiLDAPAuthService that deprecate the LDAPAuthService. It is a pity because for my pb I only need to check if the LDAP Bind is ok or not to authenticate my user, and this works perfectly (except the allocated XwikiGroup) with the old LDAP authentication mechanism. Is it possible to re-add the check_level param in the current XwikiLDAPAuthService ? Fabien

17 years, 3 months

2
3
0 0

[xwiki-devs] Failing build...

by Vincent Massol

It took me a while sorry but I think I've fixed it (building now). The pb is that the new context module was not added in Continuum. I had a problem with my user account there (I was locked out), that's why it took me some time. Sorry. Thanks -Vincent

17 years, 3 months

2
3
0 0

[xwiki-devs] aspect compilation problem under Eclipse with JAVA6.0 ???

by Pascal Voitot

Hello, I compiled the whole packages from trunk under Eclipse running with a JDK1.6_06. When I launch XWiki-Enterprise, it stops while instantiating Hibernate Storage with an error "can't find web property in XWikiDocument"... which is true because web is managed by get/setSpace... I discovered the get/setWeb is provided for compatibility by an aspect... So, I took a look at the compiled aspects and the generated .class were really smaller than the one in a JAR from the repository... After some unsucessful tries, in Eclipse, I decided to switch from java6.0 syntax to java5.0 and recompiled and then I got some .class which seemed bigger... Then I launch XWiki and it now works... Has anyone encountered the same problem? regards Pascal

17 years, 3 months

2
1
0 0

[xwiki-devs] Releasing spacemanager 1.0.1

by Jerome Velociter

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.

17 years, 3 months

1
0
0 0

[xwiki-devs] Tip for writing new component depending on xwiki-core

by Vincent Massol

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

17 years, 3 months

1
0
0 0

[xwiki-devs] [gsoc] syntax highlighting and code assistance

by malaka ekanayake

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

17 years, 3 months

2
1
0 0

[xwiki-devs] n umber of maximum BLOGS in xwiki

by Vivian Richard

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

17 years, 3 months

4
10
0 0

Re: [xwiki-devs] Refactoring Administration and Preferences

by Jean-Vincent Drean

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

17 years, 3 months

2
1
0 0

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

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/

17 years, 3 months

2
3
0 0

[xwiki-devs] [VOTE] Move new rendering code to the platform core?

by Vincent Massol

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

17 years, 3 months

6
5
0 0

[xwiki-devs] Refactoring Administration and Preferences

by Sergiu Dumitriu

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/

17 years, 3 months

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r10099 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/stats/impl

by Vincent Massol

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++) {

17 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r10097 - xwiki-platform/xwiki-tools/trunk/xwiki-verification-resources/src/main/resources

by Vincent Massol

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" />

17 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r10096 - xwiki-platform/core/trunk/xwiki-velocity/src/main/java/org/xwiki/velocity

by Vincent Massol

Hi Sergiu, Thanks for fixing my javadoc :) However our automated refactoring has some shortcomings which I've pointed below. I don't know if we can improve the IDE configuration but it would be nice to try since it generates some code that is less readable than the one we generate by hand. [snip] On Jun 4, 2008, at 3:27 AM, sdumitriu (SVN) wrote: [snip] > -public class DefaultVelocityContextFactory extends AbstractLogEnabled > - implements VelocityContextFactory, Initializable, Composable > +public class DefaultVelocityContextFactory extends > AbstractLogEnabled implements > + VelocityContextFactory, Initializable, Composable IMO it's better to keep implements on the same line as the interfaces it implements and not break it. > // Instantiate Velocity tools > if (this.properties != null) { > - for (Enumeration< ? > props = > this.properties.propertyNames(); > - props.hasMoreElements();) > - { > + for (Enumeration< ? > props = > this.properties.propertyNames(); props > + .hasMoreElements();) { This is way less readable than the version I had. Also remember that we agreed to use a curly brace on the next line for this case (i.e. when the conditions wraps). In addition I don't like how props.hasMoreElements() is cut. > // Call all components implementing the > VelocityContextInitializer's role. > try { > - for (Object interceptor > - : > this.componentManager.lookupList(VelocityContextInitializer.ROLE)) > - { > + for (Object interceptor : this.componentManager > + .lookupList(VelocityContextInitializer.ROLE)) { > ((VelocityContextInitializer) > interceptor).initialize(context); > } same here for the curly brace. > // Ensure that initialization has been called > if (this.engine == null) { > - throw new XWikiVelocityException("This Velocity Engine > has not yet been initialized. " > - + " You must call its initialize() method before > you can use it."); > + throw new XWikiVelocityException( > + "This Velocity Engine has not yet been initialized. " > + + " You must call its initialize() method > before you can use it."); I think my version is better and takes only 2 lines.

17 years, 3 months

1
0
0 0

[xwiki-devs] [proposal] Change the maximum line width in the codestyle to 128 characters

by Sergiu Dumitriu

Hi devs, Vincent said that he wanted to propose increasing the maximum line width for a while, but didn't get to do it yet. And since I want the same thing, I'm writing the proposal. So, the idea is to increase the line width to 128 (or 120? I like 128 better), since: - nice code uses descriptive variable/method names, which tend to be quite long, so many method calls span 2 or more lines - we're past the stage where developers have small displays that can only display 80 (or 100) characters at a time - right now the eclipse settings are at 98 chars, which is quite a silly number, and changing to only 100 is not worth the effort, so while we're increasing it, we can use a larger value Migration plan: - first, change the xwiki-verification-tools (next Tuesday) - we don't want to do a massive update, since it will probably create conflicts with the local changes for each developer, and break existing patches - whenever someone changes a file, he should first do a cleanup and commit the file without code changes, then a second commit with the actual behavior fix - never mix cosmetic changes with actual code affecting the behavior, as it will be hard to review that change - the copyright notice doesn't need to be updated So, everybody agrees? Do we use 120 or 128? -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 3 months

4
5
0 0

[xwiki-devs] should xwiki revert the attachment name

by Wang Ning

Hi, First, I upload a file named "the open grid service architecture.pdf" to xwiki page. Then I download it from the page. The default target file name change to "theopengridservicearchitecture.pdf" which is not friendly file name. I wonder if we can improve this. Are there big difficulties with attachment store components to do so? Thanks. -- Sincerely, Wang Ning

17 years, 3 months

1
0
0 0

[xwiki-devs] xwiki dev best practices page problem

by Vincent Massol

Hi all, I see that Ludovic has started this page http://platform.xwiki.org/xwiki/bin/view/DevGuide/Best+Practices+XWiki+Appl… However I think it should be moved to the Draft area. Right now it's very misleading and readers will think that it represents best practices that the xwiki dev team is recommending while it's not. It'll become those when we agree on them and that hasn't been done AFAIK. We could move it to the Draft area or we could start a vote on its content... WDYT? Thanks -Vincent

17 years, 3 months

5
4
0 0

[xwiki-devs] "List of Groups" property error

by shivshan

Hi If i try to add a property of type "List of Groups", i get the followng error. Is this a known issue? XWiki XE 1.4 running on Windows XP. Thanks, Shiva A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass com.xpn.xwiki.XWikiException: Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:230) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Wrapped Exception: java.lang.ClassCastException: com.xpn.xwiki.objects.meta.GroupsMetaClass at com.xpn.xwiki.web.PropAddAction.action(PropAddAction.java:56) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:204) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) -- View this message in context: http://www.nabble.com/%22List-of-Groups%22-property-error-tp17574276p175742… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 3 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs