- xwiki-devs@xwiki.org - lists.xwiki.org

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

14 years, 7 months

2
3
0 0

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();

14 years, 7 months

2
2
0 0

[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

14 years, 8 months

3
6
0 0

[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

14 years, 8 months

2
3
0 0

[xwiki-devs] FOSDEM 2011: presence of XWiki devs

by Vincent Massol

Hi everyone, FOSDEM (http://www.fosdem.org/2011/) is around the corner (5-6 feb 2011) and some XWiki developers are going: - Anca Luca - Ludovic Dubost - Jerome Velociter - Oana Tabaranu Anca will also give a talk on 6th February, from 14:40 to 14:55 PM, on annotations : "XWiki: Annotating documents, the eXtensible wiki way". Summary: " Since version 2.3, XWiki integrates document annotations in its collaborative environment (http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application). This talk will focus on the implementation of the annotation feature, with the challenges that an eXtensible wiki implies: handling user collaboration on documents and annotations, annotating dynamically generated content, flexible annotations structure to allow customization. As a default XWiki feature, it allows users to add notes on all types of content, plain unstructured documents or structured documents. It is also used in the Scribo project (http://www.scribo.ws) to manipulate automatic semantic annotations on wiki documents and collaboration around them. Since a demo is worth a thousand words, the presentation will center upon showing all these at work. " So if you intend to go to FOSDEM let us know here and it would be cool to meetup. Some details here: http://www.xwiki.com/xwiki/bin/view/Blog/XWiki%20Fosdem Thanks -Vincent

14 years, 8 months

1
0
0 0

[xwiki-devs] State of filesystem attachment storage.

by Caleb James DeLisle

Hello, Here's an update on the current state of new filesystem attachment storage: There are a couple platforms on which attachment storage sits: * Transaction handling - This is finished to my satisfaction. We may decide later that it is inadequate or needs changing but it serves this purpose now. * Transaction safe file save/delete - Finished (based on transaction handling) * Serialization - Finished refactoring of XMLWriter and generic Serializer and XMLSerializer. * Providing of files - Mostly finished, needs review to see if there is a cleaner way. Barring any major changes, this should not take longer than 1 day to complete. * Locking - Needed, lock management exists but does not handle deadlock nor "greedy thread" situations. 3 days needed to do code review on Apache commons LockManager to determine if it handles these situations, I'm guessing 2 days are needed to integrate LockManager and in place of the existing lock mechanism and a further 3 days to implement one of the features on top of LockManager if need be. "Consumer" code: * FilesystemAttachmentStore - Complete, enabling requires adding the .jar file to WEB-INF and changing a line in xwiki.cfg. Suffers from deadlock because the locking mechanism, is inadequate. * FilesystemAttachmentVersioningStore - Complete but needs tests, enabling is same as for FilesystemAttachmentStore. 1-2 days should be adequate for testing. * FilesystemAttachmentRecycleBinStore - in progress, 3 days to complete and test (?). Finished DeletedFilesystemAttachment, need TransactionRunnables for saving and deleting and serializer for deleted attachment meta-data. * Need a plan for migrating data from old system. FilesystemAttachmentStore fails over to old store if an attachment cannot be found. Is this correct? Should migration scripts be distributed instead? WDYT? * Consumer code all needs more tests. Any amount of time could be spent on this, I think a week is adequate. Since this contains a large amount of code and all storage code is critical, I think this should go through a release cycle in the platform but disabled by default so that it can be beta tested before it becomes official. WDYT? Caleb

14 years, 8 months

4
9
0 0

[xwiki-devs] State of the XWiki Community

by Sergiu Dumitriu

Hi Community, The following message expresses my personal opinions as a member of the community, so it might not be entirely accurate. The goal is to start a discussion about how can we attract more contributors and committers to the XWiki open source project, and will address three main subjects: - the current state of the community and committers - the possibility of joining or creating a non-profit foundation to govern XWiki - the possibility of using Fundry as a way for users to fund XWiki development ----- Status of the community At the start of a new year, it's time to look a bit at the status of XWiki, the project and the community. XWiki was created by Ludovic Dubost as an open source project from the start. Later, he founded a commercial company (XWiki SAS, back then XPertNet SaRL) as a way to financially support the development of the product. It kept the project entirely open, unlike the many false open source companies that only offer a basic open source version, forcing people to buy the commercial one (the open core model), or that only release the source code while still doing behind-the-curtains development, or that almost completely ignore the outside community. See the XWiki SAS values: http://purl.org/xwiki/sas-values and manifesto: http://purl.org/xwiki/sas-manifesto The committers, elected for their merit, and not made automatically as employees of the company, always tried to maintain a healthy community and attract new contributors/committers. Thus, the XWiki software is developed not by the XWiki SAS company, but by the XWiki community. http://dev.xwiki.org/xwiki/bin/Community/ has a lot of information about the community, and the development process. As of January 2011, there are 16 core committers, 12 of which are XWiki SAS employees, and 3 are or were related to XWiki SAS one way or another. http://dev.xwiki.org/xwiki/bin/Community/HallOfFame#HCoreCommitters A big part of the development is aided by non-committer members of the community, either by providing patches, testing and reporting bugs, requesting new features, providing feedback, answering on the mailing lists, etc. As committers, we tried to listen to the community when developing the project, but as paid employees we have to also listen to the company requirements. With a limited manpower it's very hard to evolve as fast as the community would want, or in all the directions that the community wants. And we welcome any help here. The project is healthy, we have regular and frequent releases, with visible progress with each new release (see Vincent's statistics on http://massol.myxwiki.org/xwiki/bin/Blog/XWikiIn2010 for more details). Still, I'm a little disappointed with the development speed. Lately, out of the 16 committers on average about 3-4 are actually available for platform development during a day. * How can we help speed up the growth of the community? * How can we attract more developers outside XWiki SAS? ----- Joining/forming a free software foundation One possible reason while so few people are willing to become committers could be that XWiki SAS might appear to over-control the software, and a clear non-profit foundation on top of XWiki might make it more obvious that XWiki is a true open source project, and anybody is welcome to join. XWiki SAS is a member of the OW2 consortium http://ow2.org/ , and this membership also extends a bit to the XWiki project. OW2 used to host all our infrastructure, SVN, mailing lists, downloads... Currently only the official downloads linked from the main download page are hosted on OW2 servers, as we've gradually moved parts of the development infrastructure on servers provided by XWiki SAS. While OW2 is a great home for XWiki SAS, it's mostly a company consortium, not a software development foundation. The most development help coming from OW2 consists of research projects involving both OW2 and XWiki SAS, thus the OW2 membership doesn't bring much value when it comes to code. One option is to form an XWiki non-profit Foundation, which will govern all XWiki-related software development. The main disadvantage would be that there's a risk that it won't make any difference at all, while adding the burden of more paperwork. This is where your opinion comes into play, since there's no point in doing all the hard work if the community doesn't see a clear benefit in it. The Apache Foundation has the huge disadvantage that it requires a license change, but it's a very well known home for software development, with good visibility. The Software Freedom Conservancy has been getting a lot of press recently, since several high profile projects joined it. It's got a few top-notch projects under its hood, so XWiki would be among well known projects in there. A smaller, compatible alternative is Codehaus, but I'm not convinced they would make a difference with respect to our needs. Other foundations aren't really suited for XWiki, since they either don't bring value to the community because they don't foster inter-project collaboration (SourceForge, Google Code), or don't match the project goals (FSF, GNU, Eclipse, Linux, Mozilla...). So, some questions in regard to this subject: * Is there anybody that would like contribute more / become a committer? * Do users believe that a foundation on top of XWiki will help attract more developers? Please note that this is not THE discussion about which foundation to join, just trying to see if there is a benefit in doing so. ----- Supporting code development Becoming a committer requires time, and few people can spend that time when there's no direct benefit involved. XWiki SAS employees are already being paid to work with XWiki, so they can contribute to the platform because the company benefits directly from their work. Employees of other companies that deal with XWiki do spend time contributing, but very few actually got to hang around enough to be voted as committers, although many came close, but stopped short of it. One way of supporting code development is to contact XWiki SAS and sign a contract to develop one or more features with a higher priority. An alternative, which allows to share the cost with other companies/individuals, is to collaboratively request and support feature development (crowdfunding), for example through Fundry, a new site especially designed for this. I've set up an account for XWiki at https://fundry.com/project/58-xwiki . This is also a good place to donate to the XWiki project, since there are no visible ways to financially support the project. Fundry would allow to gather financial incentives for non-employees to contribute more code, thus involving the community more in the direction the software evolves, and attracting more potential contributors. * Do you (the community) think this is a good idea and it would help? * Would you be willing to contribute/donate to the project? ----- Please provide us with your feedback, so we can advance on these topics. Thanks, -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 8 months

2
1
0 0

[xwiki-devs] [discussion] Gadgets in wiki syntax vs gadgets in objects

by Anca Luca

Hi team, I talked on Friday with Vincent about how to approach editing of a dashboard, and we rethought the current approach of specifying the gadgets in a dashboard. Right now, the solution I started to implement is Option 4) in the Dashboard syntax section, http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Colu… , having the gadgets be actual macro calls in wiki syntax in the content of the dashboard macro. This is causing quite some issues on editing, because the wiki syntax of the document needs to be re-generated when the dashboard changes. We detailed another solution, option 5) in the same document http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption529Gadg… , where gadgets will be specified by objects in the dashboard document, and the dashboard macro call in the page will only mark the point where the objects are read and rendered as a dashboard. Editing should be easier in this case, as the data is more structured than in option 4) (reading and changing object fields). My question here is, does anyone see anything wrong with option 5) ? So far to me it seems a better choice than 4), easier to implement and fixing more problems, and it feels a bit more "semantic" to store the gadgets as structured data, rather than "unstructured" document content. Thanks, Anca

