xwiki-devs January 2011

xwiki-devs@xwiki.org

32 participants
67 discussions

[xwiki-devs] [Proposal] Skin extension grouping and transformation

by Marius Dumitru Florea

Hi devs, I have this wiki syntax: ----------8<---------- {{velocity output="false"}} $xwiki.ssrx.use('uicomponents/widgets/gallery.css') $xwiki.jsrx.use('uicomponents/widgets/gallery.js') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8---------- and I'd like to make the resource import automatic. I think we can achieve this in two steps. (1) Add a way to group skin extensions. I'd like to be able to write this: ----------8<---------- {{velocity output="false"}} $xwiki.gsx.use('gallery') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8---------- (2) Write a rendering transformation that looks for style names (CSS classes) in the content and imports the skin extension group with the same name. This way I'd be able to write just: ----------8<---------- (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8---------- Let's consider the technical details now: (1) I propose we add two XWiki classes: XWiki.SkinExtension * type (StaticList): jsrx * resource (String): uicomponents/widgets/gallery.js XWiki.SkinExtensionRole * role (String): gallery which will be used by a new SkinExtension plugin and component (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with XWiki.SkinExtension objects by document id. In other words, in order to create a skin extension group you have to add a XWiki.SkinExtensionRole object and multiple XWiki.SkinExtension objects to a document. To make group creation easier for StyleSheetExtension and JavaScriptExtension the new skin extension plugin will include them automatically in the group defined by the XWiki.SkinExtensionRole. In other words if you want to group a JSX and a SSX that are on the same document you just have to add a XWiki.SkinExtensionRole object to that document. (2) The rendering transformation that will automatically import the skin extension groups based on style names will use the skin extension component defined at step (1). This transformation should be the last one executed. WDYT? I'd like to implement this ASAP as it doesn't seem to be very complicated. Thanks, Marius

13 years, 10 months

[xwiki-devs] [Discussion] JIRA: Improving QA/Test Reports + relaxing JIRA rule

by Vincent Massol

Hi devs, Sorin and Silvia are helping us in term of improving the quality of platform/XE/XEM by systematically testing milestones/RCs/final versions. They've started a TestReports space on xwiki.org where he's going to put all his test reports from now on: http://www.xwiki.org/xwiki/bin/view/TestReports/ In those reports, when a test fails they'll need to create a JIRA issue (instead of pointing to a page on the incubator). This would make it much easier for reporting purpose, to see all the issues they've created and for us to see all issues found by the Q&A team. The problem is that our current JIRA strategy is to NOT create jira issue for issues that haven't been "released" already (instead the strategy is to comment in them). I'm proposing to relax this rule in the following manner: * Allow to have "affects" and "fix for" be the same value in JIRA * Automatically exclude from our release notes issues where "affects" == "fixfor" In addition IMO it would be good for Sorin/Silvia to: * Link the newly created jira to an existing jira WDYT? Thanks -Vincent

13 years, 10 months

[xwiki-devs] [VOTE] Add Document.getPlainTitle()

by Vincent Massol

Hi devs, In lots of places we need to display the title without any markup rendering. Examples: - breadcrumb - activity stream - search results etc This is such a common use case I'm proposing to add a new API for it in Document: getPlainTitle() It's a one liner that will do: getRenderedTitle("plain/1.0") Here's my +1 Thanks -Vincent

13 years, 10 months

[xwiki-devs] [VOTE] Move filesystem attachment storage into the core.

by Caleb James DeLisle

I would like to move the attachment storage code into the trunk for testing and inclusion in 3.0. I would like to put it in /core/xwiki-store/ which can begin the modularization of the storage engine. The filesystem attachment storage is still a work in progress but the main attachment storage class runs. I have added a new type of lock which automatically breaks deadlock and might solve the problem with deletion sometimes blocking. This code depends on and includes: TransactionRunnable which will allow us to evaluate TR in real life situations. Serialization apis for including a refactoring of the existing XMLWriter. File save/delete TransactionRunnables which serve as primitives for safe file saving and deletion on the filesystem. Lock manager which is still brand new and has to be moved into it's own package yet. An EntityReferenceSerializer for getting file paths from document names. This code provides: FilesystemAttachmentStore which is beta and functional. FilesystemAttachmentVersioningStore which is alpha and "you're on your own". along with compatible FilesystemAttachmentContent and ListAttachmentArchive. Here is my +1 for including this in the core so it can be developed and tested in concert. Caleb

13 years, 10 months

Re: [xwiki-devs] [Proposal] Making "Edit this attachment" an advanced feature in the advanced edit mode

by Raluca Stavro

Hello, >Sergiu Dumitriu wrote: > >>Silvia Rusu wrote: >> >>Hi devs, >> >>I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode. >> >>When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform. >> Under the above circumstances I think "Edit this attachment" will cause confusion for the average user instead of providing a useful tool. >> >>WDYT? >> > >Agreed to remove the edit button if the FF extension is not already installed and configured. The edit button is still there and the Firefox extension can't be installed because it is not compatible with newer Firefox versions. I really think that we should remove this button as soon as possible because this is a non-functionality at this point. Raluca.

13 years, 10 months

[xwiki-devs] [VOTE] Release IRCBot 1.0 application

by Vincent Massol

Hi devs, Just realized we've never released it. I'm proposing to do it today and document it at http://extensions.xwiki.org/xwiki/bin/view/Extension/IRC+Bot+Application Here's my +1 Thanks -Vincent

13 years, 10 months

[xwiki-devs] read-only XWiki ?

by Paul Libbrecht

Hello list, I have had a short attempt: set GLOBAL read_only=true; on the MySQL that runs my curriki and it kind of works. A few exceptions are thrown at the beginning but otherwise it seems to render well. The interest is that it could allow some of the web requests to be served by a database that is a slave of the main database, in live synchronization with the master MySQL. Has anyone tried that? thanks in advance paul

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r34247 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl

by Vincent Massol

On Jan 29, 2011, at 3:59 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2011-01-29 03:59:38 +0100 (Sat, 29 Jan 2011) > New Revision: 34247 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java > Log: > [refactoring] Better performance by avoiding repeated lookup of components > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java 2011-01-29 02:52:13 UTC (rev 34246) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java 2011-01-29 02:59:38 UTC (rev 34247) > @@ -124,6 +124,12 @@ > /** Logging helper object. */ > private static final Log LOG = LogFactory.getLog(PdfExportImpl.class); > > + /** Velocity engine manager, used for interpreting velocity. */ > + private static VelocityManager velocityManager = Utils.getComponent(VelocityManager.class); > + > + /** The OpenOffice manager used for generating RTF. */ > + private static OpenOfficeManager oooManager = Utils.getComponent(OpenOfficeManager.class); This is not very since it will prevent the Extension Manager and the dynamic component mechanism to work (if a new component impl overrides the role/hint). We shouldn't use any static as much as possible. Note that a lookup doesn't cost anything since there's no synchronize and it's only a concurrent hashmap get, so I doubt it's going to improve perf by much (unless there's something I don't understand). Note that in the future an idea we've had with Thomas is that all @Requirement will actually be proxies to the component impl so that if the component is replaced you'll always get the current one. Thanks -Vincent > + > /** DOM parser factory. */ > private static DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance(); > > @@ -242,11 +248,9 @@ > LOG.debug("Final XHTML for export: " + xhtml); > } > > - OpenOfficeManager OpenOfficeManager = Utils.getComponent(OpenOfficeManager.class); > - > // If OpenOffice server is connected use it instead of FOP which does not support RTF very well > // Only switch to openoffice server for RTF because FOP is supposedly a lot more powerful for PDF > - if (type != PDF && OpenOfficeManager.getState() == ManagerState.CONNECTED) { > + if (type != PDF && oooManager.getState() == ManagerState.CONNECTED) { > exportOffice(xhtml, out, type, context); > } else { > // XSL Transformation to XML-FO > @@ -285,10 +289,8 @@ > // id attribute on body element makes openoffice converter to fail > html = html.replaceFirst("(<body[^>]+)id=\"body\"([^>]*>)", "$1$2"); > > - OpenOfficeManager OpenOfficeManager = Utils.getComponent(OpenOfficeManager.class); > + OpenOfficeConverter documentConverter = oooManager.getConverter(); > > - OpenOfficeConverter documentConverter = OpenOfficeManager.getConverter(); > - > String inputFileName = "export_input.html"; > String outputFileName = "export_output" + (type == PdfExportImpl.RTF ? ".rtf" : ".pdf"); > > @@ -605,7 +607,6 @@ > Utils.getComponent(EntityReferenceSerializer.class); > try { > StringWriter writer = new StringWriter(); > - VelocityManager velocityManager = Utils.getComponent(VelocityManager.class); > VelocityEngine engine = velocityManager.getVelocityEngine(); > try { > VelocityContext vcontext = velocityManager.getVelocityContext();

13 years, 10 months

[xwiki-devs] Exposing PDF Export Options

by Thibaut Camberlin

Hi, I was writing a piece of code so that PDF export prints associated meta data of a page. Since I was in PDF macros code, I worked on a PDF export options page. By working on the PDF export options, I am using check boxes that allows user to choose to export or not cover page, toc page, metadata page attachments and comments. Issue I encountered is that when a check box is not checked it is not set and I found no way to use check boxes with actual code from pdfhtmlheader.vm page: #if("$!request.pdfcover" != '0') #set($displayPdfCover = 1) #else #set($displayPdfCover = 0) #end and the same for pdftoc (I could have put <input value="0"/> instead but it makes more sense to have <input value="1"/>) Therefore I am proposing that we: * update pdfhtmlheader.vm page so that cover and toc page are not exported by default * update existing pdf export button so that we keep the same behaviour (pdfcover and pdftoc printed in PDF), meaning instead of *page?format=pdf*it would be *page?format=pdf&pdftoc=1&pdfcover=1* Some UI will be needed afterward so that this page is exposed. (I am not planning to work on this.) The export options would be made in a template, but I put the code in this page of the incubator so that it makes things clearer if needed: http://incubator.myxwiki.org/xwiki/bin/view/PDFExport/ExportOptions Thanks for your feedback on pdfhtmlheader.vm modification and on the feature itself. -- Thibaut

13 years, 10 months

[xwiki-devs] [Discussion] Application Within Minutes Investigation

by Thibaut Camberlin

Hi, I layed down some of my investigations on Application Within Minutes features voted for 3.0. Can you give me your feedback on current "specs". All features that I could think of are there. http://incubator.myxwiki.org/xwiki/bin/view/Roadmap/ApplicationWithinMinutes Thanks -- Thibaut

13 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2011