June 2008 - xwiki-devs@xwiki.org

[xwiki-devs] Why /templates not in /WEB-INF?
by Lilianne E. Blaze 13 Jun '08

13 Jun '08

Hello, Is there any particular reason why /templates are not in /WEB-INF? I don't like the idea of having part of the source code accessible by everyone. Greetings, Lilianne E. Blaze

5 15

[xwiki-devs] Automatically migrating/adding wiki documents upon upgrade
by Jerome Velociter 13 Jun '08

13 Jun '08

Hello devs, I'm currently trying to find the best approach to automatically upgrade an XWS instance workspaces when upgrading the XWS version. By that, I mean adding new pages to existing workspaces for example. I see at least two possible approaches : * On display of the workspace, we check that the considered pages are present, and if not either we automatically create them, either we offer a big button to "upgrade" the workspace. (the test could be done in a skin template, so that any page would trigger the upgrade) * On plugin init, we search for all workspaces and upgrade the ones in need. And we could have a marker once the upgrade is done, not to execute the query at each init. WDYT ? Are there other approaches I'm missing ? Regards, Jerome.

3 5

[xwiki-devs] New WYSIWYG editor with or without dialogs?
by Marius Dumitru Florea 13 Jun '08

13 Jun '08

Hi devs, While working on the new GWT-based WYSIWYG editor, I find out that the default DialogBox from GWT moves very slow when dragged if it contains many HTML elements (like a table with 10 rows and 20 columns). In the current WYSIWYG editor dialog boxes are used for color picker, custom character, insert image / attachment / macro / table. Before I start porting these dialogs to GWT I'd like to ask you: Do you agree with using dialog boxes for these features? * if so, do you think it's ok to optimize the way they are moved by showing only their border while dragging (win95-like)? * if not, how can we replace them? Thanks, Marius

5 16

[xwiki-devs] [Rendering] XHTML parser
by Vincent Massol 13 Jun '08

13 Jun '08

Just to let you know (and especially Marius) that I've discovered that wikimodel has a XHTML parser already which seems to be doing quite a lot of things. I'll be trying it next week and integrate it into the new rendering module so that the new WYSIWYG module can use it. Thanks -Vincent

1 0

[xwiki-devs] It's voting time again: Help XWiki ! Vote for it's creator at a French radio contest !
by Ludovic Dubost 13 Jun '08

13 Jun '08

Hi XWiki users and developers ! It's voting time again.. You have helped me get through to the semi final a few month ago, and this week is the voting period for the semi-final. What's less fun is that this time we cannot not the current voting result in real time so we have to push as much as we can. You can vote here (in french too but that should not be too difficult ! Make sure you select the second person at the top !): http://www.radiobfm.com/bfm_academie/index.php This can give a nice additional boost to XWiki ! Thanks to all of you for you continuous support of XWiki and participation to the lists. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

3 6

Re: [xwiki-devs] [xwiki-notifications] r10278 - xwiki-platform/web/trunk/standard/src/main/webapp/templates
by Vincent Massol 12 Jun '08

12 Jun '08

On Jun 12, 2008, at 5:08 PM, Sergiu Dumitriu wrote: > vmassol (SVN) wrote: >> Author: vmassol >> Date: 2008-06-12 10:08:57 +0200 (Thu, 12 Jun 2008) >> New Revision: 10278 >> >> Modified: >> xwiki-platform/web/trunk/standard/src/main/webapp/templates/ >> login.vm >> Log: >> XWIKI-2458: Ensure that the username field has the input focus in >> the login form so that it's easier for users to quickly log in >> Idea submitted by Mihail Agafonovs >> >> >> Modified: xwiki-platform/web/trunk/standard/src/main/webapp/ >> templates/login.vm >> =================================================================== >> --- xwiki-platform/web/trunk/standard/src/main/webapp/templates/ >> login.vm 2008-06-12 03:17:43 UTC (rev 10277) >> +++ xwiki-platform/web/trunk/standard/src/main/webapp/templates/ >> login.vm 2008-06-12 08:08:57 UTC (rev 10278) >> @@ -42,5 +42,11 @@ >> #xwikimessageboxend() >> </form> >> </div> >> +## Ensure that the username field of the login form has the focus >> to make it easy for users to log in quickly >> +<script type="text/javascript"> >> +//<![CDATA[ >> + document.forms.loginForm.j_username.focus(); >> +//]]> >> +</script> >> #template("endpage.vm") >> #end > > I don't like it. This is intrusive Javascript. I'd rather: > - add a class attribute, class="autofocus" > - write a global SkinExtension that focuses the first element with > that class, if it exists > - and execute that method onload, with Event.observe(window, "load", > autofocus) Actually before doing this I checked other vm files and I saw this was a common practice... So common but not good I guess :) I'm not sure why we would use a skin extension for a template. This is not about extending a skin, it's about common templates to all skins. I'd like to understand how the full current template structure is impacted by the new Skin Extension and what's the vision. Also AFAIK SkinExtensions are in wiki pages. I don't think it's a good idea to have pages for template stuff since template stuff work without a database. The solution you highlight also sounds very slow for performances. > What's missing now: global skin extensions don't work yet. We could, > for the moment, pull it in. WDYM by "pull it in"? Thanks -Vincent

