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

[xwiki-devs] [VOTE] Release XWS 1.1 RC 2
by Jerome Velociter 17 Sep '08

17 Sep '08

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.

6 6

[xwiki-devs] [VOTE] New syntax for headers - Take 2
by Vincent Massol 17 Sep '08

17 Sep '08

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

4 4

[xwiki-devs] XWiki Query Language & JCRStore status
by Artem Melentyev 16 Sep '08

16 Sep '08

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

3 9

[xwiki-devs] [Proposal] Reorganize XWiki Core JIRA components reflecting core/web modules
by Jerome Velociter 16 Sep '08

16 Sep '08

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.

5 10

[xwiki-devs] Integration of the WebDAV plugin in the UI
by Asiri Rathnayake 16 Sep '08

16 Sep '08

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

4 9

[xwiki-devs] [Proposal] XWiki 2.0 syntax : going further on the syntax overhaul
by Jean-Vincent Drean 16 Sep '08

16 Sep '08

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.

6 5

[xwiki-devs] external javascript as XWiki docs?
by Pascal Voitot 15 Sep '08

15 Sep '08

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

2 2

[xwiki-devs] building under eclipse 3.4 with last m2eclipse
by Pascal Voitot 15 Sep '08

15 Sep '08

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

4 6

Re: [xwiki-devs] [Proposal] XWiki 2.0 syntax : going further on the syntax overhaul (SUMMARY)
by Jean-Vincent Drean 15 Sep '08

15 Sep '08

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

3 3

[xwiki-devs] [Rendering] Ambiguity in link format for URIs
by Vincent Massol 15 Sep '08

15 Sep '08

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

2 1