14 years, 8 months

3
2
0 0

[xwiki-devs] Reminder: Corporate Wiki Users' Perception Survey

by Zeeshan-Ahmed.BHATTI

Hello Everyone, Please help me in my Doctoral dissertation survey about "Corporate Wiki Users' Perception of Wikis". I need respondents(corporate Wiki users) for my web survey on Wiki perceptions. I will highly appreciate your help in this. The survey takes 5 min. If anyone is interested, He/She can also get the results of the study. The link to survey is: http://www.kwiksurveys.com/?s=HBJEMM_bfb8d99c (English) http://www.kwiksurveys.com/?s=HCEKKH_f6159e79 (Français) Thank You All, Regards// Zeeshan Ahmed BHATTI Doctoral Student, IAE Graduate School of Management, Aix-en-Provence, FRANCE Cell: +33(0)632008933

14 years, 8 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r34206 - platform/core/trunk/xwiki-skin

by Sergiu Dumitriu

On 01/25/2011 03:29 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2011-01-25 15:29:51 +0100 (Tue, 25 Jan 2011) > New Revision: 34206 > > Modified: > platform/core/trunk/xwiki-skin/pom.xml > Log: > Align name and description with other modules > > > Modified: platform/core/trunk/xwiki-skin/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-skin/pom.xml 2011-01-25 12:49:33 UTC (rev 34205) > +++ platform/core/trunk/xwiki-skin/pom.xml 2011-01-25 14:29:51 UTC (rev 34206) > @@ -7,8 +7,8 @@ > <version>3.0-SNAPSHOT</version> > </parent> > <artifactId>xwiki-core-skin</artifactId> > -<name>XWiki Core - Skin Component</name> > -<description>XWiki Core - Skin Component</description> > +<name>XWiki Platform - Core - Skin</name> This is something I really don't like. The description should not be the same as the name, otherwise there wouldn't be a need to have the same information in two places. The description should be a real description, a full sentence that makes sense and really describes what's the module for. > +<description>XWiki Platform - Core - Skin</description> > <properties> > <xwiki.clirr.skip>true</xwiki.clirr.skip> > </properties> -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 8 months

3
2
0 0

[xwiki-devs] Corporate Wiki Users' Perception Survey

by Zeeshan-Ahmed.BHATTI

Hello Everyone, Please help me in my Doctoral dissertation survey about "Corporate Wiki Users' Perception of Wikis". I need respondents(corporate Wiki users) for my web survey on Wiki perceptions. I will highly appreciate your help in this. The survey takes 5 min. If anyone is interested, He/She can also get the results of the study. The link to survey is: http://www.kwiksurveys.com/?s=HBJEMM_bfb8d99c (English) http://www.kwiksurveys.com/?s=HCEKKH_f6159e79 (Français) Thank You All, Regards// Zeeshan Ahmed BHATTI Doctoral Student, IAE Graduate School of Management, Aix-en-Provence, FRANCE Cell: +33(0)632008933

14 years, 8 months

1
0
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.0 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is pleased to announce the release of XWiki Enterprise 3.0 Milestone 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the start of the 3.x release cycle, bringing in several backwards-incompatible changes, like removing old deprecated APIs, and upgrading to the new version of Velocity Engine 1.7. Several more major changes are planned for the next 3.0 milestones, like changing the default theme, a new logo for the XWiki Open Source product, upgrading all documents to the 2.0 (or 2.1) syntax, a new administration interface, and many others. The highlights of this release are: * Better WYSIWYG editor support for Opera, Safari and Chorome * More ColorTheme customization options * More standardized UI forms * PDF export improvements * Activity stream performance improvements * Upgrade to Velocity 1.7 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks -The XWiki dev team