1 0

[xwiki-devs] Bug Fixing Day Results for 11 June 2008
by Vincent Massol 12 Jun '08

12 Jun '08

Hi everyone, Yesterday was our first bug fixing day (which we intend to have every wednesday). The following bugs were fixed: http://tinyurl.com/5wcvs8 - Vincent * XWIKI-2454 XWiki products don't stop correctly under Tomcat - Sergiu * XWIKI-1007 Removing all content in page has no effect & the content of a wiki page is not allowed to be completely empty * XWIKI-1434 Case Related Issue With Backlinks * XWIKI-1045 halign and align {image} parameters overlap * XWIKI-2199 Saving a document via the inline editor resets the Tags document's property * XWIKI-1284 Image disappears from WYSIWYG editor in documents with special characters in name - Thomas * XWIKI-2453 Wrong use of cache in LDAP authenticator * XWIKI-2264 LDAP authentication does not support "." in login names - Artem * XWIKI-2375 Group and user access rights problem with a name which includes space characters So that's a total of 9 bugs fixed. Well done everybody and thanks to all who participated. Let's hope that even more of you can participate next wednesday. Thanks -Vincent

1 0

[xwiki-devs] the return of class/object management
by Pascal Voitot 12 Jun '08

12 Jun '08

Hello guys, do you remember my work on classes and objects? I fear the answer is "no" :) Anyway, I have been working on some other critical projects so I haven't been able to work on that for some time. But, now I have restarted my study for my current needs. The idea was to provide a simple way to manage classes, to delete/restore class properties and to synchronize objects with these classes. As I was not really happy about the result of my previous work based on class versioning (I found it too much intrusive in XWiki code and complicated), I totally changed my approach into something much lighter. The idea is really simple: I propose to add the feature of enabling/disabling class properties. * If you disable a property, it is only "hidden" without being deleted so you can modify the structure of the class without losing anything. * Then the disabled properties are also "hidden" for the objects instantiating this class and the valued fields are also not lost. * If you add a new property to the class, all objects will inherit a new field with the default value. * If you enable a disabled property, all the objects owning the field re-find it and the objects not having the field now have it with the default value. * you could also delete a disabled field from an object for some optimization issues. I also propose to add the "remove property" feature which would be quite protected but which is useful: you simply delete the property from the class. * All objects having the "removed" field are no more synchronized with the class. * the removed field still exist in the object but is no more available to classical display functions which use "class properties" to find object fields. * the removed field can be deleted from the object to resynchronize the object to the class * if a new property with the same type and name is re-added to the class, the object re-finds its existing field. The way to do it is quite simple: just add a "enabled" field to the PropertyClass and manage it in the code. I have modified a bit XWiki-Core and some velocity scripts but it seems really light without any really new logic Are you interested in this? best regards Pascal

3 3

Re: [xwiki-devs] [GSOC]syntax highlighting probleam
by Vincent Massol 12 Jun '08

12 Jun '08

Hi Venkatesh, On Jun 12, 2008, at 10:40 AM, Venkatesh Nandakumar wrote: [snip] > 1. Syntax Highlighting, to a large extent, though there have been > problems, as pointed out by Malaka, *bold~~combined~~bold* doesn't > give > the required effect, and secondly, the complex use of '*' in the wiki > syntax makes it a bit difficult to differentiate between actual *bold* > usage versus listing uses, maybe we would have to create own custom > regex-based rules for it later. For other tags, its been simple and > straightforward. Do you really need to parse it yourself? We have a parser in charge of doing this so you don't have to care at all about these problems. That's unless the system you use for syntax highlighting uses regexs (in which case I think it should be changed). Thanks -Vincent > > 2. Content Proposal, type <the first character of syntax> and drop- > down > of possible syntaxes, when selected, moves cursor to correct > position of > entry of text. Key-combination also brings down the menu. Also valid > for > applying styles to selected text. > 3. As a minor addition, context information. ( though very partially) > 4. Indentation strategies (very partial implementation till now) > 5. minor - Hyperlink detection and linking within {quote} and a > hyperlinks > > > I've also divided the document into partitions,(as of now, > pre,code,table,<dl> and default) for possibility of different content > proposal/content assist/syntax highlighting. > > I have not integrated any of the code with the xeclipse plugin's code. > What I have created as of now, is just another eclipse-plug-in. > > > Venkatesh > > > >

2 2

[xwiki-devs] Code commit
by Fabio Mancinelli 12 Jun '08

12 Jun '08

Hi everybody. I have some code to commit for XWIKI-2432 and XWIKI-2428... There has been a previous vote for my committership but no official announcement of the results (unless I missed it). So I am just asking for the official ok before committing the code in trunk. Cheers, Fabio

2 1