xwiki-devs February 2011

xwiki-devs@xwiki.org

30 participants
95 discussions

[xwiki-devs] Replacing mentions of OpenOffice

by jstoldt

Hi everyone, I have been working with the application strings a fair bit lately when doing the German Translation for XWiki. While doing that I noticed a lot of the stuff says "OpenOffice". Now, this term is problematic, IMO. 1. "OpenOffice" is trademarked in the Netherlands and UK so the office suite opted for "OpenOffice.org", so if we were talking about this particular office suite, it should actually be "OpenOffice.org". 2. Since Sun was acquired by Oracle there was a major fork which created LibreOffice. The latter is going to be redistributed with Linux distributions such as Ubuntu. That means to say that using "OpenOffice" is kind of pointing to only one product, when more products are available. What I would like to discuss is if you would like to see a replacement of this very specific (and at least a little faulty) term and if so, what should it be? I thought about "Open Office" which is getting a little further away but I am really not happy with it either. "Open office suite" would be a little more generic and would include all OOo derivatives with the downside of including other potential open source office suites that got nothing to do with OOo at all (such as GNOME Office). Any comments on that? Regards, Johannes -- View this message in context: http://xwiki.475771.n2.nabble.com/Replacing-mentions-of-OpenOffice-tp601553… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 10 months

[xwiki-devs] [Proposal] Gallery macro

by Marius Dumitru Florea

Hi devs, I'd like to add a gallery macro that will be used like this: {{gallery}} any wiki content {{/gallery}} and which is equivalent to: {{velocity output="false"}} $xwiki.jsfx.use('uicomponents/widgets/gallery/gallery.js') $xwiki.ssfx.use('uicomponents/widgets/gallery/gallery.css') {{/velocity}} (% class="gallery" %) ((( any wiki content ))) Some technical details: * it won't support in-line mode * it will have two optional parameters: width and height, both expressed in pixel units (i.e. both are positive integers) * it will handle its content as box macro does (using a MacroContentParser without running transformations) * it will be placed in xwiki-rendering-macros/xwiki-rendering-macro-gallery/ * images will be displayed as in http://incubator.myxwiki.org/xwiki/bin/view/Improvements/OfficePresentation… Further more, I will change the office importer module to generate: {{gallery}} image:presentation-slide1.jpg image:presentation-slide2.jpg ... image:presentation-slideN.jpg {{/gallery}} when importing an office presentation file. As a consequence the office viewer macro will use the gallery macro behind the curtains (i.e. {{office attachment="presentation.odp"/}} will display the presentation slides using the gallery macro). WDYT? Note that the gallery macro could be based on a generic macro that: * wraps the content with a GroupBlock and adds a CSS class name * uses the SkinExtension component to import some JS/CSS resources but there is no such macro right now. Another thing to note is that I can't make gallery macro a wiki macro because the office importer module will depend on it. Thanks, Marius

13 years, 10 months

[xwiki-devs] [UX][Vote] New Administration forms width: partial or full

by Ecaterina Moraru (Valica)

Hi, Since XE 3.0M2 we have a new administration look ( http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…). There was a debate if the forms should be full width or not. *Variants*: 1) *Partial Width* (current): http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu… 2) *Full Width*: http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu… *Test*: You can test this "partial"/"full" width on your resolution by removing "half" class from "<form class='xform half"" definition. *Considerations*: - When voting please consider that the width will be set for small and high resolutions (that until we will improve our skin to detect the resolutions change). - You should consider how form controls look (readability, usability) on different sizes, like <select>, input, textarea, etc. *Other Solutions*: A. The problem is that on large resolution is hard to read the controls because the form are too wide - on small resolution there is unused space. A solution would be to use CSS media queries and adjust the width for smaller resolutions. B. Another solution would be to use the additional space given by the partial width and provide some extra help for the sections, see smaller resolution: http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu… higher resolution: http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu… *Vote*: You can use the poll made for this vote: http://incubator.myxwiki.org/xwiki/bin/view/Polls/AdministrationFormsfullwi… or if you don't have an account on incubator, just reply to this mail. Please cast you votes. Thanks, Caty

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r34616 - in enterprise/trunk/wiki/src/main/resources: Main XWiki

by Vincent Massol

On Feb 10, 2011, at 8:50 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2011-02-10 20:50:06 +0100 (Thu, 10 Feb 2011) > New Revision: 34616 > > Added: > enterprise/trunk/wiki/src/main/resources/XWiki/RequiredRightClass.xml > Modified: > enterprise/trunk/wiki/src/main/resources/Main/Activity.xml > enterprise/trunk/wiki/src/main/resources/Main/Spaces.xml > enterprise/trunk/wiki/src/main/resources/XWiki/AllAttachmentsResults.xml > enterprise/trunk/wiki/src/main/resources/XWiki/DeletedAttachments.xml > enterprise/trunk/wiki/src/main/resources/XWiki/DeletedDocuments.xml > Log: > XE-831 Provide a XClass that allow to mark pages that require to be saved by a user with certain rights > XE-832 Add XWiki.RequiredRightClass to XE documents that require to be saved with certain rights > [snip] > Modified: enterprise/trunk/wiki/src/main/resources/Main/Spaces.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/Main/Spaces.xml 2011-02-10 19:49:34 UTC (rev 34615) > +++ enterprise/trunk/wiki/src/main/resources/Main/Spaces.xml 2011-02-10 19:50:06 UTC (rev 34616) > @@ -1,5 +1,4 @@ > <?xml version="1.0" encoding="UTF-8"?> [snip] > +<className>XWiki.RequiredRightClass</className> > +<guid>eb832884-79a9-4e96-b1fa-55fdbb06b0a5</guid> > +<property> > +<level>edit</level> I don't understand the point of settings RequiredRightClass with level = edit. Editing a page always requires edit rights anyway, no? (I'm sure I'm missing something though...) Note: Wiki/TagCloud.xml also has an "edit" level > Added: enterprise/trunk/wiki/src/main/resources/XWiki/RequiredRightClass.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/XWiki/RequiredRightClass.xml (rev 0) > +++ enterprise/trunk/wiki/src/main/resources/XWiki/RequiredRightClass.xml 2011-02-10 19:50:06 UTC (rev 34616) Hmm do we consider the RequiredRightClass a "core" class or not? If so I think we should create it programmatically if it doesn't exist in the wiki at startup. Thanks -Vincent

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r34581 - in enterprise/trunk/wiki/src/main/resources: Main XWiki

by Vincent Massol

