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