Hi fellow XWikiers,
I've been spending some time thinking about the new User Interface we might
want to build for the new WYSIWYG editor. I've posted the ideas I gathered
so far on this page :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface .
I'd be glad to get some feedback either on the list or in comments right on
the page in order to see whether any given approach clinches or clashes with
your own conceptions of a great rich text editor.
Please bear in mind that I'll probably be adding content to the page on a
regular basis in days to come in order to account for the feedback received
- if any.
In case of an absence of feedback, well, I guess we'll be able to assume
safely that the new WYSIWYG editor doesn't matter that much in the end and
stop its development altogether ;-)
Looking forward hearing from you guys (and girls),
Guillaume
Hi,
While exporting the page to PDF format i got this error. And not able
to export the page.
Kindly any one tell me what's this error. And how to solve this problem.
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:189)
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:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
--
Prathap
Hi,
Though office converter can convert office documents to many format, I
think only some conversion is useful:
1). convert office document to html (view attachment as html)
2). export a page to office document(MS Word, OpenOffice odt), as influence do.
3). export a page to pdf, but this have been done with fop. I don't
think xwiki should have two way to export pdf.
4). convert office document to html then parse to xwiki syntax. (this
is the most important goal, but I still be learn how to)
I can product the low level interface for multi format conversion, but
now I only focus on the 1), 4), 2) fuctions.
Actually, I'm working on the "view as html". My step:
1. add a method in XWiki Util or Office converter plugin(Which is
better) "boolean canViewAsHTML(OfficeDocumenType)" to check if the
attachment can view as a html.
2. add a action "viewashtml" to xwiki action map. to handle the "view
as html" request
3. modify the attachmentinline.vm. use
"$doc.getAttachmentURL("${attach.filename}", "viewashtml",
"xredirect=${redirect}")" as "view as html" link.
WDYT?
Thanks.
Wang Ning
Hi all,
Now I've completed (committed to the sandbox) the syntax colouring for most
of the Velocity syntax. The colours used are not yet finalized. We are yet
to develop colour scheme for both Xiki and Velocity syntax. Your suggestions
for appropriate colours are welcome.
I've identified following tasks which are to be completed.
1) support for user defined macros in Velocity
2) Enhance the Xwiki content assistance.
3) Implement the Velocity content assistance
4) Implement the Xwiki and Velocity error handling
AFAIS, for the 4th task we have to integrate Xwiki and Velocity parsers to
get the error messages and to find the excat location of the error. Your
comments are welcom on this.
I would like to suggest following changes to the existing package sturcture
of xeclipse plugin. Now this editor plugin supports different languages, I
think refactoring of the package stucture is needed. For the moment, I've
included Velocity related classes under the following package name.
org.xwiki.eclipse.ui.editors.velocity.*
And also several other classes has been modified provide syntax coloring for
Velocity. So my suggetion is to put all the Xwiki related classes under the
following package name.
org.xwiki.eclipse.ui.editors.xwiki.*
Then the common classes can be put in the org.org.xwiki.eclipse.ui.editors
and org.xwiki.eclipse.ui.editors.util packages.
WDYT?
Thanks
Malaka
Hi,
We need to better organize our SVN repos. Some current needs/issues:
* Curriki needs its own svn location outside of main xwiki devs
* Chrono is currently outside of the main svn repo. Same for Sandbox.
* We'd like to offer a forge for xwiki -related project (for example
for the xlet project)
We had a discussion before and I think we agreed to have a single SVN
repo vs one for each project.
See http://tinyurl.com/69c4bx for more details.
Hence I propose the following new structure:
https://svn.xwiki.org/svnroot/xwiki
|_ platform/
|_ curriki/
|_ sandbox/
|_ enterprise/
|_ enterprise-manager/
|_ watch/
|_ workspaces/
|_ xeclipse/
|_ xlet/ (or whatever name we choose for it)
The idea is:
* Top level directories are projects.
* As such they get their wikis on xwiki.org (<project>.xwiki.org),
they are identified by the Committers group in that wiki.
* They also get a mailing list (they can use an existing mailing list
though)
Thus we remove the notion of extensions and products and we replace it
with the notion of projects which can be anything. This is more
scalable and in line with a forge idea.
If we're ok I'll work with Raff to set this up and to modify all web
pages which have the SVN URLs (like ohloh, freshmeat, etc).
Developers will need to perform a new co.
Here' s my +1
Thanks
-Vincent
Hi,
Contrary to what is described here http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture#HA6Intr…
I'd like to propose instead to use a nested {xhtml} macro whenever
you want your velocity script to generate XHTML.
So the example would be transformed into:
{velocity}{xhtml}
<div>
<h1>Hello $customer.Name!</h1>
<table>
#foreach( $mud in $mudsOnSpecial )
#if ( $customer.hasPurchased($mud) )
<tr>
<td>
* [link>$flogger.getPromo( $mud )]
</td>
</tr>
#end
#end
</table>
</div>
{/xhtml}{/velocity}
It seems to me much more logical to do it this way, especially since
we allow nested macros.
Note1: that it'll work because the velocity macro supports wiki syntax
and {xhtml} is wiki syntax.
Note2: This is not equivalent to writing {xhtml}{velocity}... since
the xhtml macro only accepts valid XHTML. This is valid though:
{xhtml}
<div>
<a href="...">{somemacro/}</a>
</div>
{/xhtml}
WDYT? Is it ok with you?
Thanks
-Vincent
Hi devs,
As it has been already mentioned a couple of times, I strongly believe
that XWiki Watch should be accessible in a sandbox on xwiki.org, for
everyone to try it out and explore its features and for us to get an
open real-life test of it.
There is a document dedicated to the issues that might prevent this at
http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg ,
please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on
xwiki.org, WDYT?
Happy coding,
Anca
P.S: Sorry for the duplicate email, I forgot the subject in the previous
one and I thought it's important enough to deserve duplicating.