Hi devs,
I would like to release 2.0.4 as soon as possible.
Among other things it contains:
- this time statistics are working, promise (except for
http://jira.xwiki.org/jira/browse/XWIKI-4590 but that's another story)
- several important users management related issue fixed mainly
visible in path based multiwiki mode
Here is my +1
--
Thomas Mortagne
Hi,
We have a few issues in the WCAG tests for our wiki edit mode
(results are in http://www.webrichtlijnen.nl/english/test/report/76745/182681/)
:
1) "Use friendly URL's, that are readable and recognisable.". I
believe this is caused by js present in javascript.vm which generate
URLs like:
var surl = "http://localhost:8080/xwiki/bin/cancel/Main/WebHome?ajax=1";
This is probably a pb with the WCAG test parser. However shouldn't we
move the script in a JS file (maybe in xwiki.js)?
If we don't move it then another rule that says that script element
but have a noscript element specified will be triggered too.
2) "When using client-side script in combination with a link: if the
link does not lead to anything, do not confront the visitor without
support for client-side script with a non-working link."
"Contains links which will not work if javascript is unavailable or
switched off."
Not sure what we should do with this one. Any idea?
3) "Use the th (table header) to describe a column or row in a table
with relational information."
The pb is in the Information Panel.
<table summary="List of included documents"
id="xwikiincludeddocuments"> <tbody> <tr><td><a href="/xwiki/bin/view/
Main/Dashboard">Main.Dashboard</a></td> <td class="xwikibuttonlink"><a
href="/xwiki/bin/edit/Main/Dashboard">Edit</a></td></tr> </tbody> </
table>
We need to decide if we consider it's valid or not. If the table is
not a data table then it could be valid, as mentioned here:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout
I have tried to find alternatives (like not using a table, adding
headers) but none looks good to me. Should we consider our code is ok?
Thanks
-Vincent
Hi devs,
We need to decide what to do with html macro content (or any other
RawBlock content) in plain text renderer.
For me the rule of plain text renderer should be to print anything we
are able to print which mean printing any pure text content and skip
styles for which obviously we don't have syntax. RawBlock content is
pure text so we should print it.
Note that first version of plain text renderer was printing html
content and it was lost when introducing RawBlock.
Here is my +1 for printing RawBlock content in plain text renderer.
WDYT ?
--
Thomas Mortagne
On Nov 19, 2009, at 3:53 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-11-19 15:53:25 +0100 (Thu, 19 Nov 2009)
> New Revision: 25217
>
> Modified:
> platform/web/trunk/standard/src/main/webapp/templates/rightsUI.vm
> Log:
> [cleanup] Apply codestyle
>
> Modified: platform/web/trunk/standard/src/main/webapp/templates/
> rightsUI.vm
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/templates/
> rightsUI.vm 2009-11-19 14:43:57 UTC (rev 25216)
> +++ platform/web/trunk/standard/src/main/webapp/templates/
> rightsUI.vm 2009-11-19 14:53:25 UTC (rev 25217)
> @@ -110,15 +110,15 @@
> </tr>
> <tr id="usersandgroupstable-filters">
> <td>$msg.get("rightsmanager.searchfilter") <input
> name="name" type="text" style="width:65%"/>
> - #if($context.database != "xwiki") #set($mainwk
> = false) #else #set($mainwk = true) #end
> - #if(!$mainwk) ## display the combobox only
> in a local wiki
> + #if(!$context.isMainWiki()) #set($mainwk =
> false) #else #set($mainwk = true) #end
> + #if(!$mainwk) ## display the combobox only in
> a local wiki
> <select name="wiki" style="margin-left:10px;">
This will create some extra spaces in the generated HTML. It would be
great if we could find a way to have nice indentation and nice
generated HTML output too.
I tried to imagine a good solution and couldn't so far (apart from
running the generated HTML to a pretty printer but this is going to
cause some overhead - Maybe it's minor enough to do it though). We
could also have our own pre-processor that would remove spaces at
beginning of velocity lines (as we're doing in the {{velocity}} macro)
WDYT?
Thanks
-Vincent
> <option value="local" selected="selected">
> $msg.get("rightsmanager.local")</option>
> <option value="global">
> $msg.get("rightsmanager.global")</option>
> <option value="both">
> $msg.get("rightsmanager.both")</option>
> </select>
> - #else<input type="hidden" name="wiki"
> value="local"/>#end
> - #set($colsp = $maxlevel + 1)
> + #else<input type="hidden" name="wiki"
> value="local"/>#end
> + #set($colsp = $maxlevel + 1)
> </td>
> <td colspan="$colsp"><input type="hidden"
> name="clsname" value="$clsname" /></td>
> </tr>
Hi,
Before we start doing a wide range of Macros, I would like to suggest
that unless a Macro is part of a bigger application we store it in the
Macros space.
Macros.GoogleCalendar
Macros.Map
WDYT ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi everyone,
If you like XWiki, please nominate it for one (or more) of the
following Crunchie award categories:
1) Best Enterprise StartUp: http://crunchies.techcrunch.com/vote/?NzpYV2lraQ
2) Best Overall StartUp Of 2009: http://crunchies.techcrunch.com/vote/?MTg6WFdpa2k
3) Best International StartUp: http://crunchies.techcrunch.com/vote/?ODpYV2lraQ
You can submit one nomination per category per day until December 4th
2009 at Midnight PST.
General vote link: http://crunchies2009.techcrunch.com/vote/
Thanks a lot for your participation and support!
-Vincent
PS: About the Crunchies:
The 2009 Crunchies is our third annual competition and award ceremony
to recognize and celebrate the most compelling startups, internet and
technology innovations of the year.
- Where: the award ceremony will take place in San Francisco
- When: on Friday, January 8, 2010, at 7:30 pm
Hello,
I'm Using XWiki Enterprise 2.0.3
when i'm trying to catch the events that are triggered from rename and delete both the events are DocumentDeleteEvent. I would like to know how xwiki is differentiating both these events as i need to perform some actions depending upon the event which is triggered in my component .
In 2.0 version when i do a rename action the event which is triggered is DocumentUpdateEvent and for the delete it is DocumentDeleteEvent . Is there anything which is changed in the implementation between the two releases. i checked the release notes and there is nothing explained about this.
Can you help regarding this issue?
Regards
Durga
I created some pages in Chinese names.
Problem 1:
Ctrl + G can't find those pages.
Problem 2:
Document Index show these pages as ?????
(http://192.168.1.213:8080/xwiki/bin/view/Main/AllDocs)
I have newly installed 2.1M1 zip version running on port 8080. And
2.0.3 running side by side on port 80. 2.0.3 doesn't have such
problems.
--
-- Currahee! We stand alone together!
Hi,
I've done some XWiki profiling and it seems that the biggest bottlenecks are
Velocity template evaluating (in XWikiVelocityRenderer) and Lucene Index
Updater thread...
Did you think about using StringResourceLoader (or something similar)
instead of Velocity.evaluate()? I believe caching parsed ASTs rather than
reparsing the same strings everytime could significantly improve overall
performance.
Here you can find some interesting discussion about StringResourceLoader -->
http://www.mail-archive.com/user@velocity.apache.org/msg02135.html
Well, I'd like to give it a try. Do you know any traps/gotchas I should be
aware of?
Kind regards
Lukasz
Hi,
I'm applying Caleb's path for http://jira.xwiki.org/jira/browse/XWIKI-1082
("When renaming a page, also update the "parent" field of subpages").
We need a new signature for rename so that the rename UI can let the
user decide which document having the document being renamed as parent
needs to be updated.
Document.rename(String newDocumentName, List<String>
backlinkDocumentNames, List<String> childDocumentNames)
Here's my +1
Thanks
-Vincent
Hi
Based on this JIRA report:
http://jira.xwiki.org/jira/browse/XWIKI-4430
it would be necessary to create a new set of methods just to be able
to pass an additional parameter to the calls. Because this makes it
harder and harder to deal with Plugin I would suggest to use a
Parameter Container which could contain:
- Feed Type (Blog, Web, etc)
- Type (Query, List or Feed )
- List
or
- Query, Count and Start
or
- Feed
- Metadata
- Object Class Name
- Output Type (RSS, Atom etc)
Then we would only need 2 major methods:
- SyncdFeed getFeed( FeedParams )
- String getFeedOutput( FeedParams )
This is what I came up so far (without the Feed Type):
/**
* @see #getBlogFeed(String, int, int, Map)
* @see #getFeedOutput(SyndFeed, String)
*/
public String getBlogFeedOutput( FeedParams params)
{
SyndFeed feed = getBlogFeed( params );
String ret = getFeedOutput( feed, params.getOutputType() );
return ret;
}
public SyndFeed getBlogFeed( FeedParams params)
{
Map<String, Object> myMetaData = Collections.emptyMap();
if( params.getMetaData() != null ) {
myMetaData = params.getMetaData();
}
Map<String, Object> blogMappings = null;
if( params.getObjectClassName() == null ) {
blogMappings = BLOG_FIELDS_MAPPING;
} else {
blogMappings = new HashMap<String, Object>();
blogMappings.put(SyndEntryDocumentSource.FIELD_TITLE,
params.getObjectClassName() + "_title");
blogMappings.put
(SyndEntryDocumentSource.FIELD_DESCRIPTION, params.getObjectClassName
() + "_content");
blogMappings.put
(SyndEntryDocumentSource.FIELD_CATEGORIES, params.getObjectClassName()
+ "_category");
blogMappings.put(SyndEntryDocumentSource.CONTENT_LENGTH,
new Integer(400));
}
SyndFeed blogFeed = null;
if( params.getType() == FeedParams.Type.QUERY ) {
String query = params.getQuery();
if (query == null) {
XWikiRequest request = getXWikiContext().getRequest();
String category = request.getParameter("category");
if (category == null || category.equals("")) {
query =
", BaseObject as obj where
obj.name=doc.fullName and obj.className='" + BLOG_POST_CLASS_NAME + "'
and obj.name<>'" + BLOG_POST_TEMPLATE_NAME + "' order by
doc.creationDate desc";
} else {
query =
", BaseObject as obj, DBStringListProperty as
prop join prop.list list where obj.name=doc.fullName and
obj.className='" + BLOG_POST_CLASS_NAME + "' and obj.name<>'" +
BLOG_POST_TEMPLATE_NAME + "' and obj.id=prop.id.id and
prop.id.name='category' and list = '"
+ category + "' order by doc.creationDate
desc";
}
}
blogFeed = getFeed(
query, params.getCount(), params.getStart(),
getSyndEntrySource(SyndEntryDocumentSource.class.getName(),
blogMappings), Collections.EMPTY_MAP, fillBlogFeedMetadata(myMetaData)
);
} else {
blogFeed = getFeed(
params.getEntries(), getSyndEntrySource
(SyndEntryDocumentSource.class.getName(), blogMappings),
Collections.EMPTY_MAP, fillBlogFeedMetadata(myMetaData)
// params.getEntries(), getSyndEntrySource
(SyndEntryDocumentSource.class.getName(), blogMappings), myMetaData,
fillBlogFeedMetadata(myMetaData)
);
}
if (blogFeed != null) {
blogFeed.setImage(getDefaultFeedImage());
}
return blogFeed;
}
public static class FeedParams {
public enum Type {
QUERY,
LIST
}
private static final String DEFAULT_OUTPUT_TYPE = "rss_2.0";
private static final int DEFAULT_COUNT = 10;
private static final int DEFAULT_START = 0;
private Type type;
private List<Object> entries;
private String query;
private int count = DEFAULT_COUNT;
private int start = DEFAULT_START;
private Map<String, Object> metaData;
private String outputType = DEFAULT_OUTPUT_TYPE;
private String objectClassName;
public FeedParams( List<Object> entries, String
objectClassName, Map<String, Object> metaData, String outputType ) {
this.type = Type.LIST;
this.entries = entries;
this.metaData = metaData;
this.outputType = outputType == null ?
DEFAULT_OUTPUT_TYPE : outputType;
this.objectClassName = objectClassName;
}
public FeedParams( String query, Integer count, Integer
start, String objectClassName, Map<String, Object> metaData, String
outputType ) {
this.type = Type.QUERY;
this.count = count == null ? DEFAULT_COUNT : count;
this.start = start == null ? DEFAULT_START: start;
this.metaData = metaData;
this.outputType = outputType == null ?
DEFAULT_OUTPUT_TYPE : outputType;
this.objectClassName = objectClassName;
}
public Type getType() {
return type;
}
public String getQuery() {
return query;
}
public int getCount() {
return count;
}
public int getStart() {
return start;
}
public List<Object> getEntries() {
return entries;
}
public Map<String, Object> getMetaData() {
return metaData;
}
public String getOutputType() {
return outputType;
}
public String getObjectClassName() {
return objectClassName;
}
}
What do you think?
-Andy
When I try to load a Groovy script using xwiki.parseGroovyFromPage()
then I fail when this Script is enclosed inside '{{groovy}}'. This
means I have to use two different documents when I want to use the
same document to be loaded by XWiki and by xwiki.parseGroovyFromPage()
because one needs the be enclosed by '{{groovy}} and the other can't.
Isn't there a way to remove '{{groovy}}' when parsed so that the
scripts can be used for both?
In addition the 'GroovyScriptEngineImpl' which is used for the Binding
does throw a NoSuchPropertyException when a property is not available.
This makes it cumbersome to test for properties and add them if not
already put inside. For example I need some objects over and over like
'BlogParams' and so I would like to store them inside the bindings. In
order to avoid the exception I either have to catch the Exception
(time consuming) or I need to get the properties map and check if the
property is already added to the map.
Is there a better way to do that?
Cheers - Andy
Hello friends of XWiki,
Several XWiki members will be participating at FOSDEM next year in
February ( http://fosdem.org/ ), and we're trying to determine if
there's interest in applying for a devroom, which would mean half a day
or more of XWiki-related presentations.
- Are there any people interested in participating to such presentations?
- Does anybody want to do such a presentation, besides XWiki committers?
I'd need answers to these questions soon, since the deadline for
application is in two days. Note that FOSDEM is a developer-oriented
conference, so presentations should be rather technical.
FYI, there is no participation fee, anybody can attend FOSDEM as long as
there are places in the rooms.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
The XWiki development team is pleased to announce the release of XWiki
Enterprise 2.1 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
It's the first and only milestone of the 2.1 version.
Main changes from 2.0.3:
* Re-design of the actions menus. Split the top menu into 2: one for
wiki and space level actions and one for page level actions.
* New renderer for mathematical formulae based on the Google Chart APIs.
* Added PHP support through a new PHP Macro (note that this Macro is
not bundled by default, you'll need to install it).
* Lots of improvements and bugfixes in order to conform to the Web
Content Accessibility Guidelines (WCAG).
* Macro parameter pretty names are now displayed in the WYSIWYG
* WYSIWYG editor performance improvement (Minimize and aggregate
WYSIWYG editor stylesheets at build time to reduce the number of HTTP
requests)
* Upgraded to JbossCache 3.2.1GA version
* Upgraded to Groovy 1.7 Beta 2
* Lots of bugs fixes
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise21M1
Thanks
-The XWiki dev team
On Nov 19, 2009, at 1:48 PM, vmassol (SVN) wrote:
> Author: vmassol
> Date: 2009-11-19 13:48:06 +0100 (Thu, 19 Nov 2009)
> New Revision: 25212
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java
> Log:
> [misc] web --> space
ouch, I committed too much....
-Vincent
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/XWikiDocument.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java 2009-11-19 11:51:51 UTC (rev 25211)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java 2009-11-19 12:48:06 UTC (rev 25212)
> @@ -447,13 +447,13 @@
> * Constructor that specifies the full document identifier: wiki
> name, space name, document name.
> *
> * @param wiki The wiki this document belongs to.
> - * @param web The space this document belongs to.
> + * @param space The space this document belongs to.
> * @param name The name of the document.
> */
> - public XWikiDocument(String wiki, String web, String name)
> + public XWikiDocument(String wiki, String space, String name)
> {
> setDatabase(wiki);
> - setSpace(web);
> + setSpace(space);
>
> int i1 = name.indexOf(".");
> if (i1 == -1) {
> @@ -4166,8 +4166,9 @@
> }
>
> /**
> - * Rename the current document and all the backlinks leading to
> it. See
> - * {@link #rename(String, java.util.List,
> com.xpn.xwiki.XWikiContext)} for more details.
> + * Rename the current document and all the backlinks leading to
> it. The parent field in all documents which list
> + * the renamed document as their parent is also renamed.
> + * See {@link #rename(String, java.util.List, java.util.List,
> com.xpn.xwiki.XWikiContext)} for more details.
> *
> * @param newDocumentName the new document name. If the space is
> not specified then defaults to the current space.
> * @param context the ubiquitous XWiki Context
> @@ -4187,9 +4188,11 @@
> * <li>[Page?param=1]</li>
> * <li>[currentwiki:Page]</li>
> * <li>[CurrentSpace.Page]</li>
> + * <li>[currentwiki:CurrentSpace.Page]</li>
> * </ul>
> * <p>
> - * Note: links without a space are renamed with the space added.
> + * Note: links without a space are renamed with the space added
> and all documents having the renamed document as
> + * their parent have their parent field set to
> "currentwiki:CurrentSpace.Page".
> * </p>
> *
> * @param newDocumentName the new document name. If the space is
> not specified then defaults to the current space.
> @@ -4228,43 +4231,57 @@
> return;
> }
>
> + // Grab the XWiki object, it gets used a few times.
> + com.xpn.xwiki.XWiki xwiki = context.getWiki();
> +
> // Step 1: Copy the document and all its translations under
> a new name
> - context.getWiki().copyDocument(getFullName(),
> newDocumentName, false, context);
> + xwiki.copyDocument(getFullName(), newDocumentName, false,
> context);
>
> - // Step 2: For each backlink to rename, parse the backlink
> document and replace the links
> - // with the new name.
> - // Note: we ignore invalid links here. Invalid links should
> be shown to the user so
> - // that they fix them but the rename feature ignores them.
> + // Step 2: For each child document, update parent.
> + List<String> childDocumentNames = getChildren(context);
> + if(childDocumentNames != null){
> + // Note: We're adding the fully qualified document name
> (i.e. including the wiki name).
> + String newParent = newDocName.getWiki() + ":" +
> newDocName.getSpace() + "." + newDocName.getPage();
> +
> + for (String childDocumentName : childDocumentNames) {
> + XWikiDocument childDocument =
> xwiki.getDocument(childDocumentName, context);
> + childDocument.setParent(newParent);
> + xwiki.saveDocument(childDocument,
> context.getMessageTool().get("core.comment.renameParent",
> + Arrays.asList(new String[] {newDocumentName})),
> true, context);
> + }
> + }
> +
> + // Step 3: For each backlink to rename, parse the backlink
> document and replace the links with the new name.
> + // Note: we ignore invalid links here. Invalid links should
> be shown to the user so that they fix them but the
> + // rename feature ignores them.
> DocumentParser documentParser = new DocumentParser();
>
> for (String backlinkDocumentName : backlinkDocumentNames) {
> - XWikiDocument backlinkDocument =
> context.getWiki().getDocument(backlinkDocumentName, context);
> + XWikiDocument backlinkDocument =
> xwiki.getDocument(backlinkDocumentName, context);
>
> if (backlinkDocument.is10Syntax()) {
> // Note: Here we cannot do a simple search/replace
> as there are several ways to point
> // to the same document. For example [Page], [Page?
> param=1], [currentwiki:Page],
> // [CurrentSpace.Page] all point to the same
> document. Thus we have to parse the links
> // to recognize them and do the replace.
> - ReplacementResultCollection result =
> -
> documentParser.parseLinksAndReplace(backlinkDocument.getContent(),
> oldLink, newLink, linkHandler,
> - getSpace());
> + ReplacementResultCollection result =
> documentParser.parseLinksAndReplace(
> + backlinkDocument.getContent(), oldLink,
> newLink, linkHandler, getSpace());
>
> backlinkDocument.setContent((String)
> result.getModifiedContent());
> } else {
> backlinkDocument.refactorDocumentLinks(oldDocName,
> newDocName, context);
> }
>
> - context.getWiki().saveDocument(backlinkDocument,
> -
> context.getMessageTool().get("core.comment.renameLink",
> Arrays.asList(new String[] {newDocumentName})),
> - true, context);
> + xwiki.saveDocument(backlinkDocument,
> context.getMessageTool().get("core.comment.renameLink",
> + Arrays.asList(new String[] {newDocumentName})),
> true, context);
> }
>
> - // Step 3: Delete the old document
> - context.getWiki().deleteDocument(this, context);
> + // Step 4: Delete the old document
> + xwiki.deleteDocument(this, context);
>
> - // Step 4: The current document needs to point to the
> renamed document as otherwise it's
> - // pointing to an invalid XWikiDocument object as it's been
> deleted...
> - clone(context.getWiki().getDocument(newDocumentName,
> context));
> + // Step 5: The current document needs to point to the
> renamed document as otherwise it's pointing to an
> + // invalid XWikiDocument object as it's been deleted...
> + clone(xwiki.getDocument(newDocumentName, context));
> }
>
> private void refactorDocumentLinks(DocumentName oldDocumentName,
> DocumentName newDocumentName, XWikiContext context)
We could upgrade now to get checkstyle 5.
-Vincent
Begin forwarded message:
> From: Mark Hobson <markh(a)apache.org>
> Date: November 19, 2009 10:22:34 AM CEST
> To: announce(a)maven.apache.org, users(a)maven.apache.org
> Subject: [ANN] Maven Checkstyle Plugin 2.4 Released
> Reply-To: "Maven Users List" <users(a)maven.apache.org>
>
> The Maven team is pleased to announce the release of the Maven
> Checkstyle Plugin, version 2.4.
>
> This plugin generates a report on violations of code style and
> optionally fails the build if violations are detected.
>
> http://maven.apache.org/plugins/maven-checkstyle-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-checkstyle-plugin</artifactId>
> <version>2.4</version>
> </plugin>
>
> Release Notes - Maven 2.x Checkstyle Plugin - Version 2.4
>
> ** Improvement
> * [MCHECKSTYLE-105] - Update to Checkstyle 5.0
> * [MCHECKSTYLE-122] - Add Portuguese (Brazil) translation
> * [MCHECKSTYLE-124] - Add Swedish translation
>
> ** Task
> * [MCHECKSTYLE-119] - Review the Doxia Sink calls
> * [MCHECKSTYLE-120] - Bump to Doxia 1.0
> * [MCHECKSTYLE-125] - Update to maven-reporting-impl-2.0.4.3
>
> Enjoy,
>
> -The Maven team
[XWiki Enterprise 2.0.3 on Windows XP]
Hi,
XWiki Enterprise\webapps\xwiki\WEB-INF\xwiki.cfg file contains the following
lines:
#-# Enable light monitoring of the wiki performance. Records various
statistics, like number of requests processed,
#-# time spent in rendering or in the database, medium time for a request,
etc. Disable for a minor increase of
#-# performance and a bit of memory.
# xwiki.monitor=1
This is quite misleading because although xwiki.monitor=1 is commented out
XWiki still monitor requests. To actully turn it off one has to put
xwiki.monitor=0
I would vote to turn off monitoring if xwiki.monitor setting is not defined
(i.e. is commented out).
Kind regards
Lukasz
Hi,
Whenever a panel is displayed more than once (ie on the panel page
itself if the page is also displayed in a panel column, in the panel
wizard, etc) we have invalid XHTML for panels that use an HTML ID
attribute. We have this in the search panel right now which I'd like
to fix.
In addition with Colibri we've hardcoded the search panel content in
the header.
Here's what I'd like to do:
1) Use class name of globalsearch and globalsearchinput instead of IDs
Note: WCAG tests forbid using <label> without a FOR attribute which
means we need an ID for the input. This can be achieved easily using
velocity to increment a counter. This is a technical internal ID
anyway so it won't matter.
2) In Colibri, use #displaypanel(Panels.Search) instead of hardcoding
the panel content in the header. This allow users to edit the content
for example to change the link to Main/Websearch to Main/LuceneSearch
or do any other thing).
Note: the only change between what is currently in the Search panel
and in the colibri header is the image which can be overwritten in
colibri I guess. A better solution (if someone with CSS skills can
help me) might be to define the image to display in the CSS.
3) In the release notes, mention the change and tell users that if
they want to keep the old behavior (for ex if they have a custom skin
using the globalsearch* IDs) then they just need to edit the Search
panel and replace "class" by "id".
Here's my +1
Thanks
-Vincent
Hi,
we found in the svn-sandbox, that some kind of ntlm authentication is
implemented. In Jira we found the following request for that "XWIKI-2496
Single Sign on HTTP Negiotiate login" (hope we are right on that).
Is this feature planned for an upcoming release?
We would also be interested in testing!
Thanks
Helmut
--
View this message in context: http://n2.nabble.com/NTLM-Authentication-tp4024303p4024303.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
Currently it's not possible to list support BlockRenderer syntaxes
like we do for Parser for example.
So i propose to add
Syntax getSyntax();
to BlockRenderer interface
Here is my +1
--
Thomas Mortagne
On Nov 18, 2009, at 12:44 AM, mflorea (SVN) wrote:
> Author: mflorea
> Date: 2009-11-18 00:44:21 +0100 (Wed, 18 Nov 2009)
> New Revision: 25111
>
> Modified:
> platform/web/branches/xwiki-web-2.0/wysiwyg/src/main/resources/com/
> xpn/xwiki/wysiwyg/client/editor/Strings.properties
> Log:
> XWIKI-4581: Change the name for "Background Color" to "Highlight
> Color"
>
> Merged from trunk, revision 25110.
>
>
> Modified: platform/web/branches/xwiki-web-2.0/wysiwyg/src/main/
> resources/com/xpn/xwiki/wysiwyg/client/editor/Strings.properties
> ===================================================================
> --- platform/web/branches/xwiki-web-2.0/wysiwyg/src/main/resources/
> com/xpn/xwiki/wysiwyg/client/editor/Strings.properties 2009-11-17
> 23:43:13 UTC (rev 25110)
> +++ platform/web/branches/xwiki-web-2.0/wysiwyg/src/main/resources/
> com/xpn/xwiki/wysiwyg/client/editor/Strings.properties 2009-11-17
> 23:44:21 UTC (rev 25111)
> @@ -5,7 +5,7 @@
> apply=Apply
> select=Select
> attachment=Insert an Attachment Link
> -backColor=Background Color
> +backColor=Highlight Color
Minor:
Is it the background color or the highlight color?
If highlight is the correct one then maybe the key name should be
changed too? At the very least I think a comment would be necessary
since someone reading this line will not know who's right... the key
or the value... Highlight is a term that refers to me as a foreground
color.
Thanks
-Vincent