Hi devs,
Caty suggested a while ago to allow the users to set custom logos in the
color theme. At first I thought this was not OK, since normally the logo
should be the same regardless of the site colors, but now I realize it's
a pretty good idea, because it ensures more flexibility, and, more
importantly, it allows to workaround transparency issues that appear in
some browsers (yes, I'm talking about IE6) by setting logos with the
same background color as the header.
The necessary changes would be:
- in "ColorThemes.ColorThemeClass" add a property called 'logo' whose
values are names of files attaches to the ColorTheme document
- in "global.vm", when searching for the wiki logo, start by looking in
the current ColorTheme, and, if not found, continue as before.
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
We are not ready to release the 2.2 final version so I'm proposing to
release a 2.2 RC 2 today and the final version on next Monday.
Here is my +1.
WDYT ?
--
Thomas Mortagne
Hi devs,
Currently when the reference does not contains any wiki name it's
resolved using the wiki of the current document.
Problem is that we generally use context wiki as the current wiki and
references used to be resolved that way before the refactoring using
official Resolver component.
In many places we set the wiki we want to work on before doing a bunch
of tasks: loading documents, executing queries etc... the problem is
that when Current*ReferenceResolver is used you have to create some
empty document and put it in the context just to set the wiki you want
to work on.
So i propose to change the behavior of all the
Current*ReferenceResolver to get context wiki as default wiki name.
Here is my +1
--
Thomas Mortagne
Hi,
I think viewheader.vm is not used anymore. I couldn't find any reference of it in other vm nor in skins.
However it's still referenced from XWiki.java, in getSkinClass() (and from ApplicationResources*.properties files):
needsUpdate |= bclass.addTemplateField("viewheader.vm", "View Header");
But I think this field is now not only useless but even misleading since filling it will have no effect AFAIK.
Could someone confirm this? Does it mean people with custom skin will find their skin not working anymore?
Anyone knows when viewheader.vm was stopped to be used because AFAICS this will break all existing custom skins?
What new properties should we add t o the XWikiSkins class?
Thanks
-Vincent
Hi Caleb,
This commit has broken a functional test, please see:
http://bit.ly/aNzmAF
Thanks
-Vincent
On Tue, Feb 9, 2010 at 6:49 AM, cjdelisle
<platform-notifications(a)xwiki.org> wrote:
> Author: cjdelisle
> Date: 2010-02-09 06:49:32 +0100 (Tue, 09 Feb 2010)
> New Revision: 26828
>
> Modified:
> Â platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/Registration.xml
> Log:
> XAADMINISTRATION-103: Make registration page support lightbox so administrator can use it to add users in admin users sheet. - Modified registration page to be compatable with lightbox, also moved form tags and submit button outside of generateHtml macro.
>
> Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/Registration.xml
> ===================================================================
> --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/Registration.xml  2010-02-09 05:46:48 UTC (rev 26827)
> +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/Registration.xml  2010-02-09 05:49:32 UTC (rev 26828)
> @@ -74,6 +74,11 @@
> Â #set($loginPage = 'XWiki.XWikiLogin')
> Â #set($loginAction = 'loginsubmit')
> Â ##
> +## If this is true, then assume the registration page is being viewed inside of a lightbox
> +#if($request.get('xpage'))
> + Â #set($assumeLightbox = true)
> +#end
> +##
> Â ## Use javascript based live validation see: http://www.livevalidation.com
> Â ## Set false to stop using LiveValidation
> Â #set($useLiveValidation = true)
> @@ -457,16 +462,68 @@
> Â ## Then we display the registration form.
> Â #if(!$registrationDone)
> Â $welcomeMessage
> - Â {{html clean=false}}
> - Â Â ## I do not want to put this inside of a paragraph block so I end the block here and
> - Â Â ## start it at the end.
> - Â Â </p>
> + Â {{html clean=false wiki=false}}
> + Â Â <div>
> + Â Â <form id="register" action="" method="post">
> + Â Â <div>
> Â Â #generateHtml($fields, $fieldMandatoryStar, $failureMessageParams)
> + Â Â <span class="buttonwrapper">
> + Â Â #if($assumeLightbox)
> + Â Â Â ## LightBox detected...
> + Â Â Â <script type="text/javascript">
> + Â Â Â Â ## Make the X button not reload the page. (overriding LbClose)
> + Â Â Â Â window.lb.lbClose = function() {
> + Â Â Â Â Â this.lbHide();
> + Â Â Â Â Â this.lbClearData();
> + Â Â Â Â Â ##return false;
> + Â Â Â Â }
> + Â Â Â Â ## Post the form entry to the page and load the result. (we override lbSaveForm)
> + Â Â Â Â window.lb.lbSaveForm = function() {
> + Â Â Â Â Â var formParams = Form.serialize(this.form);
> + Â Â Â Â Â Form.disable(this.form);
> + Â Â Â Â Â var ajaxRequest = new Ajax.Request(this.saveUrl, {
> + Â Â Â Â Â Â parameters: formParams,
> + Â Â Â Â Â Â asynchronous: false
> + Â Â Â Â Â });
> + Â Â Â Â Â window.lb.lbFormDataLoaded(ajaxRequest.transport);
> + Â Â Â Â }
> + Â Â Â </script>
> + Â Â Â ## It doesn't really matter where these are, the scripts will be relocated to the head.
> + Â Â Â <!-- com.xpn.xwiki.plugin.skinx.CssSkinFileExtensionPlugin -->
> + Â Â Â <!-- com.xpn.xwiki.plugin.skinx.JsSkinFileExtensionPlugin -->
> + Â Â Â ##
> + Â Â Â <input class="button" type="submit" value="$msg.get('save')" onclick="window.lb.lbSaveForm();"/>
> + Â Â Â </span>#* End ButtonWrapper then start another...*#<span class="buttonwrapper">
> + Â Â Â <input class="button" type="submit" value="$msg.get("cancel")" onclick="Form.disable(window.lb.form); window.lb.lbClose();"/>
> + Â Â #else
> + Â Â Â ## Not using the LightBox
> + Â Â Â <input type="submit" value="$msg.get('core.register.submit')" class="button"/>
> + Â Â #end
> + Â Â </span>## ButtonWrapper
> + Â Â </div>
> + Â Â </form>
> Â Â #if($useLiveValidation)
> Â Â Â #generateJavascript($fields)
> Â Â #end
> - Â Â <p>
> + Â Â </div>
> Â {{/html}}
> +## If the registration is done (successful) and we detect the Lightbox simply send the user back to the original page.
> +#elseif($assumeLightbox)
> + Â {{html clean=false wiki=false}}
> + Â Â <script type="text/javascript">
> + Â Â Â Â var url = window.lb.redirectUrl;
> + Â Â Â Â window.lb.lbClose;
> + Â Â Â Â if (url != undefined) {
> + Â Â Â Â Â if(window.location.pathname + window.location.search == url) {
> + Â Â Â Â Â Â ## Under certain circumstances (bug) Opera will not load a page if the location is the same as the current page.
> + Â Â Â Â Â Â ## In these cases, location.reload() doesn't work either, the only solution (I could find) was to change the URL.
> + Â Â Â Â Â Â window.location.href = url + "&";
> + Â Â Â Â Â } else {
> + Â Â Â Â Â Â window.location.href = url;
> + Â Â Â Â Â }
> + Â Â Â Â }
> + Â Â </script>
> + Â {{/html}}
> Â #end
> Â ##
> Â ####### The Macros (nothing below this point is run directly) #########
> @@ -608,7 +665,8 @@
> Â Â Â Â Â </span>
> Â Â Â Â Â </div>
> Â Â Â Â </form>
> - Â Â Â Â #if($autoLogin)
> + Â Â Â Â ## We don't want autoLogin if we are administrators adding users...
> + Â Â Â Â #if($autoLogin && !$assumeLightbox)
> Â Â Â Â Â <script type='text/javascript'>
> Â Â Â Â Â Â document.observe('dom:loaded', function() {
> Â Â Â Â Â Â Â document.forms['loginForm'].submit();
> @@ -632,59 +690,54 @@
> Â Â ## Put the same values back into the fields.
> Â Â #getParams($fields)
> Â Â ##
> - Â Â <form id="register" action="" method="post">
> - Â Â <div><dl>
> - Â Â Â ##
> - Â Â Â #foreach($field in $fields)
> - Â Â Â Â #if($field.get('name'))
> - Â Â Â Â Â #set($fieldName = $field.get('name'))
> - Â Â Â Â Â #if($field.get('label'))
> - Â Â Â Â Â Â #set($label = $field.get('label'))
> - Â Â Â Â Â Â <dt><label for="$fieldName">$label</label>
> - Â Â Â Â Â Â #if($field.get('validate').get('mandatory'))
> - Â Â Â Â Â Â Â <span
> - Â Â Â Â Â Â Â #foreach($entry in $fieldMandatoryStar.entrySet())
> - Â Â Â Â Â Â Â Â $entry.getKey()="$entry.getValue()"
> - Â Â Â Â Â Â Â #end
> - Â Â Â Â Â Â Â >*</span>
> + Â Â <dl>
> + Â Â #foreach($field in $fields)
> + Â Â Â #if($field.get('name'))
> + Â Â Â Â #set($fieldName = $field.get('name'))
> + Â Â Â Â #if($field.get('label'))
> + Â Â Â Â Â #set($label = $field.get('label'))
> + Â Â Â Â Â <dt><label for="$fieldName">$label</label>
> + Â Â Â Â Â #if($field.get('validate').get('mandatory'))
> + Â Â Â Â Â Â <span
> + Â Â Â Â Â Â #foreach($entry in $fieldMandatoryStar.entrySet())
> + Â Â Â Â Â Â Â $entry.getKey()="$entry.getValue()"
> Â Â Â Â Â Â #end
> - Â Â Â Â Â Â </dt>
> + Â Â Â Â Â Â >*</span>
> Â Â Â Â Â #end
> - Â Â Â Â Â ## If no tag then default tag is <input>
> - Â Â Â Â Â #if($field.get('tag'))
> - Â Â Â Â Â Â #set($tag = $field.get('tag'))
> - Â Â Â Â Â #else
> - Â Â Â Â Â Â #set($tag = 'input')
> + Â Â Â Â Â </dt>
> + Â Â Â Â #end
> + Â Â Â Â ## If no tag then default tag is <input>
> + Â Â Â Â #if($field.get('tag'))
> + Â Â Â Â Â #set($tag = $field.get('tag'))
> + Â Â Â Â #else
> + Â Â Â Â Â #set($tag = 'input')
> + Â Â Â Â #end
> + Â Â Â Â <dd><$tag id="$fieldName"
> + Â Â Â Â #set($params = $field.get('params'))
> + Â Â Â Â ## If no name parameter is spacified, then we use the field name
> + Â Â Â Â #if(!$params.get('name'))
> + Â Â Â Â Â #set($discard = $params.put('name', $fieldName))
> + Â Â Â Â #end
> + Â Â Â Â #foreach($entry in $params.entrySet())
> + Â Â Â Â Â ## If a parameter is specified as '' then we don't include it.
> + Â Â Â Â Â #if($entry.getValue() != '')
> + Â Â Â Â Â Â $entry.getKey()="$escapetool.html($entry.getValue())"
> Â Â Â Â Â #end
> - Â Â Â Â Â <dd><$tag id="$fieldName"
> - Â Â Â Â Â #set($params = $field.get('params'))
> - Â Â Â Â Â ## If no name parameter is spacified, then we use the field name
> - Â Â Â Â Â #if(!$params.get('name'))
> - Â Â Â Â Â Â #set($discard = $params.put('name', $fieldName))
> + Â Â Â Â #end
> + Â Â Â Â ></$tag>
> + Â Â Â Â #if($field.get('error'))
> + Â Â Â Â Â <span
> + Â Â Â Â Â #foreach($entry in $failureMessageParams.entrySet())
> + Â Â Â Â Â Â $entry.getKey()="$entry.getValue()"
> Â Â Â Â Â #end
> - Â Â Â Â Â #foreach($entry in $params.entrySet())
> - Â Â Â Â Â Â ## If a parameter is specified as '' then we don't include it.
> - Â Â Â Â Â Â #if($entry.getValue() != '')
> - Â Â Â Â Â Â Â $entry.getKey()="$escapetool.html($entry.getValue())"
> - Â Â Â Â Â Â #end
> - Â Â Â Â Â #end
> - Â Â Â Â Â ></$tag>
> - Â Â Â Â Â #if($field.get('error'))
> - Â Â Â Â Â Â <span
> - Â Â Â Â Â Â #foreach($entry in $failureMessageParams.entrySet())
> - Â Â Â Â Â Â Â $entry.getKey()="$entry.getValue()"
> - Â Â Â Â Â Â #end
> - Â Â Â Â Â Â >$field.get('error')</span>
> - Â Â Â Â Â #end
> - Â Â Â Â Â </dd>
> - Â Â Â Â #else
> - Â Â Â Â Â ERROR: Field with no name.
> - Â Â Â Â #end##if fieldName exists
> - Â Â Â #end
> - Â Â Â </dl>
> - Â Â <span class="buttonwrapper"><input type="submit" value="$msg.get('core.register.submit')" class="button"/></span>
> - Â Â </div>
> - Â </form>
> + Â Â Â Â Â >$field.get('error')</span>
> + Â Â Â Â #end
> + Â Â Â Â </dd>
> + Â Â Â #else
> + Â Â Â Â ERROR: Field with no name.
> + Â Â Â #end##if fieldName exists
> + Â Â #end
> + Â Â </dl>
> Â #end
> Â ##
> Â ## Remove newlines inside of tags because tags are generated by loops.
Hi devs,
While fixing WCAG issues I've discovered the Main.RecentMembers page.
It looks deprecated and AFAIK it's not linked from anywhere. In order
to keep the distrbution clean I'd like to remove it before 2.2 final.
Here's my +1.
Thanks,
JV.
Hi,
Just to let you know I've found an important problem in XEM, caused by the changes brought by the entity references.
The pb is in XWikiDocument's code for object manipulation. I've replaced the Map of String that was used to store objects with a Map of DocumentReference.
So when you have code like:
XWikiDocument doc = context.getWiki().getDocument("wiki:space.page", context);
BaseObject obj = doc.getObject("XWiki.SomeClass);
And if context.getDatabse() = "currentWiki" (with "currentWiki" != "wiki")
Then doc.getObject will check if there's an object of ref "currentWiki:XWiki.SomeClass" in doc, which won't be found since there might indeed be an object but of ref "wiki:XWiki.SomeClass"...
Basically we now allow objects and classes in a document to reference classes located in another wiki.
To fix this all calling code should be modified to use full references. However since this isn't going to happen fast enough for 2.2 final and since in any case it could break user's code I think we need to modify XWikiDocument so that all class/object methods ignore the wiki part of the references, thus assuming all classes/objects refer to classes/objects in the current wiki, as it was assumed before...
Let me know if you agree. I'll start looking at the code to see how much there is to do that in the meantime.
Thanks
-Vincent