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
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.
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
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
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
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
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
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
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
>
>
>
>
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