14 years, 8 months

1
0
0 0

[xwiki-devs] [Discussion] Velocity 1.7 - Migration guide?

by Vincent Massol

Hi Sergiu, I'd like to discuss this point that you've made in some other mail: "Velocity 1.7, which brings many new features and improvements, but breaks a lot of velocity macros (still working on fixing the broken code)" Does this mean users who have existing scripts will have things not working anymore? (I guess so if we have broken stuff on our side) If so, what can we do to make them suffer less when upgrading? Can we start by listing broken stuff here and add them to the release notes? Thanks -Vincent

14 years, 8 months

3
3
0 0

[xwiki-devs] [proposal] Introduce a new persistence engine.

by Caleb James DeLisle

Hi, I have been working hard on filesystem attachments and I found that synchronizing manual filesystem transactions with automatic database transactions was a difficult job and I needed a new tool to do it. So I wrote what I am proposing to be the next XWiki Persistence Engine. I'll start off with the fun part of the proposal, I have been calling it xwiki-store so far but I am so excited about the capabilities of this engine that I don't think it does it justice to name it "store" after the place on the corner with milk and eggs. I am proposing it be named "XWiki Persistence Engine", the directory will be renamed xwiki-persistence, the artifact name xwiki-core-persistence, and the package name org.xwiki.persistence. Persistence is an attribute of castles, mountains and redwood trees which I think is fitting for a conservatively designed storage engine. Now a little explanation of what I'm so excited about: The common and error prone way of saving things in the database is to open a transaction, enter a try clause, do something then commit. If we catch an exception, then we rollback. something like this: begin transaction; try { do something; do something else; commit; } catch (Any exception which may occur) { rollback; } There are 3 things which can go wrong. 1 we forget to begin the transaction, 2 we forget to commit and 3 we do not rollback properly. What makes things worse is often the database will "assume we meant to..." and things will work ok most of the time which makes things much worse because bugs will hide very well. My answer to this problem is a class called TransactionRunnable. It provides a set of 5 empty methods to override: onPreRun(), onRun(), onCommit(), onRollback(), and onComplete(). the exact circumstances under which each are called is documented in the javadoc comments here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-… I wrote TransactionRunnable twice, I wrote it, used it for attachments, then after having real experience as a user, I wrote it again. To repeat our original example with TransactionRunnable you might say this: public class DoSomethingTransactionRunnable extends TransactionRunnable { public void onRun() { do something; do something else; } } Now we can use another TransactionRunnable which opens and closes the transaction for us. StartableTransactionRunnable transaction = new HibernateTransactionRunnable(); new DoSomethingTransactionRunnable().runIn(transaction); transaction.start(); the runIn() function allows us to run one TransactionRunnable inside of another. Supposing we wanted to reuse "do something else" in other places, we can make it a separate TransactionRunnable and use the runIn() function to hook it to our DoSomethingTransactionRunnable ie: public class DoSomethingTransactionRunnable extends TransactionRunnable { public DoSomethingTransactionRunnable() { new DoSomethingElseTransactionRunnable().runIn(this); } .. The only limitations on running TransactionRunnables inside of one another are they cannot run more than once and they cannot call themselves (this would be an infinite loop). This pattern makes each job which is done on storage easily isolated and, as I have so far experienced, trivial to test. However, it still leaves the possibility that we might forget that DoSomethingTransactionRunnable must be run inside of a hibernate transaction. I have devised a solution for this too. Using generics, I offered a means for the author of a TransactionRunnable to communicate to the compiler what other TransactionRunnable their runnable must be run in and without explicit casting or defining of an intermediary runnable, this requirement cannot be violated or else it wouldn't compile! Finally we have the issue of starting the runnable. Who's to say I won't be tired one day and just write new DoSomethingTransactionRunnable().start() without opening a transaction first? If DoSomethingTransactionRunnable cannot be safely run outside of a transaction all it needs to do is not extend StartableTransactionRunnable and it won't have any start function. I have taken a multitude of very easy mistakes and given the author of a TransactionRunnable the tools to make it very hard for the user to make them. Also, since a TransactionRunnable has no reason to be very long (it can just branch off into another runnable) this will make testing and code review easy in the place where it is most important. This part of the code is entirely generic and has no dependence on hibernate or anything else. I propose we move: contrib/sandbox/xwiki-store/xwiki-store-transaction/ to: platform/core/xwiki-persistence/xwiki-persistence-transaction And I will propose moving each additional piece in the coming days. WDYT? Caleb

