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
Hi,
I'd like to propose Fabio as a core committer. Fabio has been mostly
participating in the rewrite of the XMLRPC support and I think it's
important that he has access to maintain and improve it. Fabio's
patches are very good too.
In addition I believe Fabio is professional enough to not commit
things he's not sure about if he's modifying other parts of the core
and ask for core review instead.
Last, if this make Fabio contributes to other parts in the core, then
that's great for the project!
Here's my +1
Thanks
-Vincent
Hi fabio
Regarding the xwiki syntax I have some questions. Up to now its
straightforward to implement the highlighting for syntaxes like
*bold*.
*bold* can be easily identified by a "MultiLineRule" as a single partition.
But it is possible for someone to write a *bold~~bold &italics~~bold*.Right ?.
So this can go on and on.How should I tackle this problem.
I think *bold~~bold &italics~~bold* should generate 3 partitions
because partitions are non overlapping.
*bold
~~bold &italics~~
bold*
Is this right ?.
Should I look into this problem later and implement the sample plugin
for simple syntaxes like *bild*,~~italics~~ or not ? .
cheers
-- Malaka Ekanayake
On Jun 12, 2008, at 1:53 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2008-06-12 01:53:06 +0200 (Thu, 12 Jun 2008)
> New Revision: 10270
>
> Modified:
> xwiki-products/xwiki-enterprise/trunk/distribution-test/selenium-
> tests/src/test/it/com/xpn/xwiki/it/selenium/WikiEditorTest.java
> Log:
> [misc] Added a comment
>
>
> Modified: xwiki-products/xwiki-enterprise/trunk/distribution-test/
> selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/
> WikiEditorTest.java
> ===================================================================
> --- xwiki-products/xwiki-enterprise/trunk/distribution-test/selenium-
> tests/src/test/it/com/xpn/xwiki/it/selenium/WikiEditorTest.java
> 2008-06-11 23:51:17 UTC (rev 10269)
> +++ xwiki-products/xwiki-enterprise/trunk/distribution-test/selenium-
> tests/src/test/it/com/xpn/xwiki/it/selenium/WikiEditorTest.java
> 2008-06-11 23:53:06 UTC (rev 10270)
> @@ -159,6 +159,9 @@
> // TODO: We need to find out how to make a text selection in
> Selenium
> }
>
> + /**
> + * See XWIKI-1007
> + */
Personally I don't like referring to JIRA issues like this because:
1) the reader has to navigate to the issue to understand what it is
2) there's the risk that in the future we'll use a tool other than jira
So I'd prefer you simply say: "Verify that a document's content can be
empty" or if you prefer " Verify that a document's content can be
empty (see XWIKI-2007).". My preference for the former.
BTW naming the test: testEmptyDocumentContentIsAllowed would be even
better :)
Thanks
-Vincent
> public void testEmptyContent()
> {
> open("/xwiki/bin/edit/Test/EmptyWikiContent?editor=wiki");
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications