Hello,
I would like to propose voting Marius Florea as a core committer. Marius
has already sent a lot of patches (see http://tinyurl.com/67wa9a, in
particular the patches on XE statistics, JodaTime plugin, and the new RSS
mechanism in the feed plugin). Marius patches are clean, well documented
and comes with tests. Marius is now working for a few months already on
the rewrite of the WYSIWYG editor in GWT, and at some point soon he will
need to start integrating his work with the platform.
Thus, I propose Marius applies his own patches from now on.
Here is my +1 for this.
Note: For full disclosure, Marius is working for XWiki SAS, the company
behind the creation of XWiki. FWIW, out of the 21 committers
(http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame), 10 are working
for XWiki SAS. Note that we're running XWiki as a meritocratic project
(trying to follow the Apache rules as much as possible) and thus anyone
can become a committer (see
http://dev.xwiki.org/xwiki/bin/view/Community/Committership). The more the
merrier!
Regards,
Jerome.
Dear,
we Downloaded your xwiki from www.xwiki.org, its an very nice free source
code software. But we need to do some addition ,details required as folows:
1.I have got nothing about about the java files.which i need to update
specialy admin java files.
2.Our specific requirement is to bypass the user login and password ,as
that user already done at our application main page.
Please send back some solution and if possible id or mail contact of person
to whom i can discuss my problem in detail.
Thanks and regards,
Deepak Sharma
Assistant Software Engineer-T
Tata Consultancy Services
Cell:- 9911502444
Mailto: deepak24.s(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
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