14 years, 8 months

4
16
0 0

[xwiki-devs] Need Release Manager for XE 2.7M1

by Vincent Massol

Hi devs, Anyone interested in volunteering for releasing XE 2.7M1 (release should start today and be finished on the 17th of Jan end of day)? Thanks -Vincent

14 years, 8 months

4
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r33998 - platform/web/trunk/standard/src/main/webapp/templates

by Vincent Massol

On Jan 19, 2011, at 2:05 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2011-01-19 14:05:06 +0100 (Wed, 19 Jan 2011) > New Revision: 33998 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > Log: > XWIKI-5890: #setVariableFromRequest doesn't work with Velocity 1.7, replace with #readVariableFromRequest > Corrected #setVariable so that it doesn't output any whitespace. > > Modified: platform/web/trunk/standard/src/main/webapp/templates/macros.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2011-01-19 13:01:30 UTC (rev 33997) > +++ platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2011-01-19 13:05:06 UTC (rev 33998) > @@ -1508,13 +1508,13 @@ > * @param value the value to assign > *### > #macro(setVariable $variableName $value) > - ## Only do this if the variable name is really a valid variable name > - #if ($variableName.matches('[a-zA-Z_][a-zA-Z0-9_-]*')) > - #evaluate("${escapetool.h}set(${escapetool.d}${variableName}=${escapetool.d}value)") > - #elseif ($variableName.matches('\$[a-zA-Z_][a-zA-Z0-9_-]*')) > - #evaluate("${escapetool.h}set(${variableName}=${escapetool.d}value)") > - #end > +## Only do this if the variable name is really a valid variable name > +#if ($variableName.matches('[a-zA-Z_][a-zA-Z0-9_-]*')) > +#evaluate("${escapetool.h}set(${escapetool.d}${variableName}=${escapetool.d}value)") > +#elseif ($variableName.matches('\$[a-zA-Z_][a-zA-Z0-9_-]*')) > +#evaluate("${escapetool.h}set(${variableName}=${escapetool.d}value)") > #end > +#end So we can't use indentation in macros? Should we document this generally or is it specific to this macro (in which case maybe we should add a comment so that the next person doesn't start indenting it)? Thanks -Vincent

14 years, 8 months

3
5
0 0

[xwiki-devs] How can I hide attachments from search results?

by John Lantz

