xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-notifications] r18410 - in platform/web/trunk: standard/src/main/webapp/resources/js/smartclient standard/src/main/webapp/templates wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/link wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/link/ui wysiwyg/src/main/resources/com/xpn/xwiki/wysiwyg/public/stylesheets

by Jerome Velociter

Hi lucaa (SVN) wrote: > Author: lucaa > Date: 2009-04-10 10:27:02 +0200 (Fri, 10 Apr 2009) > New Revision: 18410 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/js/smartclient/overwritesc.js I think this file should be under a xwiki/ folder to make it clear its not part of the SC framework. A better place IMO would be resources/js/xwiki/smartclient/overwritesc.js [snip]

15 years, 10 months

[xwiki-devs] [Proposal] Default mock implementation for the xwiki-bridge component

by Sergiu Dumitriu

Hi devs, All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?) We currently have 4 mock implementations. A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

[xwiki-devs] [Gsoc-2009] Class level approach for the Photo Album is added

by Harsha Halgaswatta

Hi marta , all I have added the class level approach for the photo album application [1] , after going through some applications. Please have a look and give me any feedbacks [1] : http://docs.google.com/Doc?id=dhh6gcfm_721hhgxstfk Thanks in advance Harsha

15 years, 10 months

[xwiki-devs] [VOTE] How to handle large content inside string properties

by Sergiu Dumitriu

Hi devs, While trying to fix XWIKI-1480, the following question was raised: What to do with large values placed inside a StringProperty? StringProperties are defined to hold at most 255 characters (which are actually bytes in mysql). Some databases automatically ignore this limit (this is the case with hsql, which is the default database for our standalone package), while others throw exceptions when trying to commit the transaction (mysql does this). Currently, we don't handle this exception at all, so it bubbles up to the UI in the form of a stack trace. XWIKI-1480 is about fixing this error. What can be done: 1. Always trim the content to 255 bytes. This is a regression from the point of view of hsql users, which will suddenly notice that their data gets truncated. 2. If the data is larger than 255 bytes, silently ignore this new value, and continue using the previous one. This is also bad, since users won't understand why doesn't the value get saved, and is a regression on hsql. 3. Try to use this value, but if an exception is thrown, truncate the data and commit again. This fixes the regression part, but might still be surprising to users. 4. Continue as before, but catch the exception and display a nice warning message to the user. This looks like the safest approach, but it fails when manipulating data from outside the UI, like scripts and XmlRpc connections. So, what is the best approach? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

[xwiki-devs] TaskCode Skin affects display of boxes (e.g. code-macro in XWiki 2.0 Syntax)

by Bernhard Kämpf

Hello all I observed, that the TasksCode-Panel inserts css style definitions to the html-code. Unfortunately this css defines a .box class style. It seems, that this .box class definition affects display of several objects, e.g. the general Comment Box or the box created by the code-macro (when using XWiki 2.0 Syntax). (the code-macro in 2.0 Syntax actually refers to class="box code", but none of the css defines a box.code-class, so obviously the .box class is used). Regards Bernhard Kaempf PS: As a ugly quick fix I hacked the TasksCode Skin (by altering the name of .box class) PPS2: XWikiUserSheet is not displayed under Syntax2.0

15 years, 10 months

[xwiki-devs] [GSoC2009] eBay and Apache Shindig for OpenSocial

by Anamaria Stoica

eBay's new Selling Manager (beta) <http://developer.ebay.com/web20> uses Apache Shindig to integrate OpenSocial !! :) http://google-code-updates.blogspot.com/2009/04/ebays-farhang-kassaei-annou… Anamaria

15 years, 10 months

[xwiki-devs] [VOTE] Introduce DocumentAccessBridge::setProperty() method

by Asiri Rathnayake

Hi devs, I need to add some tags into a document via officeimporter. For this I need to have above method implemented in DocumentAccessBridge. The most generic method signature would be: void setProperty(String documentName, String className, int objectNumber, String propertyName, Object value) throws Exception; But for my use case following would be enogh: void setProperty(String documentName, String className, String propertyName, Object value) throws Exception; I'm currently +1 for second signature. WDYT? Note: this method has been implemented in issue: http://jira.xwiki.org/jira/browse/XWIKI-2831 but this patch seems to have lot more other (unnecessary) methods. Thanks. - Asiri

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r18354 - in platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest: . resources/attachments

by Sergiu Dumitriu

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-04-08 23:58:20 +0200 (Wed, 08 Apr 2009) > New Revision: 18354 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/XWikiAuthentication.java > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/resources/attachments/AttachmentsResource.java > Log: > XWIKI-3542: Allow attachment upload in REST API using multipart form data > + @POST > + @Consumes(MediaType.MULTIPART_FORM_DATA) > + public Response addAttachment(@PathParam("wikiName") String wikiName, @PathParam("spaceName") String spaceName, > + @PathParam("pageName") String pageName, Multipart multipart) throws MessagingException, IOException, > + XWikiException > + { Fabio, could you change this to support uploading several files in a single request? This would be very useful. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r18222 - in platform/core/trunk/xwiki-xml/src: main/java/org/xwiki/xml/internal/html/filter test/java/org/xwiki/xml/internal/html

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2009-04-03 10:43:01 +0200 (Fri, 03 Apr 2009) > New Revision: 18222 > > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/filter/FontFilter.java > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/html/DefaultHTMLCleanerTest.java > Log: > XWIKI-3494: Font tag is not cleaned properly. > > * Fixed. > + public FontFilter() > + { > + fontSizeMap = new HashMap<String, String>(); > + fontSizeMap.put("1", "8"); > + fontSizeMap.put("2", "10"); > + fontSizeMap.put("3", "12"); > + fontSizeMap.put("4", "14"); > + fontSizeMap.put("5", "18"); > + fontSizeMap.put("6", "24"); > + fontSizeMap.put("7", "36"); > + } Asiri, using pt as font sizes is not good, because it will not fit well with custom skins. It is better to use relative font sizes, using either em or %, like: font size=1 => font-size: 0.6em; or: font-size: 60%; This way, fonts will be made larger or smaller compared to the current skin's normal font size. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

[xwiki-devs] Thoughts about the attachment and image insert

by Ludovic Dubost

I'm having some thoughts about the attachments and image insert. I just tested the current work on attachment link insert. The more I think about it, the more I believe that images and attachments should be mainly attached to the CURRENT page. It is a nice to have to be able to use images or attachments for other pages (and even less upload to another page). However, when I look at the superbe tree UI, I have the feeling it will actually get in the way of the main usage, which is having the file attached to the current page. Therefore I believe we should have 2 different UIs. One simple and one advanced. The simple one would only manager files or images attached to the current page. The advanced would be the tree one. I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

15 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs