xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-notifications] r33164 - platform/web/trunk/xwiki-gwt-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/public/stylesheets

by Sergiu Dumitriu

On 11/28/2010 07:54 PM, Marius Dumitru Florea wrote: > Hi Sergiu, > > I've fixed this issue locally by making the selector more specific: > > #body.main (instead of body.main) > > and > > * html #body.main (instead of * html body.main) > > I think this is better because all the rules in RichTextArea.css are > suppose to be overwrites and putting !important everywhere is an > overhead. I hope you agree. Isn't RichTextArea.css supposed to be independent of XWiki? #body is XWiki specific, so it won't always work outside XWiki. Actually, the independence is already sacrificed by the use of the color theme. I looked around when determining what's the best thing to do, and I saw that !important was already used in the same ruleset for setting the background and text color. Anyway, I'm not that familiar with the WYSIWYG, so I'll leave the decision to you, feel free to change it if you consider it's better. > On 11/28/2010 03:58 AM, sdumitriu (SVN) wrote: >> Author: sdumitriu >> Date: 2010-11-28 02:58:54 +0100 (Sun, 28 Nov 2010) >> New Revision: 33164 >> >> Modified: >> platform/web/trunk/xwiki-gwt-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/public/stylesheets/RichTextArea.css >> Log: >> XWIKI-5736: Horizontal scrollbar always visible in the WYSIWYG editor on small screens >> Fixed. >> >> Modified: platform/web/trunk/xwiki-gwt-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/public/stylesheets/RichTextArea.css >> =================================================================== >> --- platform/web/trunk/xwiki-gwt-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/public/stylesheets/RichTextArea.css 2010-11-28 01:47:54 UTC (rev 33163) >> +++ platform/web/trunk/xwiki-gwt-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/public/stylesheets/RichTextArea.css 2010-11-28 01:58:54 UTC (rev 33164) >> @@ -32,8 +32,8 @@ >> float: left; >> height: auto; >> margin: 0; >> - min-height: 100%; >> - min-width: 100%; >> + min-height: 100% !important; >> + min-width: 100% !important; >> overflow: visible; >> padding: 0; >> position: static; -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 2 months

[xwiki-devs] Office document converter configuration

by Marius Dumitru Florea

Hi devs, Currently, the office importer module doesn't expose any configuration options for the office document conversion. Most of the available parameters are used to control the connection to the open office server. Office importer module uses jodconverter ( http://code.google.com/p/jodconverter/ ) to convert from different office document formats to HTML. The conversion is controlled by a "document format registry". jodconverter provides two DocumentFormatRegistry implementations: * a default implementation, that can be configured only programmatically; this is the one we're currently using * an implementation that reads the configuration from a JSON file; this is easy to overwrite by putting a document-formats.js file (with the JSON configuration) in /WEB-INF/classes/ I'd like to change the office import module to use the JSON document format registry if possible (i.e. document-formats.js is present and can be parsed) otherwise the default document format registry. This will allow us to control, for instance, the size of the images generated when importing/viewing a presentation (the default size is 640x480 which is not enough if you have slides with a lot of information). Do you think this is worth introducing in 2.7 or should I wait for 3.0? Thanks, Marius

14 years, 2 months

[xwiki-devs] [Investigation] User Statuses

by Ecaterina Moraru (Valica)

Hi, There are some features that need to be investigated during the XE 2.7 timeframe in order to be able to integrate them in XE 3.0. One of them is **User Statuses** and a main definition for it is: "On top of activity stream <http://code.xwiki.org/xwiki/bin/view/Macros/ActivityMacro>, create a User status & twitter integration feature" The question is what should we integrate and cover if we want to have user statuses in XE. In order to deploy mockups I need to have some clear requirements and uses cases. I create some pages on incubator that will gather this mail discussions at: Requirements: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusRequirem… Use Cases: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusUseCases While discussing Activity Stream design we had some design scraps for the status casting part http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusScrap Please share your vision. Thanks, Caty

14 years, 2 months

Re: [xwiki-devs] [xwiki-notifications] r33131 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: . api

by Vincent Massol

wold be good to move it to the existing aspect. Thanks -Vincent On Nov 25, 2010, at 9:28 AM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-11-25 09:28:29 +0100 (Thu, 25 Nov 2010) > New Revision: 33131 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > Log: > XWIKI-5725: Deprecate XWiki#parseMessage > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-11-24 15:04:26 UTC (rev 33130) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-11-25 08:28:29 UTC (rev 33131) > @@ -7001,6 +7001,11 @@ > return doc.validate(context); > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String getMessage(String item, XWikiContext context) > { > XWikiMessageTool msg = context.getMessageTool(); > @@ -7011,6 +7016,11 @@ > } > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String parseMessage(String id, XWikiContext context) > { > XWikiMessageTool msg = context.getMessageTool(); > @@ -7018,6 +7028,11 @@ > return parseContent(msg.get(id), context); > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String parseMessage(XWikiContext context) > { > String message = (String) context.get("message"); > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-11-24 15:04:26 UTC (rev 33130) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-11-25 08:28:29 UTC (rev 33131) > @@ -844,37 +844,46 @@ > } > > /** > - * API to parse the message being stored in the Context A message can be an error message or an information message > - * either as text or as a message ID pointing to ApplicationResources The message is also parse for velocity scripts > + * API to parse the message being stored in the Context. A message can be an error message or an information message > + * either as text or as a message ID pointing to ApplicationResources. The message is also parse for velocity scripts > * > * @return Final message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String parseMessage() > { > return this.xwiki.parseMessage(getXWikiContext()); > } > > /** > - * API to parse a message A message can be an error message or an information message either as text or as a message > - * ID pointing to ApplicationResources The message is also parse for velocity scripts > + * API to parse a message. A message can be an error message or an information message either as text or as a message > + * ID pointing to ApplicationResources. The message is also parse for velocity scripts > * > * @return Final message > * @param id > * @return the result of the parsed message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String parseMessage(String id) > { > return this.xwiki.parseMessage(id, getXWikiContext()); > } > > /** > - * API to get a message A message can be an error message or an information message either as text or as a message > - * ID pointing to ApplicationResources The message is also parsed for velocity scripts > + * API to get a message. A message can be an error message or an information message either as text or as a message > + * ID pointing to ApplicationResources. The message is also parsed for velocity scripts > * > * @return Final message > * @param id > * @return the result of the parsed message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String getMessage(String id) > { > return this.xwiki.getMessage(id, getXWikiContext());

14 years, 2 months

[xwiki-devs] [Proposal] Deprecate $xwiki.parseMessage

by Thomas Mortagne

Hi devs, $xwiki.parseMessage is used to parse velocity located in a translation message. Thing it for me it's very bad (bad design and very bad for performances and most of all for security) to have velocity in translation messages which makes $xwiki.parseMessage useless and some other would say a security hole (see http://jira.xwiki.org/jira/browse/XWIKI-5684). So I propose to deprecate it in 2.7 to make sure we don't use that anymore. WDYT ? -- Thomas Mortagne

14 years, 2 months

[xwiki-devs] [proposal] A different approach to filesystem attachment storage.

by Caleb James DeLisle

I would like to propose a different method for attachment storage. I have spent some time working on referencing using a UUID and have run into problems with how to garbage collect files if the corresponding database entry should go missing as well as problems with getting UUID standardization approved. I would like to try a different direction. There will be a directory for the wiki, one for the space and one for the document. Inside of the document directory will be the attachments. An attachment called myImage.png attached to the document xwiki:Main.WebHome will be placed in the following location: <filesystem store directory>/xwiki/Main/WebHome/attachments/myImage.png If there is an XWikiAttachment entry in the database, the metadata from that entry will be matched with the attachment. If there is no metadata entry but there is a file, empty metadata will be created. Users will have the option of adding attachments to documents by copying the files into the relevant directory. An escaping scheme will have to be adopted to prevent attachments named ../../../../../etc/passwd or the like. I have not started on this, I would like to see some +1 before I start writing code. WDYT? Caleb

14 years, 2 months

[xwiki-devs] [discussion] Global and space dashboards implementation

by Anca Luca

Hi devs, ** short story: ** for XE-722 we'd need to implement the main and spaces dashboards separately ** long story: ** currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards. With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard). ** options: ** 1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general 2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though. Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability. I'd +1 for 1) and I'd choose 2c). WDYT? Thanks a lot, Anca

14 years, 2 months

[xwiki-devs] [Proposal] Add a http://design.xwiki.org wiki?

by Vincent Massol

Hi devs, In the same manner that we have playground.xwiki.org, I'd like to propose to have a design.xwiki.org wiki for putting our Designs and Mockups (be them static or dynamic). Right now we have design and mockup information in 2 places: - http://dev.xwiki.org/xwiki/bin/view/Design/ - on incubator.myxwiki.org I'd like to propose that we merge them both on a new http://design.xwiki.org wiki (using latest XE 2.6 version). Note: If we had support for nested spaces I'd have proposed that we do it on the existing dev.xwiki.org wiki but we'll probably need several pages for each Design proposal. On design.xwiki.org I envision a home page listing all Design ideas with the ability to filter by state (implemented, in progress, dead). I envision one space per design idea and each home page would contain a DesignIdea object containing the metadata (status, etc). Similar to what we have on http://dev.xwiki.org/xwiki/bin/view/Design/ WDYT? Thanks -Vincent

14 years, 2 months

[xwiki-devs] [UserStory] Wiki Archetypes

by coldserenity

Hi, Devs Recently one idea have crossed my mind. Thought that it might be interesting to XWiki community. It would be nice to implement something like Maven Archetypes, just for Wikis. That is a "XWiki Archetype Plug-in". Imagine a Wiki for software development project (SDP). Its structure might be more or less the same for most of the project. You would have * Place for storing development environment description and set-up * There should also be a place for developers to store some hints, code snippets etc. * A place for "User stories" and communications with customers * Meetings tracking place (where you keep meeting minutes, IRC logs) * List of deliveries and release notes. All of the above is something a modern quality-managed project cannot survive without. And with XWiki it can be gathered into a set of templates in a single *.xar archive like a Maven Archetype. At some level it can be done even with existing tools the XWiki provides. However it can be extended even more: * Archetypes can contain information about plug-ins and extensions they depend on. E.g. there may be a separate meeting minutes application which needs to be installed for our SDP Archetype example. * Parametrized archetypes (e.g. provide project name for SDP Archetype) * Special UI designed to import an archetype (e.g. choose which parts (pages and plug-ins) of the archetype you would want in your Wiki) * Special UI designed to search Wiki Archetype repository * Special UI for extracting an Archetype from existing Wiki Does it sound as a viable user-story? What kinds of other Archetypes you can think of? Does it worth the effort, to be able to quickly start-up your wikis and have them conform to the same style? Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/UserStory-Wiki-Archetypes-tp5766157p57661… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 2 months

[xwiki-devs] [Vote] XWiki.org ColorThemes

by Ecaterina Moraru (Valica)

Hi, According to the general opinion discussed at http://xwiki.markmail.org/thread/2b3io6wv4yzr324q , proposal 7 had the most votes. Here is the final proposal for XWiki.org Color Themes in the default Colibri skin: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/OrgColorThemes The xars are attached to the page and can be imported if the vote passes. My +1 Thanks, Caty

14 years, 2 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