We are having a problem with image attachments clogging up our search results. Say a user is searching for Orange. The topic page Orange will be ranked below an image named orange.png, as well as an image named IMAGEI68A35.png that is on a the Fruit Salad topic page. Ideally, we would be able to hide all attachments from search results. We don't want to hide attachments on topic pages-we need the images to be displayed-but we do need to hide them from search results. The problem is identical to the one posted by this user: http://jira.xwiki.org/jira/browse/XPLUCENE-63 Any suggestions? A simple bit of code I could past into a config or preference file somewhere? Any help would be greatly appreciated. Thank you very much, John Lantz Developer Advocate IdeaBlade Office: 510.596.5100 x124 Cell: 408.515.9565 Email: johnl(a)ideablade.com<mailto:johnl@ideablade.com>

14 years, 8 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r34008 - platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki

by Vincent Massol

On Jan 19, 2011, at 6:13 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2011-01-19 18:13:30 +0100 (Wed, 19 Jan 2011) > New Revision: 34008 > > Modified: > platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml > Log: > XPWATCHLIST-122: The HTML part of the watchlist notification mail is not rendered under velocity 1.7 > * Escape quotes using an extra variable instead of "" in order to be backwards compatible. > > > Modified: platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml > =================================================================== > --- platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml 2011-01-19 17:02:04 UTC (rev 34007) > +++ platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml 2011-01-19 17:13:30 UTC (rev 34008) > @@ -292,11 +292,12 @@ > #set($result = $result.replaceAll("${prefix}propDiffNewValue", "$propDiffStyle background:#EDFFED;")) > #set($result = $result.replaceAll("${prefix}propDiff", "$propDiffStyle")) > #set($suffix = "_WATCHLIST_IMG_PLACEHOLDER") > + #set($q = '"') If I was a PITA I'd say this should be explained since the next person who sees this will think Marius did a bad job and could have used "" instead (native synax) ;) -Vincent > #foreach($totransform in ["attach", "object", "class", "metadata"]) > - #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=""cid:${totransform}.gif"" style=""${iconStyle}"" ${iconAttrs}></img>")) > + #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=${q}cid:${totransform}.gif${q} style=${q}${iconStyle}${q} ${iconAttrs}></img>")) > #end > #foreach($totransform in ["boolean", "date", "dblist", "dbtreelist", "groups", "levels", "number", "password", "staticlist", "string", "textarea", "users"]) > - #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=""cid:${totransform}.png"" style=""${iconStyle}"" ${iconAttrs}></img>")) > + #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=${q}cid:${totransform}.png${q} style=${q}${iconStyle}${q} ${iconAttrs}></img>")) > #end > $result > #end

14 years, 8 months

2
1
0 0

[xwiki-devs] XE 3.0 roadmap status for 3.0M1 and commitments for 3.0M2 and later

by Vincent Massol

Hi devs, XE 3.0M1 is around the corner (planned for the 17th of Jan). It would be good to know where we stand. Could everyone working for 3.0M1 please report their status in this thread? The planned roadmap was: - Extension Manager - Thomas Mortagne - App within minute - Investigation - Thibaut (with?) - Improved page loading - Investigation - By whom? - Use status - whom? - Right UI - Sergiu? - Portlet - Marius - Multipage export - whom? - Dashboard/Gadget - Anca - Admin/Profile UI improvements - Sergiu - Attachment Storage - Caleb (+ Sergiu to help review it) - Spotlight like search - JV & me - IE6 support drop - Investigation (Greg + Ciprian ?) - Icon theme editor - Investigation (Greg + Caty ?) - LDAP admin section - Investigation (Greg + Thomas ?) - XEM HomePage & Workspace - Investigation (Greg + Fabio + Caty ?) - Reader macro vs XWiki Watch - Investigation - WYSIWYG working on Chrome/Safari (webkit) - Marius Please comment inline for what you've been working on and if you've been working on additional stuff for 3.0M1 please add it in the end. Also if you volunteer to work on something for 3.0M2 or later please let us know in this thread too. Thanks a lot -Vincent

14 years, 8 months

9
10
0 0

Re: [xwiki-devs] [myxwiki] new wiki request

by Vincent Massol

