Hello,
Thanks for your feedback and your suggestions.
I have made modifications in the survey. Here is the last version:
http://www.xwiki.org/xwiki/bin/view/Main/Survey
What do you think about it?
Thanks.
Emilie
On Feb 26, 2009, at 10:43 PM, Marius Dumitru Florea wrote:
>/ Hi Emilie,
/>/
/>/ Sergiu Dumitriu wrote:
/>>/ Emilie Ogez wrote:
/>>>/ Hello,
/>>>/
/>>>/ My name is Émilie Ogez. I am the marketing and communication
/>>>/ manager at
/>>>/ XWiki SAS (the company supporting the XWiki.org Open-Source
/>>>/ project).
/>>>/
/>>>/ I've given a look at the current XWiki.org website and I think
/>>>/ there's
/>>>/ room for improvement. I'd be glad to:
/>>>/
/>>>/ * help improving the design and content of the XWiki.org website
/>>>/ * suggest animation ideas for the XWiki Developers community
/>>>/ * help improving XWiki products by gathering user feedback
/>>>/
/>>>/ In order to do this, I would like to publish 2 online surveys on
/>>>/ XWiki.org:
/>>>/
/>>>/ * a survey asking users about what they think of the current
/>>>/ XWiki.org website (do they find content easily, is it
/>>>/ intuitive to
/>>>/ use)
/>>>/ * a survey asking users about how they're using XWiki products
/>>>/ and
/>>>/ how we could improve our product range
/>>>/
/>>>/ I started with the survey about XWiki.org. I'd like to send it to
/>>>/ people
/>>>/ from the Devs & Users list and to make it available to XWiki.org
/>>>/ visitors. Survey answers would help us improve the website and
/>>>/ make it
/>>>/ more effective and attractive for the XWiki.org community.
/>>>/
/>>>/ Here's the survey contents I suggest:
/>>>/ http://www.xwiki.org/xwiki/bin/view/Main/Survey. I'd be glad to
/>>>/ get your
/>>>/ feedback about it about it before putting it online.
/>>/
/>>/ The yes/no options should not be checkboxes, but radio buttons.
/>>/
/>>/ Apart from quantity and quality, we should also ask about the
/>>/ information organization, ease of use, ease of access.
/>/
/>/ I agree with Sergiu. I too think the survey should have more questions
/>/ and maybe we should let users give marks (from 1-bad to 5-exceptional,
/>/ or something similar) and not just yes/no answers. I'm not a survey
/>/ expert though.
/
I agree with Marius you should never ask for yes/no (you won't know
what to do with the result) but a scale of 1-5 instead.
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi
When i try to export a page in pdf , i have this error : (i use XWiki
Enterprise 1.6.1.13621 )
Error number 11015 in 11: Exception while exporting
Wrapped Exception: Error number 12003 in 12: XSL Transformation Failed
Wrapped Exception: Premature end of file.
com.xpn.xwiki.XWikiException: Error number 11015 in 11: Exception while exporting
Wrapped Exception: Error number 12003 in 12: XSL Transformation Failed
Wrapped Exception: Premature end of file.
at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:64)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:216)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
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.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
--
Antoine SEILLES
Doctorant (phd student)
LIRMM CNRS
Président de l'association imagiLAB
LIRMM CNRS:
UMR 5506 - 161 rue Ada
34392 Montpellier Cedex 5
FRANCE
www.lirmm.fr
Association imagiLAB
apt D22 Mas du Cavalier,
365 quai louis le vau
34080 Celleneuve
www.imagilab.fr
Tel: +33 (0)6 10 192 055
antoine(a)imagilab.fr
antoineseilles(a)gmail.com
Antoine.seilles(a)lirmm.fr
Hello,
My name is Émilie Ogez. I am the marketing and communication manager at
XWiki SAS (the company supporting the XWiki.org Open-Source project).
I've given a look at the current XWiki.org website and I think there's
room for improvement. I'd be glad to:
* help improving the design and content of the XWiki.org website
* suggest animation ideas for the XWiki Developers community
* help improving XWiki products by gathering user feedback
In order to do this, I would like to publish 2 online surveys on XWiki.org:
* a survey asking users about what they think of the current
XWiki.org website (do they find content easily, is it intuitive to
use)
* a survey asking users about how they're using XWiki products and
how we could improve our product range
I started with the survey about XWiki.org. I'd like to send it to people
from the Devs & Users list and to make it available to XWiki.org
visitors. Survey answers would help us improve the website and make it
more effective and attractive for the XWiki.org community.
Here's the survey contents I suggest:
http://www.xwiki.org/xwiki/bin/view/Main/Survey. I'd be glad to get your
feedback about it about it before putting it online.
Thanks,
Émilie
Hi,
I just realized, the password recovery function unveils a user's password.
In a wiki with registration, and Email verification, where the XWiki
space must currently be enabled to be viewed by everybdy, this could
be used by spammers(and others who like to collect email addresses) to
harvest email addresses by caling the resetpassword function for every
user they see on the "AllUsers" page.
I'd propose to not show the Email address to which a password reminder is sent.
Henning
--
Henning Sprang
http://www.sprang.de | http://lazyb0y.blogspot.com/
Hi Asiri,
On Feb 23, 2009, at 1:37 PM, asiri (SVN) wrote:
> Author: asiri
> Date: 2009-02-23 13:37:50 +0100 (Mon, 23 Feb 2009)
> New Revision: 16999
>
> Modified:
> platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/
> officeimporter/internal/cleaner/OpenOfficeHTMLCleanerTest.java
> Log:
> XWIKI-3259: Table headers are not handled properly
>
> * Added a unit test.
[snip]
> /**
> + * Test proper cleaning of {@code <th>} elements.
> + */
> + public void testTableHeaderItemCleaning()
> + {
> + // Isolated paragraph elements inside 'th' elements should
> be removed.
> + String html =
> + header + "<table><thead><tr><th><p>Test</p></th></tr></
> thead><tbody><tr><td/></tr></tbody></table>"
> + + footer;
> + Document doc = cleaner.clean(new StringReader(html));
> + NodeList nodes = doc.getElementsByTagName("th");
> + Node hearderItemContent = nodes.item(0).getFirstChild();
> + assertEquals(Node.TEXT_NODE,
> hearderItemContent.getNodeType());
> + assertEquals("Test", hearderItemContent.getNodeValue());
Why is this only for th and not for td cells too?
Is this specific to the office importer? It looks very generic to me,
isn't it?
Why do paragraphs need to be removed?
What if there are 2 paragraphs elements? what happens? Do you have a
test for that too?
Thanks
-Vincent
Hi there,
I am using java with XmlRPC to connect and send xml messages to a payment
gateway.
- My main issue is that the payment gateway accepts the requests in a
specific format like:
<merchantid>1234567</merchantid>
<account>testaccount</testaccount>
<card>
<number>....and so on
So can anyone help me on how to send xml using this format through xmlrpc. i
have checked struct but that also does not meet my requirement.
- Also is there anyway to trap the request and response message form xmlrpc
as this would help in testing.
- Apart from this does the payment gateway also need to have a xmlrpc
server. Would my XmlRPC request work if it is not?
Please help
Thanks in advance.
--
View this message in context: http://n2.nabble.com/Issues-with-XmlRPC-tp2377960p2377960.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
Due to some critical bugs and missing features, the release was
postponed for a long period.
Still the development process is way ahead of what was intended for
XWord 1.0
This is how the old roadmap looked like:
http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversi…
As you can see XWord 1.0 was intended to be an export to wiki tool and
only XWord 1.1 should enable editing wiki pages.
Sorry for not keeping you up to date on the mailing list.
This is the new roadmap for XWord:
- 1.0 M1
- Wiki Explorer - done
- Attachment Upload - done
- Attachment Download - done
- Export word documents - done
- Edit/Save wiki pages - done
- Save pages with user specified syntax - done
- Protect essential pages from editing - done
- Export using filtered html - done
- Export with non-filtered html - buggy
- Deployment and infrastructure - problematic because it uses ClickOnce.
- 1.0 M2 - 2-3 weeks from M1
- Solve as many reported bugs
- Improve html filters
- Introduce the XML-RPC communication mode
- Basic macro support(prevent the user from editing macro generated
html)
- 1.0 RC1 - 1-2 weeks from M2
- Bug fixing
- Stable and ergonomic UI
- Remove the sever package and rely only on XML-RPC
- 1.0 Final - 1-2
- Rock solid UI
- Production quality html output and wiki syntax conversion.
Please tell me your opinion.
Thanks,
Florin
vmassol (SVN) wrote:
> Author: vmassol
> Date: 2009-02-22 20:24:02 +0100 (Sun, 22 Feb 2009)
> New Revision: 16991
>
> Modified:
> platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> platform/core/branches/xwiki-core-1.8/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java
> Log:
> XWIKI-3228: Error while saving xwiki 2.0 documents containing anchor links
>
> Fixed bugs introduced in rev 16482 (XWIKI-281) for XWiki Syntax 2.0. The underlying code is pretty flaky and there are other potential errors in the code...
>
> Merged from trunk (rev 16990)
>
> Modified: platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> ===================================================================
> --- platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-02-22 18:11:58 UTC (rev 16990)
> +++ platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-02-22 19:24:02 UTC (rev 16991)
> + // Verify that the link is not an autolink (i.e. a link to the current document) and only add
> + // if the link is not already in the list.
> + // TODO: Would be better to use a Set instead of a Link but this needs to change the API and I'm
s/Link/List
Also, can't you use a Set internally and transform it to a list at the
end? Does a Set provide better performance than List.contains?
> + // not ready to risk this right now: Vincent Massol, 22/02/2009 close to the 1.8RC2 release...
> + if (!document.getFullName().equals(getFullName()) && !pageNames.contains(document.getFullName())) {
> + pageNames.add(document.getFullName());
> + }
--
Sergiu Dumitriu
http://purl.org/net/sergiu/