xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] IE issue with placing the caret at the beginning of a text node

by Marius Dumitru Florea

Hi devs, To explain the issue lets consider the following scenario: * Edit a new page with the new WYSIWYG editor. * Type "foobar" and place the caret as in "foo|bar", where the pipe represents the caret. * Press the Bold button or type CRTL+B in order to start typing bold text at the current insertion point. * At this moment, the HTML should be "foo|bar" where the pipe represents the caret. The Problem In Mozilla it's easy to place the caret as suggested. In IE it's impossible (this weekend I tried all sort of things and search desperately on Google..). What I can easily do in IE is either "foo|bar" or "foo|bar". The workaround that I found is to use a special space symbol http://en.wikipedia.org/wiki/Zero-width_non-joiner inside the strong tag (before, it had an empty text node inside) and place the caret just after this special space symbol. PROs: * When the use will type the text will be bold. CONs: * Although the space character is not visible you have to jump over it while navigating with the arrow keys. * Although we can remove these special symbols before converting to wiki syntax, the user will have them when copy&pasting. I'm in favor of using this special space symbol. WDYT? Thanks, Marius. P.S.: I need your opinion ASAP, thanks!

16 years, 3 months

[xwiki-devs] [VOTE] Make ditribution maven packages not "generics" anymore

by Thomas Mortagne

Hi devs, I finished a maven build for XWiki+GlassFish+derby distribution. So this means a distribution not based on jetty and we can't use database profile to decide what distribution to build anymore. So I propose: 1) havnig distributions like jetty-hsqldb, glassfish-derby, etc. and to remove distribution we are not releasing/using right now on XE/XEM like hsqldb-pgsql, hsqldb-derby etc. On maven build this means that to build XE glassfish-derby you will need to execute: - on XE parent : mvn install -Pci,derby,glassfish-derby - on the distribution : mvn install This will change all distributions ids but I don't think it's a problem. 2) jetty-hsqldb remain the default distribution for now Here is my +1 for both -- Thomas Mortagne

16 years, 3 months

[xwiki-devs] [vote] Apply inline style to the whole word or just the insertion point?

by Marius Dumitru Florea

Hi devs, Let's consider the following scenario: * Edit a new page with the new WYSIWYG editor. * Type a word like "ubuntu". * Move the caret inside the word like "ubu|ntu". * Press the Bold button or type CTRL+B. Question: What is the expected behavior? a) Apply the inline style (bold) only to the insertion point. The next letters typed will have this style applied. b) Apply the inline style (bold) to the word that contains the insertion point ("ubuntu"). Note: b) is the current behavior in Open Office and IE. FF behaves as in a). The behavior currently implemented in the new WYSIWYG editor is a). Also, by choosing b) I avoid the use of the special space character in IE (see my previous mail), but I have to re-implement the current behavior of the new WYSIWYG. I need around 2 days for it. Of course, it will work for any inline style like bold, italic etc. I'm +1 for b) Thanks, Marius.

16 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r13850 - sandbox/xwiki-plugin-officeimporter

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-10-27 14:00:09 +0100 (Mon, 27 Oct 2008) > New Revision: 13850 > > Removed: > sandbox/xwiki-plugin-officeimporter/BUILD > sandbox/xwiki-plugin-officeimporter/README > Log: > Removing out dated / unnecessary files. > The README file contained useful information; I hope you copied it someplace else (the xwiki.org site) before, right? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r13849 - in sandbox: xwiki-application-officeimporter xwiki-plugin-officeimporter

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-10-27 13:49:42 +0100 (Mon, 27 Oct 2008) > New Revision: 13849 > > Modified: > sandbox/xwiki-application-officeimporter/pom.xml > sandbox/xwiki-plugin-officeimporter/pom.xml > Log: > Changing the name of the officeimporter plugin & application to make more sense. Asiri, the description of the field should not duplicate the name. - The artifactId should be lowercase, no space, and have a specific format (like xwiki-plugin-alexa); this is an identifier intended for machines, to be able to identify and locate the artifact. - The name should be like a breadcrumb, from general to specific, human readable, separated by dashes (like XWiki Platform - Plugins - Alexa); this is a human readable identifier (name) of the project, intended for humans to quickly see what module this is. - The description should be prose, describing what the module does. It is intended to describe the purpose of the module. I know that most of the modules simply use the name as the description, but that does not add any useful information, thus it is wrong. See http://maven.apache.org/pom.html#More_Project_Information and http://maven.apache.org/ref/current/maven-model/maven.html#class_project > - <description>import office documents such as MS word to xwiki page</description> > + <description>XWiki Platform - Applications - Office Importer</description> -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

[xwiki-devs] JMesa and our new table support in the new rendering?

by Vincent Massol

Hi Thomas (and others), Just found JMesa: http://code.google.com/p/jmesa/ Maybe that's something we could be interested in using for our new table implementation? Or maybe not. I just wanted to raise the topic (note that dynamic table support is planned for XE 1.8 and not 1.7). One caveat: It seems to like JQuery. I don't know if it'll work with prototype for example. Thanks -Vincent

16 years, 3 months

[xwiki-devs] [vote] Next localization steps

by Sergiu Dumitriu

Hi devs, The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item): 0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me 3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners 6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge. >From me, +1 to all of these. WDYT? Any volunteers where needed? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

[xwiki-devs] JCRStore status

by Artem Melentyev

Hi. I just committed JCRStore prototype based on JCRv1 to sandbox/jcrstore Ideas of the prototype: 1. use value objects for storage (xwiki data model proposal: sandbox/org.xwiki.model) org.xwiki.store.value.* value objects allow us to eliminate xwiki-core dependency in jcrstore. we can reuse value objects in new data model later as in sandbox/org.xwiki.model. 2. put all storage specific code in DAO classes. Stores will remain only business code and delegate storage stuff to DAOs. (stores will deprecated by new data model later) 3. convert value objects to/from xwiki business objects. org.xwiki.store.value.ValueConverter planed jcr hierarchy: (node name (node type)) / <space> (xwiki:space) <docname> (xwiki:document) objects <class.name> <number> (xwiki:object) properties (Jcr Value or Value[]) attachments <filename> (xwiki:attachment extends nt:resource) lock (xwiki:lock) translations <language> (xwiki:document) (translations of document) the main problem: JCRStore needs JCRSQL2 language from JCRv2 (JCRv1 has very limited query languages), but: JSR-283 aka JCR v2 isn't still out. It was planed for September. http://jcp.org/en/jsr/detail?id=283 Jackrabbit's JCRSQL2 parser is still in progress (and unusable yet). eXoJCR v2 also in progress: http://jira.exoplatform.org/browse/JCRS I'm afraid JCR v2 may not release before XE-1.7. JCRv2 release was shifted several times before. :(. JcrStore plans: implement base JcrDAOs. (JcrDocumentDAO is ready) try to run xwiki on jcrstore. (not fully possible without JCRSQL2, but may show some problems in store) implement XWQL to JCRSQL2 translator. wait for JCRv2 or at least working JCRSQL2. test XWQL on JCRSQL2. rewrite all HQL queries to XWQL. Delivery date: If JCRv2 (or JCRSQL2) will release in a ~week then I'll implement base functionality in 1.7M2 and improve it in 1.7RC1. If not then 1.8M1 PS: I'm sorry for long delay. I was ill 2.5 last weeks. It very reduce my activity. -- Artem Melentyev

16 years, 3 months

Re: [xwiki-devs] Mozilla Add-ons: FoXWiki Nomination

by Asiri Rathnayake

Hi All, Thanks for your support to make FoXWiki a public plugin :) Btw, if you have any suggestions for new features you expect in a future version of FoXWiki, please dump them in this thread ;) - Asiri On Sat, Oct 25, 2008 at 7:42 AM, Mozilla Add-ons <nobody(a)mozilla.org> wrote: > Congratulations! Your nominated add-on, FoXWiki, has been reviewed by a > Mozilla Add-ons editor who approved your add-on to be public. > > Your most recent version (1.0b) has also been made public. > > You can view your public add-on now at: > http://addons.mozilla.org/addon/2358 > > Review Information: > Reviewer: shane hansen > Comments: Congratulations, your addon has been approved for public > status. > > Keep up the good work! > I did notice that you had an empty "general" preferences tab, which is kind > of distracting for users. > If you have questions about this review, please e-mail > amo-editors(a)mozilla.org or join #addons on irc.mozilla.org. > > Mozilla Add-ons > http://addons.mozilla.org > >

16 years, 3 months

[xwiki-devs] mute error while importing xar

by Paul Libbrecht

Hello XWikiers, I'm importing the base xar on a brand new xwiki and... well... - upload works flawlessly - clicking on the archive as well (this should have a wait UI btw!) - but then I get the following text with no information in the console > > Import > > Import > Importing curriki-wiki.xar: Error while preparing importing > > * 0 Document(s) installed > * 0 Document(s) skipped > * 0 Document(s) with error > (preceded by the warning the wiki is empty) Is there a switch somewhere to raise verbosity and get info about what went wrong? As I said, the list of files is there (and big). paul PS: for curriki-aware folks, that xar was created with the current curriki checkout after removal of package.xml. I get the same results if I use the svn-ed package.xml.

16 years, 3 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