On Fri, Jul 10, 2009 at 09:41, Vincent Massol<vincent(a)massol.net> wrote:
>
> On Jul 4, 2009, at 2:44 PM, tmortagne (SVN) wrote:
>
>> Author: tmortagne
>> Date: 2009-07-04 14:44:30 +0200 (Sat, 04 Jul 2009)
>> New Revision: 21811
>>
>> Modified:
>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> Document.java
>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> XWiki.java
>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
>> XWikiDocument.java
>> Â platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api/
>> XWikiTest.java
>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/internal/renderer/
>> DefaultPrintRendererFactory.java
>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/parser/Syntax.java
>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/parser/SyntaxType.java
>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/renderer/PrintRendererFactory.java
>> Â platform/web/trunk/standard/src/main/webapp/templates/contentview.vm
>> Â platform/web/trunk/standard/src/main/webapp/templates/plain.vm
>> Log:
>> XWIKI-4042: Add a way to choose the renderer when viewing a page
>
>>
>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
>> api/Document.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> Document.java 2009-07-04 12:42:14 UTC (rev 21810)
>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> Document.java 2009-07-04 12:44:30 UTC (rev 21811)
>> @@ -37,6 +37,7 @@
>> import org.suigeneris.jrcs.diff.DifferentiationFailedException;
>> import org.suigeneris.jrcs.diff.delta.Delta;
>> import org.suigeneris.jrcs.rcs.Version;
>> +import org.xwiki.rendering.parser.Syntax;
>>
>> import com.xpn.xwiki.XWiki;
>> import com.xpn.xwiki.XWikiContext;
>> @@ -473,6 +474,16 @@
>> Â Â }
>>
>> Â Â /**
>> + Â Â * @param targetSyntax the syntax in which render the document
>> content
>> + Â Â * @return the rendered content
>> + Â Â * @throws XWikiException error when rendering content
>> + Â Â */
>> + Â Â public String getRenderedContent(Syntax targetSyntax) throws
>> XWikiException
>> + Â Â {
>> + Â Â Â Â return this.doc.getRenderedContent(targetSyntax,
>> getXWikiContext());
>> + Â Â }
>
> Since this is for Velocity, isn't it better to use a syntax Id String
> instead of a Syntax object which is hard to construct from velocity?
The problem is that it was not easy to find a right signature since
there is already getRenderedContent taking string fo the parser
syntax. Since anyway it's necessary to give a supported syntax by
looking at existing one it was easier to not have to directly give the
found valid syntax object.
>
>> +
>> + Â Â /**
>> Â Â Â * return a escaped version of the content of this document
>> Â Â Â */
>> Â Â public String getEscapedContent() throws XWikiException
>>
>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
>> api/XWiki.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> XWiki.java   2009-07-04 12:42:14 UTC (rev 21810)
>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>> XWiki.java   2009-07-04 12:44:30 UTC (rev 21811)
>> @@ -30,6 +30,8 @@
>> import org.apache.commons.logging.LogFactory;
>> import org.suigeneris.jrcs.diff.delta.Chunk;
>> import org.xwiki.query.QueryManager;
>> +import org.xwiki.rendering.parser.Syntax;
>> +import org.xwiki.rendering.renderer.PrintRendererFactory;
>>
>> import com.xpn.xwiki.XWikiContext;
>> import com.xpn.xwiki.XWikiException;
>> @@ -2685,4 +2687,42 @@
>> Â Â {
>> Â Â Â Â return this.xwiki.getDefaultDocumentSyntax();
>> Â Â }
>> +
>> + Â Â /**
>> + Â Â * Find the corresponding available renderer syntax.
>> + Â Â * <p>
>> + Â Â * If <code>syntaxVersion</code> is null the last version of
>> the available provided syntax type is returned.
>> + Â Â *
>> + Â Â * @param syntaxType the syntax type
>> + Â Â * @param syntaxVersion the syntax version
>> + Â Â * @return the available corresponding {@link Syntax}. Null if
>> no available renderer can be found.
>> + Â Â */
>> + Â Â public Syntax getAvailableRendererSyntax(String syntaxType,
>> String syntaxVersion)
>> + Â Â {
>> + Â Â Â Â Syntax syntax = null;
>> +
>> + Â Â Â Â PrintRendererFactory printRendererFactory =
>> + Â Â Â Â Â Â (PrintRendererFactory)
>> Utils.getComponent(PrintRendererFactory.class);
>> +
>> + Â Â Â Â List<Syntax> availableSyntaxes =
>> printRendererFactory.getAvailableSyntaxes();
>
> We already have the notion of available syntaxes in the SyntaxFactory.
No, we have the notion of available parsers, the method name is just
wrong in SyntaxFactory... The only place where we know the available
renderers is the PrintRendererFactory since it's impossible to get all
renderers otherwise until renderer are made components.
> I don't understand why we need to have them in the
> PrintRendererFactory (which is not supposed to return syntaxes BTW,
> it's only supposed to return PrintRenderer(s).
>
>> +
>> + Â Â Â Â for (Syntax availableSyntax : availableSyntaxes) {
>
> Why not instead do:
> SyntaxType syntaxType = SyntaxType.getSyntaxType(syntaxTypeAsString);
>
> And then (when syntaxVersion != null):
> Syntax syntax = new Syntax(syntaxType, syntaxVersion);
>
> And then:
> syntaxFatory.getAvailableSyntaxes().contains(syntax)
It's not that simple since we have to support the use case where
syntaxVersion is not given (which is most of the time).
>
> hmmm.... Actually thinking more about it, I believe this whole code
> should be moved out of XWikiDocument and instead go in the rendering
> module in SyntaxFactory.
Again in SyntaxFactory you have no idea what are the available
renderers syntaxes and here we don't care about parsers.
Until we have clean renderer componet my goal was to put as less as
possible temporary code in rendering module.
>
>> + Â Â Â Â Â Â if (syntaxVersion != null) {
>> + Â Â Â Â Â Â Â Â if
>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType)
>> + Â Â Â Â Â Â Â Â Â Â &&
>> availableSyntax.getVersion().equals(syntaxVersion)) {
>> + Â Â Â Â Â Â Â Â Â Â syntax = availableSyntax;
>> + Â Â Â Â Â Â Â Â Â Â break;
>> + Â Â Â Â Â Â Â Â }
>> + Â Â Â Â Â Â } else {
>> + Â Â Â Â Â Â Â Â // TODO: improve version comparaison since it does
>> not work when comparing 2.0 and 10.0 for example. We
>> + Â Â Â Â Â Â Â Â // should have a Version which implements
>> Comparable like we have SyntaxId in Syntax
>> + Â Â Â Â Â Â Â Â if
>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType)
>> + Â Â Â Â Â Â Â Â Â Â && (syntax == null ||
>> availableSyntax.getVersion().compareTo(syntax.getVersion()) > 0)) {
>> + Â Â Â Â Â Â Â Â Â Â syntax = availableSyntax;
>> + Â Â Â Â Â Â Â Â }
>> + Â Â Â Â Â Â }
>> + Â Â Â Â }
>> +
>> + Â Â Â Â return syntax;
>> + Â Â }
>> }
>
> [snip]
>>
>> Â Â /**
>> + Â Â * @return the syntax of the document
>> + Â Â */
>> + Â Â private Syntax getSyntax()
>> + Â Â {
>> + Â Â Â Â Syntax syntax = null;
>> +
>> + Â Â Â Â String syntaxId = getDefaultDocumentSyntax();
>> + Â Â Â Â try {
>> + Â Â Â Â Â Â syntax =
>> this.syntaxFactory.createSyntaxFromIdString(getSyntaxId());
>
> Shouldn't we save the Syntax object instead of syntaxId in
> XWikiDocument so that we don't perform the conversion every time
> getSyntax is called?
I did not planed to refactor the whole XWikiDocument, i just done what
was needed but at some point yes we should have Syntax and XDOM
instead of the syntax/content strings :)
>
>> + Â Â Â Â } catch (ParseException e) {
>> + Â Â Â Â Â Â LOG.error("Failed to genrate Syntax object for syntax
>> identifier [" + syntaxId + "] in page ["
>
> Typo: generate
>
>> + Â Â Â Â Â Â Â Â + getDocumentName() + "]", e);
>> +
>> + Â Â Â Â Â Â syntaxId = getDefaultDocumentSyntax();
>
> I don't understand this line above, it's the same as the one a few
> lines above.
>
>> + Â Â Â Â Â Â try {
>> + Â Â Â Â Â Â Â Â syntax =
>> this
>> .syntaxFactory.createSyntaxFromIdString(getDefaultDocumentSyntax());
>
> It seems you're not using the syntaxId variable.
Yes it's an error, I added the variables when added the error message
and forgot to change the "real" code properly.
>
>> + Â Â Â Â Â Â } catch (ParseException e1) {
>> + Â Â Â Â Â Â Â Â LOG.error("Failed to genrate default Syntax object.
>> The defautlt syntax id in [" + syntaxId + "]", e);
>
> same typo
>
> [snip]
>
>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
>> pom.xml
>> ===================================================================
>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>> 2009-07-04 12:42:14 UTC (rev 21810)
>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>> 2009-07-04 12:44:30 UTC (rev 21811)
>> @@ -187,7 +187,9 @@
>> Â Â Â Â Â Â Â Â <!-- Excludes for the 2.0 M2 release. Once it's
>> released remove them. -->
>> Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/MacroManager</
>> exclude>
>> Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/MacroSource</
>> exclude>
>> - Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/
>> AbstractMacroSource</exclude>
>> + Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/
>> AbstractMacroSource</exclude>
>> + Â Â Â Â Â Â Â Â <!-- Seems clirr plugin consider adding new API as
>> an error (which I don't understand). -->
>
> It doesn't normally (it' considered as an INFO level) unless it breaks
> binary compatibility. But I don't know why in your case (would need to
> check more the code, i'm only looking at the svn diff).
If you remove this the plugin clearly say that there is an error and
it also clearly say that the error is that there is new api in
PrintRendererFactory. Maybe the error message is wrong but i check and
rechecked and this is the only difference.
>
>> + Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/renderer/
>> PrintRendererFactory</exclude>
>> Â Â Â Â Â Â Â </excludes>
>> Â Â Â Â Â Â </configuration>
>> Â Â Â Â Â </execution>
>>
>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
>> src/main/java/org/xwiki/rendering/internal/renderer/
>> DefaultPrintRendererFactory.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/internal/renderer/
>> DefaultPrintRendererFactory.java    2009-07-04 12:42:14 UTC (rev 21810)
>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>> java/org/xwiki/rendering/internal/renderer/
>> DefaultPrintRendererFactory.java    2009-07-04 12:44:30 UTC (rev 21811)
>> @@ -19,6 +19,10 @@
>> Â */
>> package org.xwiki.rendering.internal.renderer;
>>
>> +import java.util.Arrays;
>> +import java.util.Collections;
>> +import java.util.List;
>> +
>> import org.xwiki.component.annotation.Component;
>> import org.xwiki.component.annotation.Requirement;
>> import org.xwiki.rendering.parser.Syntax;
>> @@ -43,6 +47,10 @@
>> @Component
>> public class DefaultPrintRendererFactory implements
>> PrintRendererFactory
>> {
>> + Â Â private static final List<Syntax> AVAILABLE_SYNTAXES =
>> +
>> Collections.unmodifiableList(Arrays.asList(Syntax.XHTML_1_0,
>> Syntax.XWIKI_2_0, Syntax.EVENT_1_0,
>> + Â Â Â Â Â Â Syntax.TEX_1_0, Syntax.PLAIN_1_0));
>
> I don't like this, see above.
Again it's a factory, it's the only place where we really now what are
the renderers. I don't like this either but since renderer are not
component there is no choice.
>
>> +
>> Â Â /**
>> Â Â Â * Factory to easily create an XHTML Image and Link Renderers.
>> Â Â Â */
>> @@ -55,6 +63,16 @@
>> Â Â /**
>> Â Â Â * {@inheritDoc}
>> Â Â Â *
>> + Â Â * @see
>> org
>> .xwiki.rendering.renderer.PrintRendererFactory#getAvailableSyntaxes()
>> + Â Â */
>> + Â Â public List<Syntax> getAvailableSyntaxes()
>> + Â Â {
>> + Â Â Â Â return AVAILABLE_SYNTAXES;
>> + Â Â }
>> +
>
> I don't like this, see above.
>
> [snip]
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
I like this. Shouldn't we also remove the automatic creation of Tag
objects in all documents by default?
I have never understood why we do this for Tags and not for Rights,
and all other objects. For me the objects should be created only when
required and not by default.
Thanks
-Vincent
On Jul 4, 2009, at 5:22 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-07-04 17:22:41 +0200 (Sat, 04 Jul 2009)
> New Revision: 21818
>
> Modified:
> platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/
> plugin/tag/TagPlugin.java
> Log:
> XATAG-20: Adding tags fails when there is no Tag object attached to
> the document
> Fixed.
>
> Modified: platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/
> xwiki/plugin/tag/TagPlugin.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/
> plugin/tag/TagPlugin.java 2009-07-04 15:22:34 UTC (rev 21817)
> +++ platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/
> plugin/tag/TagPlugin.java 2009-07-04 15:22:41 UTC (rev 21818)
> @@ -29,12 +29,18 @@
>
> import org.apache.commons.collections.CollectionUtils;
> import org.apache.commons.lang.StringUtils;
> +import org.apache.commons.logging.Log;
> +import org.apache.commons.logging.LogFactory;
>
> import com.xpn.xwiki.XWikiContext;
> import com.xpn.xwiki.XWikiException;
> import com.xpn.xwiki.api.Api;
> import com.xpn.xwiki.doc.XWikiDocument;
> +import com.xpn.xwiki.objects.BaseObject;
> import com.xpn.xwiki.objects.BaseProperty;
> +import com.xpn.xwiki.objects.DBStringListProperty;
> +import com.xpn.xwiki.objects.classes.BaseClass;
> +import com.xpn.xwiki.objects.classes.PropertyClass;
> import com.xpn.xwiki.plugin.XWikiDefaultPlugin;
> import com.xpn.xwiki.plugin.XWikiPluginInterface;
>
> @@ -45,6 +51,9 @@
> */
> public class TagPlugin extends XWikiDefaultPlugin implements
> XWikiPluginInterface
> {
> + /** Logging helper object. */
> + public static final Log LOG = LogFactory.getLog(TagPlugin.class);
> +
> /**
> * The identifier for this plugin; used for accessing the plugin
> from velocity, and as the action returning the
> * extension content.
> @@ -116,10 +125,40 @@
> private void setDocumentTags(XWikiDocument document,
> List<String> tags, XWikiContext context)
> {
> BaseProperty prop = (BaseProperty)
> document.getObject(TAG_CLASS, true, context).safeget(TAG_PROPERTY);
> + // Properties aren't added to an object unless a value is
> specified either from the Web or from an XML.
> + if (prop == null) {
> + prop = createTagProperty(document.getObject(TAG_CLASS,
> true, context), context);
> + }
> prop.setValue(tags);
> }
>
> /**
> + * Create and add the main tag property to the provided tag
> object. The new property corresponds to the definition
> + * in the tag class, but in case of an error, the default type
> is a relational-stored list.
> + *
> + * @param tagObject the target tag object
> + * @param context the current request context
> + * @return the created property
> + * @see #TAG_PROPERTY
> + */
> + private BaseProperty createTagProperty(BaseObject tagObject,
> XWikiContext context)
> + {
> + BaseProperty tagProperty;
> + try {
> + BaseClass tagClass =
> context.getWiki().getClass(TAG_CLASS, context);
> + PropertyClass tagPropertyDefinition = (PropertyClass)
> tagClass.getField(TAG_PROPERTY);
> + tagProperty = tagPropertyDefinition.newProperty();
> + } catch (XWikiException ex) {
> + LOG.warn("Failed to properly create tag property for
> the tag object, creating a default one");
> + tagProperty = new DBStringListProperty();
> + }
> + tagProperty.setName(TAG_PROPERTY);
> + tagProperty.setObject(tagObject);
> + tagObject.safeput(TAG_PROPERTY, tagProperty);
> + return tagProperty;
> + }
> +
> + /**
> * Get all tags within the wiki.
> *
> * @param context XWiki context.
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
I've implemented the simplest EventListener possible by just implementing the EventListener required methods, adding an @Component("mystartup") line and adding my class to components.txt.
However, on startup I get an error Failed to lookup component [role = [org.xwiki.observation.ObservationManager] hint = [default]]
What am I missing? Is this a chicken and egg problem?
@Component("mystartup")
public class MyStartup implements EventListener {
public List<Event> getEvents() {
return Arrays.asList(new ApplicationStartedEvent(), new ApplicationStoppedEvent());
}
public String getName() {
return "mystartup";
}
public void onEvent(Event arg0, Object arg1, Object arg2) {
// TODO Auto-generated method stub
}
java.lang.RuntimeException: Failed to find the Observation Manager component
at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:79)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:523)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.observation.ObservationManager] hint = [default]]
at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:263)
at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:93)
at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:76)
... 22 more
Caused by: java.lang.NullPointerException
at org.xwiki.observation.internal.DefaultObservationManager.addListener(DefaultObservationManager.java:157)
at org.xwiki.observation.internal.DefaultObservationManager.initialize(DefaultObservationManager.java:128)
at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328)
at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:254)
... 24 more
Hi Devs,
This is because of several reasons,
1. Having one wiki macro per wiki page makes it clean to group a single
WikiMacroClass object and several WikiMacroParameterClass objects together
and we do not need to keep a reference from WikiMacroParameterClass objects
as to which macro in belongs to.
2. It makes the wiki macro registration / updating easy. I mean we only need
to track document save / update events involving WikiMacroClass objects. On
the other hand if we allow WikiMacros to have their parameters defined in
some other documents, things get a little complex.
3. This will make wiki macro presentation easy. We can define a sheet that
will present a single wiki macro (inside a single wiki page) in a unque
manner to the user. This sheet will not have to bother about other wiki
macros in the same document or worry about wiki macro parameters located
elsewhere.
WDYT?
Thanks.
- Asiri
Hi,
Is there a way to get all the values for the properties of an object
attached to a page? For example, in my case, I need to get all the
properties that were defined and their values for an object which belongs to
XWiki.XWikiUsers class, given the name of the document (that the object
belongs to).
>From my component I use DocumentAccessBridge, but the only methods to get
properties values are the ones like:
public String getProperty(String documentName, String className, String
propertyName)
Is there a more elegant way to get all of them, besides calling
.getProperty() for each of the property names ? Or, is there a way to get
all the properties defined for a class? (i.e. for the XWiki.XWikiUsers
class).
Are there any other components which provide access to the data model? From
what I understood from here [0], the XWiki data model resides in the old
xwiki-core module, therefore must be used a bridge (like
DocumentAccessBridge).
[0] -
http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents#HTheXWi…
Thanks a lot,
Anamaria
Marius Dumitru Florea wrote:
> Hi Anca,
>> + /**
>> + * Builds a selector from a list of pages of the specified page.
>> + *
>> + * @param editedResource the currently edited resource (page for which editing is done)
>> + */
>> + public AbstractPageListSelectorWizardStep(ResourceName editedResource)
>> + {
>
>> + super();
>
> Isn't this called by default?
Yes, by default the super constructor with no parameters is called, so
this line is not needed. It makes sense to call super only when calling
a constructor with parameters.
>> + return LinkWizardSteps.WIKIPAGECREATOR.toString();
>
> Since I can't use camelcase on constant names I use an underscore
> instead to separate words: WIKI_PAGE_CREATOR. I don't know if this is a
> code style convension but it is surely more readable.
Yes, this is how it should be done. I'll add it on
http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle a bit later.
Related, I'd like to change the codestyle to allow two consecutive
underscores to better separate chunks of the name, like a kind of
prefix: DOC_COMMENT__TAG_ADDED, DOC_COMMENT__TAG_REMOVED...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi all,
You can test the latest xeclipse code by following the README here :-
http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/xeclipse/README
The status of the features completed is here:-
http://gsoc.myxwiki.org/xwiki/bin/view/XEclipse/
The svn log gives a more detailed explanation of features.
http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/xeclipse/log [svn log copy]
The bugs I already know of are written in readme.
Please let me know how you think the features have shaped up till now, and
of course if you find any bugs.
Suggestions for more possible features to the Navigator also welcome.
A crude approximation gave me the statistic that I've added upto 7.56% of
1.2rc1 xeclipse codebase.
Venkatesh Nandakumar
Department of Electronics & Computer Engineering
Indian Institute of Technology Roorkee
Hello,
For example, I have a space "Space"
and I want to create a doc "mydoc.name" in it
I do xwiki.getDocument("Space.mydoc.name")
but it creates a space "Space.mydoc" and a doc with name "name"
is it possible to do that?
Pascal