Hi Doug, On Nov 24, 2010, at 1:27 AM, Doug Skuce wrote: > Hello! > > I am a retired IT prof (Phd 1977) and love trying to still do useful things. > > > My idea is to create a wiki in which anyone can enter and comment on problems, mainly laws, at federal, state, or municipal levels. Eg we need to spend more money on police, or garbage collection sucks. > > > I am searching for a suitable wiki and your product seems great except for cost. This wiki could have 100s of thousands of users if used nationwide. Of course they could be separate but that is less desirable. You could use myxwiki.org to validate your concept but if it grows to lots of users you should contact XWiki SAS (http://xwiki.com) to ask for a quote to support all the users you have in mind. If you're interested to test myxwiki.org please follow the instructions on http://myxwiki.org/xwiki/bin/view/Main/WebHome Thanks -Vincent > I successful how would scale to thousands of users? > > > Let me know your thoughts. > > > Thanks > > > Doug Skuce

14 years, 8 months

1
0
0 0

[xwiki-devs] [Proposal] Group manager (User with edit rights on group's page)

by Eduard Moraru

Hi devs, I`ve just made a few modifications (locally) to the group sheet and to the livetable macro to allow users with edit rights on a group's page to edit the group, acting like a "group manager", without having to require wiki-level admin rights. I thought this would be a nice addition to XE so here is the jira issue (with patch included). WDYT? Thanks, Eduard

14 years, 8 months

3
3
0 0

[xwiki-devs] Crypto module test failure

by Vincent Massol

Hi devs, This is not the first I notice that one of the crypto module test is failing on my machine when building core. Here's what I got this time: Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.106 sec <<< FAILURE! initializationProcessorTimeTest(org.xwiki.crypto.passwd.ScryptMemoryHardKeyDerivationFunctionTest) Time elapsed: 1.501 sec <<< FAILURE! java.lang.AssertionError: password hashing took 1437 and target time was 500 My machine is pretty powerful so it shouldn't be an issue either with memory or cpu. Any idea on how to fix this? Thanks -Vincent

14 years, 8 months

1
0
0 0

[xwiki-devs] [Idea] New default color theme for the 3.0 cycle

by Jerome Velociter

Hello friends, What about we create and set default a new color theme for XE, in the 3.0 cycle ? This is a cheap way for us to refresh the look and to differentiate 3.x visually ? We could aslo have new additional themes, besides the default one. Jérôme.

14 years, 8 months

8
16
0 0

[xwiki-devs] [Idea] Compatibility file for deprecated styles

by Jerome Velociter

Hello devs, I've just hit an issue where my application relies on CSS styles definitions that are being dropped between 2.7 and 3.0, namely all the dashboardXXX classes, abandoned in favor of the new dashboard macro styles. While I reckon those CSS classes were never explicitly defined as being APIs developers should rely on, I think we should offer better backward compatibility for those who did rely on them, just like we do with JavaScript code (see http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar… ) What we could do is introduce a compatibility.css file holding styles for such deprecated classes, and decide if we want it or not included by default (The JavaScript compatibility.js file is included by default, for example, although the rules states that XE releases should work just the same without it, of course). WDYT ? Jérôme.

14 years, 8 months

3
3
0 0

[xwiki-devs] [Proposal] Removing Deprecated methods in XE 3.0+

by Vincent Massol

Hi devs, I think the start of the XE 3.x cycle is a good time to remove some deprecated methods/classes. We have a deprecation strategy defined already: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca… " Our rule is to keep @deprecated methods/classes for 2 final releases after the version where they were first added has been released as final. For example if a method is deprecated in, say XE 1.3M2 then the method will be removed in 1.6M1 or after. Of course any major new release can deprecate anything. For example a XWiki 2.0 release is allowed to break backward compatibility (obviously we need to be careful to offer a migration path for users of previous major versions). " So 2 final releases mean that deprecations introduced in 2.5.x or before can theoretically be removed for XE 3.0 final. However, IMO we shouldn't remove deprecated methods/classes that are public for scrips since this will break xwiki users. Are we ok to do that? Personally I'm fine and I'd like to add this caveat to the best practice if we agree. Thanks -Vincent

14 years, 8 months

5
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs