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

[xwiki-devs] New rendering/wysiwyg feedback needed

by Vincent Massol

Hi everyone, As you may have heard we've started implementing a new wiki syntax for XE 1.6 and above. The documentation draft is available here: http://dev.xwiki.org/xwiki/bin/preview/Drafts/XWikiSyntax20 We would be interested in getting your feedback on how well it works, any issue you may have or any suggestion for further improvement. You can grab a snapshot version of XE 1.6 here: * Standalone version: http://tinyurl.com/3w4upj * WAR: http://tinyurl.com/3nwy4z * XAR: http://tinyurl.com/3pvmkc To use it, log in as admin, edit a page, select "XWiki 2.0" in the syntax field in the Panel on the right and you'll be using the new syntax. If you set your page to use the 2.0 syntax and if you use the WYSIWYG editor you'll also notice that you'll be using the new GWT WYSIWYG editor. This is a work in progress for which we're also interested in feedback. However it's not finished yet, see http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface for how it's going to look like when finished. If you find any issue please enter it in our issue tracker: http://jira.xwiki.org/jira/browse/XWIKI so that we can fix it for the final 1.6 release (due in a few days). Thanks for your help -Vincent

17 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r12815 - in platform/core/trunk/xwiki-rendering/src: main/java/org/xwiki/rendering/renderer test/resources/paragraph

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-09-21 01:15:55 +0200 (Sun, 21 Sep 2008) > New Revision: 12815 > > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/XHTMLRenderer.java > platform/core/trunk/xwiki-rendering/src/test/resources/paragraph/paragraph1.test > Log: > XWIKI-2687: GWT WYSIWYG editor removes new lines when pasting content > * Use the expanded form for DIV: <div></div>. For some reason the short form <div/> doesn't work fine for xwiki in FF3 (even though the XHTML validator says it's valid). That's probably because of the mime-type. For XML to work properly, it should be sent as application/xhtml+xml or something like that. text/html triggers the plain HTML parser. Anyway, it is better this way, as IE (<=6) does not accept XHTML even with the right mime-type. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r12806 - sandbox/xwiki-rootwebapp

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-09-19 20:01:01 +0200 (Fri, 19 Sep 2008) > New Revision: 12806 > > Modified: > sandbox/xwiki-rootwebapp/ > sandbox/xwiki-rootwebapp/.classpath > sandbox/xwiki-rootwebapp/.project > Log: > Committing project files. > You should not commit this kind of files. Project files are created by maven on each developer's computer, according to his working environment. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years

3
3
0 0

[xwiki-devs] [Rendering] Final syntax decisions and remaining issues

by Vincent Massol

