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

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 10 Apr '09

10 Apr '09

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]

1 0

[xwiki-devs] [Proposal] Default mock implementation for the xwiki-bridge component
by Sergiu Dumitriu 10 Apr '09

10 Apr '09

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/

3 3

[xwiki-devs] [Gsoc-2009] Class level approach for the Photo Album is added
by Harsha Halgaswatta 10 Apr '09

10 Apr '09

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

1 0

[xwiki-devs] [VOTE] How to handle large content inside string properties
by Sergiu Dumitriu 09 Apr '09

09 Apr '09

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/

4 5

[xwiki-devs] TaskCode Skin affects display of boxes (e.g. code-macro in XWiki 2.0 Syntax)
by Bernhard Kämpf 09 Apr '09

09 Apr '09

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

1 0

[xwiki-devs] [GSoC2009] eBay and Apache Shindig for OpenSocial
by Anamaria Stoica 09 Apr '09

09 Apr '09

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

1 0

[xwiki-devs] [VOTE] Introduce DocumentAccessBridge::setProperty() method
by Asiri Rathnayake 09 Apr '09

09 Apr '09

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

2 2

Re: [xwiki-devs] [xwiki-notifications] r18354 - in platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest: . resources/attachments
by Sergiu Dumitriu 08 Apr '09

08 Apr '09

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/

1 0

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 08 Apr '09

08 Apr '09

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/

2 1

[xwiki-devs] Thoughts about the attachment and image insert
by Ludovic Dubost 08 Apr '09

08 Apr '09

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

5 8