Would be better next time to have a jira issue associated with commits
like this one, especially since you're changing something visible to
the user. Didn't you open a jira issue already when you made those
changes to DefaultDocumentAccessBridge earlier on?
BTW shouldn't this be i18ned? Are we doing that for other save messages?
Thanks
-Vincent
On Jan 7, 2009, at 7:28 AM, asiri (SVN) wrote:
> Author: asiri
> Date: 2009-01-07 07:28:11 +0100 (Wed, 07 Jan 2009)
> New Revision: 15118
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java
> Log:
> Addressing review comments.
>
> * Improced javadoc comemnts.
> * Added an editComments when changing document syntaxId
> * Prevented re-saving the XWikiDocument after calling
> doc.saveAttachmentContent()
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/DefaultDocumentAccessBridge.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-06 23:15:02 UTC (rev 15117)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-07 06:28:11 UTC (rev 15118)
> @@ -116,8 +116,10 @@
> {
> XWikiContext xcontext = getContext();
> XWikiDocument doc =
> xcontext.getWiki().getDocument(documentName, xcontext);
> + String oldSyntaxId = doc.getSyntaxId();
> doc.setSyntaxId(syntaxId);
> - xcontext.getWiki().saveDocument(doc, xcontext);
> + xcontext.getWiki().saveDocument(doc,
> + String.format("Changed document syntax from [%s] to
> [%s].", oldSyntaxId, syntaxId), xcontext);
> }
>
> /**
> @@ -241,8 +243,6 @@
> attachment.setAuthor(xcontext.getUser());
> attachment.setDoc(doc);
> doc.saveAttachmentContent(attachment, xcontext);
> - xcontext.getWiki().saveDocument(doc,
> - String.format("Added attachment [%s].",
> AttachmentName), xcontext);
> }
>
> /**
> @@ -326,6 +326,8 @@
> }
>
> /**
> + * Utility method for checking access rights of the current
> user on a target document.
> + *
> * @param documentName The name of the document.
> * @param right Access right requested.
> * @return True if the current user has the given access right,
> false otherwise.
Hi there,
I've just noticed that we have the following in distribution-test/
pom.xml:
<!-- Used only in xml-rpc tests -->
<property>
<name>pathToXWikiXar</name>
<value>com/xpn/xwiki/products/xwiki-enterprise-wiki/$
{pom.version}/xwiki-enterprise-wiki-${pom.version}.xar</value>
</property>
I don't think this is in the right place. It should be in the the
XMLRPC test's pom.xml file.
Fabio could you look into this?
Thanks
-Vincent
On Jan 6, 2009, at 5:05 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-01-06 17:05:57 +0100 (Tue, 06 Jan 2009)
> New Revision: 15098
>
> Modified:
> platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/xpn/
> xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> Log:
> XWIKI-3068 : Builtin firefox table features (add row, add col)
> messes up tables in the WYSIWYG
>
> Fixed by disabling builtin firefox table features. Merged from trunk.
>
>
>
> Modified: platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/
> com/xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> ===================================================================
> --- platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:02:23 UTC (rev 15097)
> +++ platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:05:57 UTC (rev 15098)
> @@ -85,6 +85,10 @@
> addFeature(rta, new InsertColAfter(this));
> addFeature(rta, new DeleteCol(this));
> addFeature(rta, new DeleteTable(this));
> +
> + // Disable the standard table editing features of Firefox.
> + // See XWIKI-3068 for more info.
I don't think we should put JIRA references in our code and not for
describing a solution. Rationale: we can move to another issue tracker
in the future, the issue can be moved/deleted/replace, etc.
It's better to have all the information in the source file IMO.
>
> + rta.getDocument().execCommand("enableInlineTableEditing",
> "false");
>
> getUIExtensionList().add(toolBarExtension);
> }
Thanks
-Vincent
http://xwiki.comhttp://massol.nethttp://xwiki.org
Hi Fabio
On Jan 6, 2009, at 1:46 AM, fmancinelli (SVN) wrote:
> Author: fmancinelli
> Date: 2009-01-06 01:46:26 +0100 (Tue, 06 Jan 2009)
> New Revision: 15087
>
> Added:
> sandbox/xwiki-core-rest/src/main/java/components/
> sandbox/xwiki-core-rest/src/main/java/components/org/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> SpacesResource.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResource.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResourceFinder.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResourceRepresenter.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiRestApplication.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiRestletServlet.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/PlainTextSpacesRepresenter.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/XmlTextSpacesRepresenter.java
> Modified:
> sandbox/xwiki-core-rest/src/main/resources/META-INF/plexus/
> components.xml
> Log:
> Added a fully componentized version of the REST infrastructure.
>
> Now resources and "representers" (i.e., objects that are in charge
> for representing a given resource for a given media type) are
> declared through components.xml and automatically registered:
>
> 1) At the application level routes are created for all the
> components declaring the org.xwiki.rest.XWikiResource role. The role
> hint defines the uri template.
>
> 2) Representers components are associated to resource components by
> looking at the role hint (which should reflect the resource a given
> representer is associated to)
[snip]
> + restApplication = (XWikiRestApplication)
> componentManager.lookup(applicationClass);
> +
> +
> restApplication.setName(getServletConfig().getServletName());
> + restApplication.setContext(new
> ServletContextAdapter(this, context));
> +
> restApplication
> .getContext().setLogger(restApplication.getClass().getName());
Looks good in general.
Just making sure: is createApplication() and hence the code above
executed only once?
All components you've created are singletons so you need to be careful
that they don't hold state or if they do (as above) then this needs to
be a state that is common for all threads and thus only initialized
once for the entire app lifetime.
[snip]
Thanks
-Vincent
Howdy,
I've checked out the source code HEAD revision from:
http://svn.xwiki.org/svnroot/xwiki/platform/trunks
I've installed Maven, setup my .../.m2/settings.xml, and am running "mvn
-Pwindows install".
The build seems to proceed part way, then one of the tests fails:
Running com.xpn.xwiki.tool.xar.XarMojoTest
[info] Using the existing package.xml descriptor at
[C:\temp\xwiki\tools\xwiki-x
ar-plugin\target\test-classes\malformedXml\src\main\resources\package.xml]
[error] The existing package.xml is invalid.
java.lang.Exception: The supplied document contains no document list
at
com.xpn.xwiki.tool.xar.XarMojo.getDocumentNamesFromXML(XarMojo.java:2
72)
at
com.xpn.xwiki.tool.xar.XarMojo.addFilesToArchive(XarMojo.java:321)
at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:124)
at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:76)
Any ideas?
--
View this message in context: http://n2.nabble.com/Build-error-of-fresh-checkout-on-Windows-Vista-tp21117…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
Hi devs,
This is not a priority (we need to finish our first stable release of
the WYSIWYG editor first) but I wanted to propose 2 things and start a
discussion on it:
* That we make our new GWT WYSIWYG editor a top level project (i.e.
with a separate jira, separate wiki like http://wysiwyg.xwiki.org with
a better name, etc)
* Make it usable by someone who is not using XWiki
The rationale is:
* If we want our editor to become strong and compete with the likes of
FCKEditor/TinyMCE we need to open it up to others and for that we need
to:
- advertise it (hence the http://wysiwyg.xwiki.org that would lists
all features same as http://www.fckeditor.net/)
- make it be usable easily and thus without dragging xwiki dependencies
Other options:
1) Don't do anything. Cons: we won't get enough help and it'll be hard
to compete with other editors. They'll have more features/less bugs
and we'll have a hard time keeping up. In addition it's possible
someone else creates a new GWT WYSIWYG editor and it would be better
if we could all join force on that and using what we have started
2) Externalize it on some forge other than the xwiki forge. This is
nice from a marketing point of view (i.e. easier to show it as a pure
wysiwyg editor) but it has some drawbacks:
- further from the xwiki community and thus harder for us to maintain
it there
- doesn't strengthen our xwiki project
In addition, what we need to evaluate is how do we make it independent
of xwiki and how long would that take. This is probably more a
question for Marius. Marius this is not urgent compared to the 1.7.1
release. Whenever you have time.
Thanks
-Vincent