xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

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/

16 years, 8 months

[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

16 years, 8 months

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

16 years, 8 months

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

16 years, 8 months

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

16 years, 8 months

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.

16 years, 8 months

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

16 years, 8 months

[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

16 years, 8 months

[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

16 years, 8 months

[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.

16 years, 8 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