On Feb 9, 2011, at 10:42 AM, lucaa (SVN) wrote: > Author: lucaa > Date: 2011-02-09 10:42:42 +0100 (Wed, 09 Feb 2011) > New Revision: 34581 > > Added: > enterprise/trunk/wiki/src/main/resources/XWiki/GadgetClass.xml > Modified: > enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml > Log: > XE-828: Main.Dashboard dashboard must be updated to store its gadgets in objects > * Refactored the Main.Dashboard to store the gadgets in objects > > > Modified: enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml 2011-02-09 09:38:29 UTC (rev 34580) > +++ enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml 2011-02-09 09:42:42 UTC (rev 34581) > @@ -11,8 +11,8 @@ [snip] Another option would be to have an Initializer component in the Dashboard macro module which would listen to the application started event (note that this event needs the DB to be ready we need to talk about doing this one since we're in need of it) and would create the GadgetClass if it doesn't already exist (or update it if it's missing some fields for example). This would allow to: 1) remove the dependency this commit is creating with the default XE XAR 2) removes the need for a gadget application 3) make the dashboard macro work even when the default XE XAR is not installed or if the user hasn't updated to the newest XAR Notes: * Since we don't have the app started event coupled with the app ready, we could FTM have the dashboard macro implement Initializable and perform the init there. * Maybe we can think of other pages that would be needed for the gadget "feature" (for ex listing all dashboards available in the current wiki, etc). In this case we would need a specific gadget appilcation in platform/applications IMO. Note that even if we need this application we still don't need to have a GadgetClass.xml file. WDYT? Thanks -Vincent

13 years, 10 months

[xwiki-devs] BugFixingDay Results of 10 Feb 2011

by Vincent Massol

Hi everyone, Thanks to everyone who contributed to the bugfixingday of yesterday. I've blogged the results: http://www.xwiki.org/xwiki/bin/view/Blog/BugFixingDayFebruary2011 Please let me know if I've forgotten someone. Let's have even more contributions next time! Thanks -Vincent

13 years, 10 months

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

by Sergiu Dumitriu

On 02/10/2011 10:08 PM, Alex Busenius wrote: > Hi, > > On 02/10/2011 09:38 PM, sdumitriu (SVN) wrote: >> Author: sdumitriu >> Date: 2011-02-10 21:38:15 +0100 (Thu, 10 Feb 2011) >> New Revision: 34623 >> >> Modified: >> platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/XWikiGroupSheet.xml >> Log: >> XAADMINISTRATION-218: CSRF token not included in add-group-member ajax request >> Fixed. >> Patch from Andreas Jonsson applied with a slight change (applied escapetool.url for safety) >> >> Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/XWikiGroupSheet.xml >> =================================================================== >> --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/XWikiGroupSheet.xml 2011-02-10 20:37:52 UTC (rev 34622) >> +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/XWikiGroupSheet.xml 2011-02-10 20:38:15 UTC (rev 34623) >> @@ -171,7 +171,7 @@ >> }, >> addNewMember: function(uorg, input) { >> if (input) { >> - var url = "${doc.getURL()}?xpage=adduorg&uorg=" + encodeURIComponent(uorg) + "&name=" + encodeURIComponent(input.value); >> + var url = "${doc.getURL()}?xpage=adduorg&uorg=" + encodeURIComponent(uorg) + "&name=" + encodeURIComponent(input.value) + "&form_token=$!{escapetool.url($services.csrf.getToken())}"; > > actually, $services.csrf.getToken() returns the token in a URL-safe > base64 encoding, so it should work fine without escapetool. I know, but an extra encoding doesn't break anything. > Regards, > Alex > >> new Ajax.Request(url, { >> method: 'get', >> onSuccess: function(transport) { >> -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 10 months

[xwiki-devs] [proposal] More con.xpn.xwiki.store.* deprecations.

by Caleb James DeLisle

I would like to propose another round of storage deprecations, the goal of these is to remove and decrease visibility of code in order to simplify storage and move as much as possible over from API to implementation details. I am proposing deprecation of each of the following, after 2 releases this may be revisited and they may be removed or altered. The following are changes I have made locally and found xwiki-core does compile and test with those changes. For now I propose adding deprecation comments and annotations to each class or method. WDYT? Caleb XWikiAttachmentStoreInterface.java saveAttachmentContent(XWikiAttachment attachment, XWikiContext context, boolean bTransaction) remove cleanUp(XWikiContext context) remove XWikiBatcher.java remove entirely XWikiBatcherFactory.java remove entirely XWikiBatcherStats.java remove entirely XWikiDefaultStore.java remove entirely XWikiHibernateBaseStore.java getDatabaseProductName(XWikiContext context) public --> protected shutdownHibernate(XWikiContext context) remove updateSchema(XWikiContext context) public --> private getSchemaFromWikiName(String wikiName, DatabaseProduct databaseProduct, XWikiContext context) protected --> private getSchemaFromWikiName(XWikiContext context) protected --> private getSchemaUpdateScript(Configuration config, XWikiContext context) public --> private updateSchema(String[] createSQL, XWikiContext context) public --> private updateSchema(BaseClass bclass, XWikiContext context) remove isVirtual(XWikiContext context) public --> protected beginTransaction(SessionFactory sfactory, XWikiContext context) public --> protected beginTransaction(SessionFactory sfactory, boolean withTransaction, XWikiContext context) public --> protected endTransaction(XWikiContext context, boolean commit, boolean withTransaction) public --> protected execute(XWikiContext context, boolean bTransaction, boolean doCommit, HibernateCallback<T> cb) public --> private XWikiHibernateStore.java getContent(XWikiDocument doc, StringBuffer buf) remove public List search(Query query, int nb, int start, XWikiContext context) remove injectCustomMappingsInSessionFactory(BaseClass bclass, XWikiContext context) public --> private injectCustomMappingsInSessionFactory(XWikiContext context) public --> private XWikiHibernateVersioningStore.java loadAllRCSNodeInfo(XWikiContext context, final long id, boolean bTransaction) protected --> private

13 years, 10 months

[xwiki-devs] [Announcement] Bug Fixing Day Today!

by Sergiu Dumitriu

Hi community, As previously announced, today is a Bugfixing Day, and everyone is welcome to participate with bug reporting, patching, or issue cleanup. The rules are simple: - First try to synchronize on the IRC channel (#xwiki on irc.freenode.org) - When closing an issue, add a "bugfixingday" keyword to it, so that it can be correctly assigned to this group effort - The status is available at http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=r… Have fun! -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r34589 - enterprise/trunk/wiki/src/main/resources/XWiki

by Jerome Velociter

Don't we change the current behavior of displaying field with syntax inside, doing that ? On Wed, Feb 9, 2011 at 1:04 PM, sdumitriu < enterprise-notifications(a)xwiki.org> wrote: > Author: sdumitriu > Date: 2011-02-09 13:04:28 +0100 (Wed, 09 Feb 2011) > New Revision: 34589 > > Modified: > enterprise/trunk/wiki/src/main/resources/XWiki/LiveTableResults.xml > Log: > XE-829: Document names containing \ break livetables > Fixed. > > Modified: > enterprise/trunk/wiki/src/main/resources/XWiki/LiveTableResults.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/XWiki/LiveTableResults.xml > 2011-02-09 11:51:00 UTC (rev 34588) > +++ enterprise/trunk/wiki/src/main/resources/XWiki/LiveTableResults.xml > 2011-02-09 12:04:28 UTC (rev 34589) > @@ -25,7 +25,7 @@ > <hidden>false</hidden> > <content>{{include document="XWiki.LiveTableResultsMacros" /}} > > -{{velocity}} > +{{velocity wiki="false"}} > #set($extra = "") > #set($params = []) > #if("$!request.space" != '') > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications >

13 years, 10 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2011