Hi, I've updated this page http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiSyntax20 which describes both XWiki syntax 1.0 and XWiki Syntax 2.0. I want to make sure we agree with the following syntax decisions and especially with regards to Creole since we want to be close to it. One disclaimer though: the creole specification is badly done and is not strict enough. There are lots of ambiguities in their descriptions of the syntax elements so it's almost impossible to ensure to be fully compatible with some element syntaxes. 1) New lines Right now we honor new lines (we've all already voted to have this). I just wanted to point out that this is different from Creole. 2) Horizontal lines We accept 4 or more dashes. Creole says it's 4 dashes only. However if you try it on their test page at http://www.wikicreole.org/EditX.jsp?page=JSPWikiTestCases if works fine with more than 4 dashes too. 3) Special numbered lists Is it ok to have this syntax: (% class="roman" %) 1. item1 1. item2 Or do we introduce new syntax elements as it's done in XWiki Syntax 1.0: i. item1 i. item2 See http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiSyntax20#HLists for more examples. I have the feeling it would be better to use our 1.0 syntax for this (note that this requires some heavy changes to wikimodel - Will need to discuss it with Mikhail). 4) Images There's currently no special support for images in wikimodel. The solution wikimodel proposes is to implement its support through linline links. For example: This is an image:my.png image. As you can see the image is specified as a URI. Ok with everyone? Thanks -Vincent

17 years

7
18
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.5.2 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.5.2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is a quick release for important regression found in 1.5.1. Changes from 1.5.1: * XWIKI-2649 - xwiki.authentication.ldap.mode_group_sync is not "always" by default * XWIKI-2655 - Members of LDAP group detected with case sensitivity * XWIKI-2663 - Image plugin does not resize .gif images * XWIKI-2672 - new parseTemplate breaks setCacheDuration * XWIKI-2681 - Minor edit checkbox and default language field doesn't work * XE-301 - XE's xar has both pages with and without the .xml extension For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise152 Thanks -The XWiki dev team

17 years

1
0
0 0

[xwiki-devs] [VOTE] Release XWS 1.2 Milestone 1

by Jerome Velociter

Dear devs, I would like to release the first Milestone of XWiki Workspaces 1.2 next week, ideally Thuesday, with the following release notes : http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10302&… XWiki Workspaces 1.2 Iteration focuses on new features like UI refactorings, global search, custom groups, and typed spaces. Check http://workspaces.xwiki.org/xwiki/bin/view/Main/Roadmap. My +1 for it, Jerome.

17 years

6
6
0 0

[xwiki-devs] Login Password readable in password input

by Michael Dietrich

Hello XWikiers, today I encountered the problem, that my login password was readable as plain text. After some tests the login input worked again, without changing anything. This worries me quite a bit, because I cannot predict whether this will happen again and after it happens the browser's autocompletion suggests passwords to type. Does anyone of you encounter familiar problems or is having an explanation. We were thinking that it has something to do with the trick you are using to make the "password" label readable in the password input element. May this be? Thanks in advance for your help. Regards, Michael ----required by german law----------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 -------------------------------------------------------------

17 years

2
1
0 0

[xwiki-devs] #actionmenu .editinfo CSS IE bug and fix

by Art Yeung

Hi All, Noticed a bug in IE, If the page title has multiple words separted by white spaces, then the action menu wrap it into multiple lines. Firefox is fine. After adding the nowrap into the CSS seems fixed the issue. so FYI. #actionmenu .editinfo a { white-space:nowrap; } Cheers, Art -- View this message in context: http://n2.nabble.com/-actionmenu-.editinfo-CSS-IE-bug-and-fix-tp1100710p110… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years

1
0
0 0

[xwiki-devs] Fwd: [ANN] Maven 2.1.0-M1 Released

by Vincent Massol

fyi -Vincent Begin forwarded message: > From: John Casey <jdcasey(a)apache.org> > Date: September 19, 2008 5:33:54 AM CEDT > To: Maven Users List <users(a)maven.apache.org>, Maven Developers > List <dev(a)maven.apache.org>, announce(a)maven.apache.org > Subject: [ANN] Maven 2.1.0-M1 Released > Reply-To: "Maven Developers List" <dev(a)maven.apache.org> > > The Maven team is pleased to announce the release of the Maven 2.1.0- > M1. > > This release signals the beginning of a new direction in the > development of Maven. Recently, Maven's development efforts were > split into three major goals. First, the Maven 2.0.x code line will > be minimally maintained for regression fixes; the 2.0.x series > should be entering end-of-life mode soon now that 2.1.0-M1 is out. > > Next, the 2.x series aims to accomplish a relatively conservative > series of new features, improved implementations, and other changes > that bring with them too much risk to be appropriate for a revision > release on the 2.0.x version series. Each of these releases - 2.1, > 2.2, and so on - will be preceded by a formal release plan. > > Finally, the 3.x series is the home of Maven's more aggressive > improvements, including wholesale reimplementation of subsystems and > the introduction of major new features. > > This means that all discussions in the past that referred to Maven > 2.1 now apply mainly to Maven 3.x, currently under development. We > will backport some of the smaller features to the 2.x version > series, provided we can contain the risk of these features and > provide a smooth transition from one version to the next for the user. > > You can download Maven here: > > http://maven.apache.org/download.html > > > Release Notes - Maven 2 - Version 2.1.0-M1 > > > ** Bug > * [MNG-2068] - Multiple inheritance fails to find "grand" parent > in ../../pom.xml when the groupIds differ (Test Case Attached) > * [MNG-2318] - When a project has modules and its parent is not > preinstalled the build fails > * [MNG-2695] - -o makes build fail for snapshot plugins > * [MNG-2739] - Repository entries are not validated and NPE will > occur > * [MNG-2873] - Unable to find transitive dependencies when they > have been relocated. > * [MNG-3052] - Transitive Dependency not found when repo is not > listed > * [MNG-3070] - ${x} properties no longer expanded in </version> > tag after 2.0.3 > * [MNG-3106] - Multiple profile activation conditions broken > * [MNG-3368] - Printing version (-v argument) should not stop > lifecycle execution > * [MNG-3380] - MavenMetadataSource retrieves ResolutionGroup > without consulting ManagedVersionMap, is problem when relocation > * [MNG-3475] - Some directories are not basedir aligned > * [MNG-3482] - merging managed dependencies happens before > managed-dependency versions are interpolated > * [MNG-3497] - rar, par and ejb3 archives should not be added to > classpath > * [MNG-3498] - StringIndexOutOfBounds -1 during path translation > while reading pom.xml > * [MNG-3527] - profile deactivation has no affect > * [MNG-3530] - Regression: Properties get resolved before the > LifeCycle is Forked. > * [MNG-3535] - Valid properties which look self referential fail > to resolve > * [MNG-3536] - REGRESSION: pom.build.sourceDirectory in Maven > 2.0.9: it doesn't work anymore > * [MNG-3545] - Option -P-profile overridden if profile is > activebyDefault > * [MNG-3581] - stage:copy ClassCastException with maven 2.0.9 > * [MNG-3584] - possible new memory leak in Maven 2.0.9 > * [MNG-3585] - nonProxyHosts separator is wrong in the default > settings.xml > * [MNG-3599] - webdav does not set http-proxy correctly > * [MNG-3622] - upgrade to wagon 1.0-beta-4 > * [MNG-3639] - Ant 1.7.0 Task not found after upgrading from > Maven 2.0.8 to 2.0.9 > * [MNG-3642] - back-propagation of resources doesn't handle > multiple resources with the same directory > * [MNG-3645] - Maven doesn't do strict model validation for POMs > in the current reactor > * [MNG-3651] - mvn.bat returns an incorrect error code > * [MNG-3654] - [regression] unable to build ServiceMix 3 - > IndexOutOfBoundsException in mergeDeterministicBuildElements > * [MNG-3667] - Dependencies resolution is wrong in some cases > (xfire-core:1.2.6 for example) > * [MNG-3671] - plugin-level dependencies in POMs are not > interpolated at correct time > * [MNG-3679] - <execution><id>${some.custom.var}</id> ... broke > * [MNG-3680] - POM validation fails on projects in central repo > starting with 2.0.10 RCs > * [MNG-3684] - Injection of Build instance as report parameter > results in uninterpolated values for build.directory, etc. > * [MNG-3693] - Updating project POM via project.setFile(..) > changes project basedir, and project classpath when used as a > dependency in a reactor > * [MNG-3694] - plugin parameters injecting $ > {project.compileSourceRoots} get uninterpolated source directories > * [MNG-3697] - NPE at DefaultPluginManager line 700 (from Hudson > CI) > * [MNG-3701] - ClassCastException when building settings.xml with > profiles that have activeByDefault set > * [MNG-3703] - ExecutionProject contains relative paths in > compileSourceRoots > * [MNG-3704] - NPE in DefaultLIfecycleExecutor when run from > within Hudson builds > * [MNG-3705] - Expression: ${executedProject} doesn't work in > reports > * [MNG-3710] - ModelUtils.cloneModel() and .cloneBuild() pollute > existing Plugin instances with merged information > * [MNG-3716] - Aggregators that fork lifecycles don't have > execution projects setup for all projects in the reactor. > * [MNG-3717] - Maven prompts for a password when one is provided > over SSH in some circumstances > * [MNG-3718] - Build timestamp interpolator gives hours in AM/PM > instead of 24-hour time > * [MNG-3722] - Fail to run CXF code generation with 2.0.10 RC > * [MNG-3723] - ${project.basedir} is not interpolated > * [MNG-3724] - ExecutionProject not getting updated compile/test- > compile/script roots in RC10 > * [MNG-3729] - Maven 2.0.10-RC10 fails with NPE on > assembly:assembly > * [MNG-3740] - Plugin builds that reference earlier versions of > themselves in the <plugins> section of the POM result in > StackOverflowError in 2.1.0-M1-RC12 > * [MNG-3741] - CLONE maven-plugin-tools-api requires relative > script root paths > * [MNG-3743] - pluginManagement not consulted when building from > lifecycle forked via javdoc reports > * [MNG-3746] - POM properties do not override default system > properties during POM interpolation > * [MNG-3747] - relative build paths are not path-translated when > using prefixed expressions (eg. project.build.directory) in plugin > configurations > * [MNG-3748] - settings builder doesn't use strict mode in xml > parser > > ** Improvement > * [MNG-2609] - Mention 'activeByDefault' in the "Introduction to > Build Profiles" guide > * [MNG-3268] - Command line doesn't handle multiple -P correctly > * [MNG-3478] - Use expression ${project.build.directory} instead > of hard-coding "target" in super POM > * [MNG-3509] - Make "mvn -v" output locale/encoding > * [MNG-3511] - Review fix for MNG-2166 > * [MNG-3520] - Korean message resource > * [MNG-3571] - Allow use of ! when deactivating profiles > * [MNG-3652] - set a user agent for Maven HTTP requests > * [MNG-3673] - Upgrade plugin versions in super-POM where > appropriate > * [MNG-3698] - Improve performance regarding concrete/dynamic > build transitions surrounding plugin executions and report > instantiations > * [MNG-3709] - Be sure source distro has the same name as the > binary distro in the repository. > > ** New Feature > * [MNG-2562] - expose current time as a property for POM > interpolation > * [MNG-2576] - Make Like Reactor Mode > * [MNG-3219] - Create a CLIRR/JarDiff setup for 2.0.x and 3.0.x > * [MNG-3675] - Add accessor for lifecycles list to > LifecycleExecutor/DefaultLifecycleExecutor > > > Enjoy, > > -The Maven team

17 years

1
0
0 0

[xwiki-devs] XWiki - Get Username.

by Prathap Pandian

Hi, How to get/print the existing xwiki username.(XWiki.Admin) in a separate page....? -- Prathap

17 years

3
3
0 0

[xwiki-devs] Maven 2.1.0 for test

by Vincent Massol

Hi, Maven 2.0.10 has been renamed as Maven 2.1.0 and the previous Maven 2.1 has been renamed as Maven 3.0. Maven 2.1.0 is going to be released real soon. Here's the latest staged binary: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1/org/apache/ma… It would be good if we could use this and verify it all works fine for us. I'm installing it now on my laptop. Thanks -Vincent

17 years

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r12766 - in sandbox/xwiki-clients/FoXWiki: . content content/images defaults defaults/preferences locale/en-UK

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-09-18 09:20:07 +0200 (Thu, 18 Sep 2008) > New Revision: 12766 > > Added: > sandbox/xwiki-clients/FoXWiki/content/browser.js > sandbox/xwiki-clients/FoXWiki/content/browser.xul > sandbox/xwiki-clients/FoXWiki/content/images/ > sandbox/xwiki-clients/FoXWiki/content/images/foxwiki.png > sandbox/xwiki-clients/FoXWiki/content/images/general.png > sandbox/xwiki-clients/FoXWiki/content/images/webdav.png > sandbox/xwiki-clients/FoXWiki/content/preferences.xul > sandbox/xwiki-clients/FoXWiki/defaults/ > sandbox/xwiki-clients/FoXWiki/defaults/preferences/ > sandbox/xwiki-clients/FoXWiki/defaults/preferences/foxwiki.js > sandbox/xwiki-clients/FoXWiki/locale/en-UK/foxwiki.dtd > Removed: > sandbox/xwiki-clients/FoXWiki/content/overlay.js > sandbox/xwiki-clients/FoXWiki/content/overlay.xul > sandbox/xwiki-clients/FoXWiki/locale/en-UK/overlay.dtd > Modified: > sandbox/xwiki-clients/FoXWiki/build.sh > sandbox/xwiki-clients/FoXWiki/chrome.manifest > sandbox/xwiki-clients/FoXWiki/install.rdf > Log: > Added a preference page for foxwiki, renamed some files to make sense. > > > > Added: sandbox/xwiki-clients/FoXWiki/content/browser.js > =================================================================== > --- sandbox/xwiki-clients/FoXWiki/content/browser.js (rev 0) > +++ sandbox/xwiki-clients/FoXWiki/content/browser.js 2008-09-18 07:20:07 UTC (rev 12766) > Deleted: sandbox/xwiki-clients/FoXWiki/content/overlay.js > =================================================================== > --- sandbox/xwiki-clients/FoXWiki/content/overlay.js 2008-09-17 22:39:57 UTC (rev 12765) > +++ sandbox/xwiki-clients/FoXWiki/content/overlay.js 2008-09-18 07:20:07 UTC (rev 12766) You should use svn mv old_name new_name when renaming files, so that svn tools can link the two filenames, for example so that fisheye can correctly display the full file history. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years

3
3
0 0

[xwiki-devs] [ANN] XWiki Workspaces 1.1 RC 2 released

by Jerome Velociter

The XWiki development team is pleased to announce the release of XWiki Workspaces 1.1 Release Candidate 2, Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the second and hopefully last Release Candidate for the 1.1 cycle, and is mainly a bug fix release. You can find out more reading the full releases notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces11RC2, including installation and upgrade instructions. Thanks, -The XWiki dev team

17 years

1
0
0 0

[xwiki-devs] Getting the domain name of a virtual wiki through velocity

by mh

Hi devs, I have an XEM set up with with several virtual wikis on it. I'm trying to get the name of the virtual xwiki though velocity. For example, say that I have a XEM instance running two virtual wikis: 1) wikiA.domain.org 2) wikiB.domain.org on a XEM called xem.domain.org Im looking for the velocity code that will return the name (domain name) when embedded in a page of one of the virtual wikis. Something like: $xwiki.getServerName() if i put that in a page in wikiA, it should return "wikiA.domain.org". Likewise, if i put the same code in wikiB, it should return "wikiB.domain.org" I looked at the velocity code for xem.doman.org/xwiki/bin/view/WikiManager/ because it lists the actual domain names under the "Domain Names" column. But it just gets a list of any virtual wikis available and lists them out. This page uses the xwikimanager plugin. I looked at the api and didn't see a way to directly get the domain name of the wiki in question. Could someone please point me in the right direction? Thanks in advanced and have a great day! -mh

17 years

1
0
0 0

[xwiki-devs] XE 1.6RC1 release planning

by Vincent Massol

Hi, The date for releasing XE 1.6RC1 is today. However we are late on several points: new WYSIWYG, new rendering, maybe others. So we need to all together list what remains and when it can be finished. The deadline we had planned for the final 1.6 release was 22nd of September. We should still strive to release it at that date as much as possible. What I'm asking all committers here is to list the pending issues they have and when the can have it finished. Please list only critical things that have to go in the 1.6 release. I'm starting on the new rendering. What I have left: * Fix the nested list problem in wikimodel: http://code.google.com/p/wikimodel/issues/detail?id=22 * Document the new syntax * Fix problem of < and > in HTML Cleaner, see http://jira.xwiki.org/jira/browse/XWIKI-2669 * Change the syntax for italics: // instead of ~~ * Change the syntax for headers: == instead of 1[.1]* I should be able to have this done by Wednesday the 17th. What about others? Thanks -Vincent

17 years

3
6
0 0

[xwiki-devs] [VOTE] Release XWS 1.1 RC 2

by Jerome Velociter

Dear devs, I would like to release XWiki Workspaces 1.1 Release Candidate 2 beginning of next week, ideally thuesday, with the following releases notes : http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10302&… My +1 for it, Jerome.

17 years

6
6
0 0

[xwiki-devs] [VOTE] New syntax for headers - Take 2

by Vincent Massol

Ok since our last vote wasn't successful I'm restarting it (since we've had lots of reasons given the opinion of each of us may have changed). Please note that we also need to be quick since 1.6 release is approaching fast and this is going to take some time to implement. Proposal: * Replace 1[.1]* syntax with =[=]* syntax * Force closing = with any number of equal signs (including none). ** Rationale 1: this is what Creole suggest. See http://www.wikicreole.org/wiki/Creole1.0#section-Creole1.0-Headings ** Rationale 2: makes it easier for lazy people * Allow wiki syntax in headers (we need that to auto generate them using velocity syntax for example). Creole considers this optional so we're good. * White space allowed before the left = * Any characters after the closing = signs are considered to be part of the paragraph after the header. Note: I don't know what Creole suggests for this. Note also that I'll have to check with the wiki model parser what is easier to do. The other alternative is to simply ignore chars there. * Default (in wysiwyg editor for ex) is to generate closed headers (with matching = signs on the right) Here's my +1 to all. Thanks -Vincent

17 years

4
4
0 0

[xwiki-devs] XWiki Query Language & JCRStore status

by Artem Melentyev

Hi, devs. I committed first version of XWQL (or XQL) language to our sandbox (xwiki-query/xwql) for review. I worked ~2 last weeks for it. install info is in xwiki-query/README. Currently it works according my proposal[1], but it is quite easy to modify. It is not perfect, but it works and will be improved. You can test it via QueryManager. (for example in velocity: $xwiki.xWiki.store.queryManager.createQuery("select doc.fullName from Document as doc, doc.XWiki.ArticleClass as a where a.title like '%Launch'", "xwql").execute() ) plan for xwql (for fix in next week): * use xwiki-bridge instead of xwiki-core in xwql. (some methods in bridge are needed) * create query velocity service accessible like $services.query.xwql('...') (according Vincent's velocity services proposal [2]) * move xwiki-query maven module from sandbox to platform/components/ * move QueryManager component from xwiki-core to xwiki-query I would like to integrate xwql for hql in 1.6M2 (8 Sept) and improve it in RC if needed. JCRStore: old JCRStore with some modifications is partly working (save/load document is ok) on recent Jackrabbit, but missing some new stores and need redesign. plan: * create xwiki-store/jcr maven module in platform/components (at sandbox first) it have to depend on xwiki-core (but not reverse). Is it a problem for platform/components? * split JCRStore into components. (RepositoryFacory, SessionFactory, SessionPool, Stores, DAOs) * jcrstore will contains DefaultStores which will contain only business logic on data model, and use DAOs components for store/load data. DefaultStores will be reused in future HibernateStore to remove duplicating of code. * get rid of patched graffito-jcr-mapping (~ORM for JCR). it is old and unsupported. candidates: jcrom [3], jackrabbit-ocm (former graffito), simple hand-made annotation based mapping. I'll look at jcrom first. I already have some code and plan to work on it in sandbox, after finish with xwql-hql. I plan to create working version of JCRStore at the end of September. xwql on JCRStore will work only on JCRv2 implementation. [1] http://xwiki.markmail.org/message/uar73uglivj6fbbn [2] http://markmail.org/message/jwcjomrck3yo2kjq [3] http://code.google.com/p/jcrom/ -- Artem Melentyev

17 years

3
9
0 0

[xwiki-devs] [Proposal] Reorganize XWiki Core JIRA components reflecting core/web modules

by Jerome Velociter

Hello everybody, Discussing we Vincent we agreed that currently XWiki Core components on JIRA are very scattered and do not make very much sense. We propose to reorganize the project and have one component per module in platform core and web, which would be : * action * cache * component * containers * context * xwiki-core * observation * patchservice * plexus * rendering * url * velocity * xml * xmlrpc * web-standard * web-exo * web-gwt * web-wysiwyg +1 for that. A question now I have is : since it will be quite a big refactoring, do we move all issues ? or only open issues ? Thanks, Jerome.

17 years

5
10
0 0

[xwiki-devs] Integration of the WebDAV plugin in the UI

by Asiri Rathnayake

Hi Devs, >From today onwards I'll be working on integrating the xwiki-webdav plugin in the xwiki ui. And in the process i will resurrect the foxwiki firefox extension as well. By integrating xwiki-webdav on the xwiki ui, we mean to provide the users the ability to open / edit / save various types of attachments with their favourite editor. For an example, we'll provide a "open with word" link next to a ".doc" attachment in the attachments section of the UI. When the user clicks on this link it will fire up word and let the user edit the content and save it back as he/she wishes. Currently this functionality is available natively on IE (phew) and there isn't much to be done on that. But for this to work on firefox we're going to have to resurrect the foxwiki extension. So the tentative workplan would be as bellow: * Make foxwiki work with firefox 3 - (Estimated : 2 days - Already started working on this) * Add the functionality to load the corresponding application (to edit the attachment) via foxwiki - (Estimated : 3 days ?) * Provide a common javascript API (javascript.vm ?) that can be used to launch an application from pages - (Estimated : ?) * Modify attachments.vm to automatically include the links for editing attachments. These are the goals I currently have in my mind and i'm still bit shaky about some topics myself. If any of you have sugesstions / comments / thoughts please let me know. Thanks. - Asiri

17 years

4
9
0 0

[xwiki-devs] [Proposal] XWiki 2.0 syntax : going further on the syntax overhaul

by Jean-Vincent Drean

Hi XWikiers, Those last months we've discussed a lot about precise elements of the new XWiki 2.0 syntax : - usage of 2 chars for **bold** and [[links]] - {{macro/}} syntax - Linebreaks on carriage returns - Linking to attachments/Insert link to image - |table| syntax - styling syntax - emoticons So far the idea was to keep the xwiki/2.0 syntax as close as possible from xwiki/1.0. IMHO we've reached a point where xwiki/2.0 is so different from xwiki/1.0 that it could be the occasion to go further and replace our few radeox leftovers by their widespread equivalent. That's the first thing I'd like to discuss, do we all agree to make other substantial modifications to xwiki/2.0 ? Here's my +1. Being completely in line with Creole [1] or WikiSyntaxCommon [2] is not an option since we've already made some incompatible choices (like linebreaks on carriage returns) and it would imply a big amount of work now that the new rendering is approaching a stable state. That's the reason why this proposal is about 2 basic (and important) wiki syntax elements, those 2 modifications would make xwiki syntax familiar to wikiPowerUsers. 1) Usage of // instead of ~~ for italic Creole rationale : A slash (/) looks like slanted italics, so it is intuitive and thus easier to remember. See http://www.wikicreole.org/wiki/BoldAndItalicsReasoning Note : on all the keyboard mappings I know slashes are more easily reachable than ~. Here's my +1. 2) Usage of equal signs instead of 1./1.1/etc for Headings Creole rationale : Using equal signs (=) is the most popular wiki header markup. Since there are more equal signs for smaller headers, subheaders will become more indented making it easier to get a visual overview from the markup alone. See http://www.wikicreole.org/wiki/HeadingsReasoning Note : We've experienced problems in the past with the 1/1.1 syntax (bad document section computation, problems with table cells starting with 1, etc) but those problems are addressed in the new rendering. Anyway I think users are more likely to unintentionaly start a line with a 1 than a = (like in "1 is more than 2" in the middle of a paragraph). What I personnaly like with this syntax is that it makes sections very visible when editing a page in wiki mode. About unclosed titles : === Also level 3 === Also level 3 = === Also level 3 == a) Don't interpret them +0. b) Interpret them but make closed title our default (generated by wysiwyg) +1, as I wrote above I think that having clear sections in a page helps to navigate in edit mode. c) Interpret them and make it our default -0. [1] : http://www.wikicreole.org/wiki/Creole1.0 [2] : http://code.google.com/p/wikimodel/wiki/WikiSyntaxCommon Thanks, JV.

17 years

6
5
0 0

[xwiki-devs] external javascript as XWiki docs?

by Pascal Voitot

Hello, I would like to write a document containing some javascript functions... For example: in "MySpace.MyJSDoc": {pre} print('This is my javascript'); {/pre} Then, instead of using Velocity #includeMacros, I would like to use it with the classical external javascript link "<script src=""/> and take advantage of usual JS caching features of web browsers in order not to load this JS everytime... Thus, keeping a way of editing my javascript online... In the middle of a page, I would like to put something like: ... Some wiki content to render... <script type="text/javascript" src="$xwiki.getURL('MySpace.MyJSDoc')?xpage=plain"/> ... Some wiki content to render... (I use "xpage=plain" to retrieve only the JS content...) But it appears that web browsers don't wait until the whole page is received and make a nested call to the XWiki engine immediately after reading the <script src=""> and the receiving of the remaining part of the page is simply stopped at this stage (XWiki seems to trash the remaining part of the page). So my questions: is my idea totally stupid? if not, do you have an idea to make it possible or at least, at first sight, do you see what happens exactly to give me some clues before going deeper with debuggers? best regards Pascal

17 years

2
2
0 0

[xwiki-devs] building under eclipse 3.4 with last m2eclipse

by Pascal Voitot

Hello, I've tried building platform and XE from trunk under Eclipse 3.4(Ganymede) with last M2Eclipse (Maven embedded 2.1.0 with m2eclipse 0.9.5) which brings lots of new features but also some new problems... I've checked out full platform trunk and tried to use the "nested modules management" of m2eclipse in order to have something clean... so check out using Subclipse and then activated Maven dependency management, Workspace resolution and Nested Modules... Due to some new features of both maven and m2eclipse and due to new nested modules, there are some problems building everything from scratch... Here are my short remarks (I'm only maven and eclipse user so this is what I can seem with an external point of view): - the famous out-of-memory still exists when building aspects so still needs to creates a specific Run target with the now famous "-XmxLOTS_OF_MEMORY" - now in Maven, compiled classes are separated: main classes goes in target/classes and test classes goes in target/test-classes (which is not so bad) - In XWiki platform, we have now up to 3 levels of nested modules and apparently the maven inheritance is not well managed by m2eclipse. By default, maven tests are not run using parent compiled classes and I had to explicitely trigger "resolve Workspace artifact" in my specific Maven Run target not to have "no class def found exception for ...XWikiContext" when running maven:test. - the "resolve Workspace artifact" is sometimes not good: for web/standard, it tries to copy the file xwiki-core/target/classes but as it is a directory, it fails to copy it :)... - Moreover, m2eclipse seems to run maven tests using target/classes from parent or locally dependent maven modules but not target/test-classes. And in XWiki, xwiki-rendering/xwiki-rendering-tests, for example, uses classes from xwiki-core tests classes. I haven't found a clever solution for this. - I can also see some code errors in Eclipse in web/gwt because Eclipse trie to resolve some deprecated functions from xwiki-core trunk... not a problem when compiling with maven One other question about something I remark: when compiling, I see this tens of times: url = http://maven.xwiki.org/externals Downloading: http://maven.xwiki.org/externals/groovy/groovy-all-1.0-jsr/06/groovy-all-1.… url = http://maven.xwiki.org/releases Downloading: http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0… url = http://repo1.maven.org/maven2 Downloading: http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-j… Apparently, it doesn't see it has already downloaded it... Do you know why? So finally, compiling module per module triggering some options is OK but compiling from scratch implies skipping tests... Pascal

17 years

4
6
0 0

Re: [xwiki-devs] [Proposal] XWiki 2.0 syntax : going further on the syntax overhaul (SUMMARY)

by Jean-Vincent Drean

Summary : 1) Usage of // instead of ~~ for italic Three +1, two 0, no -1. 2) Usage of equal signs instead of 1./1.1/etc for Headings Three +1, two 0, no -1 for this change. Three +1, two 0, no -1 for choice a) : consider a line as a heading only if there is the same number of equal signs at the beginning and at the end of the line. Thanks, JV. On Fri, Sep 12, 2008 at 5:29 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote: > Hi XWikiers, > > Those last months we've discussed a lot about precise elements of the > new XWiki 2.0 syntax : > - usage of 2 chars for **bold** and [[links]] > - {{macro/}} syntax > - Linebreaks on carriage returns > - Linking to attachments/Insert link to image > - |table| syntax > - styling syntax > - emoticons > > So far the idea was to keep the xwiki/2.0 syntax as close as possible > from xwiki/1.0. > IMHO we've reached a point where xwiki/2.0 is so different from > xwiki/1.0 that it could be the occasion to go further and replace our > few radeox leftovers by their widespread equivalent. > That's the first thing I'd like to discuss, do we all agree to make > other substantial modifications to xwiki/2.0 ? > > Here's my +1. > > Being completely in line with Creole [1] or WikiSyntaxCommon [2] is > not an option since we've already made some incompatible choices (like > linebreaks on carriage returns) and it would imply a big amount of > work now that the new rendering is approaching a stable state. That's > the reason why this proposal is about 2 basic (and important) wiki > syntax elements, those 2 modifications would make xwiki syntax > familiar to wikiPowerUsers. > > 1) Usage of // instead of ~~ for italic > > Creole rationale : A slash (/) looks like slanted italics, so it is > intuitive and thus easier to remember. > See http://www.wikicreole.org/wiki/BoldAndItalicsReasoning > Note : on all the keyboard mappings I know slashes are more easily > reachable than ~. > > Here's my +1. > > 2) Usage of equal signs instead of 1./1.1/etc for Headings > > Creole rationale : Using equal signs (=) is the most popular wiki > header markup. Since there are more equal signs for smaller headers, > subheaders will become more indented making it easier to get a visual > overview from the markup alone. > See http://www.wikicreole.org/wiki/HeadingsReasoning > > Note : We've experienced problems in the past with the 1/1.1 syntax > (bad document section computation, problems with table cells starting > with 1, etc) but those problems are addressed in the new rendering. > Anyway I think users are more likely to unintentionaly start a line > with a 1 than a = (like in "1 is more than 2" in the middle of a > paragraph). > What I personnaly like with this syntax is that it makes sections very > visible when editing a page in wiki mode. > > About unclosed titles : > > === Also level 3 > === Also level 3 = > === Also level 3 == > > a) Don't interpret them > > +0. > > b) Interpret them but make closed title our default (generated by wysiwyg) > > +1, as I wrote above I think that having clear sections in a page > helps to navigate in edit mode. > > c) Interpret them and make it our default > > -0. > > [1] : http://www.wikicreole.org/wiki/Creole1.0 > [2] : http://code.google.com/p/wikimodel/wiki/WikiSyntaxCommon > > Thanks, > JV. > -- Jean-Vincent Drean

17 years

3
3
0 0

[xwiki-devs] [Rendering] Ambiguity in link format for URIs

by Vincent Massol

Hi, I have a problem in the new rendering. We cannot differentiate between a URI and a multiwiki link. For example: [[prefix:value]] This can be considered as a URI or as a space/page (another ambiguity) pointing to the "prefix" subwiki... Right now what I've done is to only support mailto: URI and URI with the format scheme://value. Any other prefix:value is considered a multiwiki link. Ideally we should have a better format so that there's no ambiguity. WDYT? (I don't have a good proposal right now). Thanks -Vincent

17 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs