Hi,
I've done fast test with some people here (10 users, 7 no-XWiki users, 3
XWiki users):
2. 1/10 has read *XNiki* in option A and *XWiki* in option B; she was
no-XWiki user.
3. 1/10 has read *lambda wiki* in option A and *XWiki* in option B; she
was no-XWiki user.
3. Some no-XWiki users, 5/10 have had some problems to identify the X
both in option A and B.
4. All users consider that *wiki* is clearer in option B.
5. XWiki users read XWiki in both A and B.
Please, consider that no experimental design is under the scene! :-)
Cheers,
Ricardo
Raluca Stavro wrote:
> Hi all,
>
> How about this alternative:
> http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallengeRound2/16-va….
> I think that the W is readable now.
>
> Raluca.
>
> On Wed, Apr 14, 2010 at 11:06 AM, Valdis Vītoliņš
> <valdis.vitolins(a)odo.lv> wrote:
>
>> Readability is better, but for me upper right backgoing "serif" for w
>> seems unnecessary.
>> In place of (ascii art):
>> \// \
>> /\\/\/iki
>>
>> only in this way:
>> \/
>> /\\/\/iki
>>
>> Then X can be bigger and w can be aligned with k.
>> What do you think?
>>
>> Valdis
>>
>>
>>> I completely agree with Marius, I would also add that since this is a
>>> Community project, it should have a Community logo !
>>> Since 16 has receive many votes now, and that I also agree with
>>> Vincent,
>>> Ludovic and others, it is not readable enough, I have made an
>>> alternative
>>> design: W-angle. My feeling was that the W is difficult to read, so my
>>> proposal try to keep the style and reworked it. There is also small
>>> changes
>>> in spacing, and a different powered by button.
>>>
>>> Here is almost all that was requested in a proposal with this
>>> variable:
>>> http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallengeRound2/16%2D…
>>>
>>> I really hope that if the logo 16 is chosen, my proposal could help in
>>> mitigating the disappointment of those that really find it
>>> unacceptable.
>>>
>>> WDYT ?
>>>
>>> Denis
>>>
>> _______________________________________________
>> users mailing list
>> users(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Ricardo RodrÃguez
CTO
eBiotic.
Life Sciences, Data Modeling and Information Management Systems
On 04/12/2010 04:30 PM, Thibaut Camberlin wrote:
> My corrected vote is +1 for 12A.
12A has been retired and is no longer a valid option. Please choose
another one.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Note that the 2.3 branches have been created. Don't forget to merge
your fixes in those branches and fixes for blocker bugs in:
trunk/2.2/2.3.
XE 2.3 RC1 will be released as soon as tests succeed on the continuous build.
Thanks,
JV.
On Apr 12, 2010, at 12:05 PM, jvelociter (SVN) wrote:
> Author: jvelociter
> Date: 2010-04-12 12:05:45 +0200 (Mon, 12 Apr 2010)
> New Revision: 28239
>
> Modified:
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js
> Log:
> XWIKI-5094 Administration rights editor cannot be used in portlet mode
>
> Merged from branch 2.2
>
>
> Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js 2010-04-12 10:04:39 UTC (rev 28238)
> +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js 2010-04-12 10:05:45 UTC (rev 28239)
> @@ -367,8 +367,9 @@
> var uorg = table.json.uorg;
> var allows = row.allows;
> var denys = row.denys;
> - var saveUrl = "?xpage=saverights&clsname=" + table.json.clsname + "&fullname=" + row.fullname + "&uorg=" + uorg;
>
> + var saveUrl = window.docviewurl + "?xpage=saverights&clsname=" + table.json.clsname + "&fullname=" + row.fullname + "&uorg=" + uorg;
> +
BTW can we guarantee that table.json.clsname, row.fullname and uorg don't contain any character that would need to be URL-encoded?
Thanks
-Vincent
PS: We need a URL factory on the JS side to create valid URLs with proper encoding.
[snip]
Hi
After using my Groovy based XWiki Blog I decided that I am not going to pursue this any further because of these issues:
- Groovy applications still have more limitations than Velocity making it very difficult to use as an alternative
- It is very difficult to deploy my own Groovy blog application because I have to go over several hoops to install it (content, plugins, plugin configurations)
- Most of the issues where related to Groovy based Panels which seems not to be possible
- No interest in it
Even though I think that Groovy would be a much better way to script applications like the Blog XWiki seems not to be ready to embrace it. From my point of view the entrenched usage of Velocity makes it very difficult to go beyond a simple page script in another scripting language.
Cheers
Andreas Schaefer
CEO of Madplanet.com Inc.
Email: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter; andy_mpc
AIM: schaefera(a)me.com
Hi devs,
Since the JSR330 is now accepted as final and thus as a standard, I'd like to propose that we modify our component annotations to use it.
Rationale
========
The advantages of using it are:
* Be standard, ie:
** Our components will be able to be re-used by injectors other than ours (Guice for example)
** Since IDEs will support JSR330 they'll be able to offer features for our code (auto complete, graph, etc), for ex http://blogs.jetbrains.com/idea/tag/dependency-injection/
Proposed Changes
===============
Note: JSR330 doesn't specify how components should be bound, hence the need to keep xwiki-specific metadata for the bindings.
* @Component and @ComponentRole stay unchanged
* Deprecate @Requirement, replaced by @Inject
* Use @Named or application-specific annotations (based on @Qualifier) instead of hints specified in the @Requirement annotation
* Add new @Role(Class) to specify a dependency role in the case of collections (since generics are not available using reflection in Java)
* Deprecate @InstantiationStrategy, replaced by @Singleton. We don't need to introduce any other scope annotations for now.
* Note that the default scope in the JSR330 spec is "per lookup". Since our default is singleton, we'll need to add @Singleton annotations everywhere we used to not have anything.
Example before:
@Component("html")
public class HTMLMacro extends AbstractMacro<HTMLMacroParameters>
{
...
@Requirement
private HTMLCleaner htmlCleaner;
...
@Requirement("xhtmlmacro/1.0")
private PrintRendererFactory xhtmlRendererFactory;
...
Same example after the change:
@Component("html")
public class HTMLMacro extends AbstractMacro<HTMLMacroParameters>
{
...
@Inject
private HTMLCleaner htmlCleaner;
...
@Inject
@Named("xhtmlmacro/1.0")
private PrintRendererFactory xhtmlRendererFactory;
...
WDYT?
Thanks
-Vincent
Hi,
yesterday I'v set up a new wiki (with the new Milestone 2).
I've followed the instructions to set up short urls:
http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs
with one difference. Instead of using mod_redirect for the Apache HTTPD
I'm using mod_proxy and mod_rewrite so that an url
www.mydomain.com/docs -> (internal-ip) 192.168.1.n/appContext
The effect is that from the internet only the new naming schema is
visible and not the default 'long' url resolution.
This works fine so far, except for one issue:
In all cases where xwiki generates redirection urls like this example
for "Logout"
/docs/logout/XWiki/XWikiLogout?xredirect=http://www.mydomain.com/appContext/docs/XWik/aha
What's wrong IMHO is "appContext" - part of the ?xredirect - this
exposes the internal webapppath back to the caller.
I have configured the xwiki.cfg to not using the appPath:
xwiki.webapppath=/ but this setting is not used,
instead the deployment webappPath is used for ?xredirect.
In all other cases (except the ?xredirect) the configured webapppath
seems to be used correctly.
This is my configuration:
in xwiki.cfg:
xwiki.webapppath=/ (because this is handled by mod_rewrite)
xwiki.defaultservletpath=docs/ (use "docs" instead of "bin")
xwik.showviewaction=0
in web.xml
param-value of "redirectHomeServlet" to http://www.mydomain.com/docs/Main
and added a <servlet-mapping> pattern for "action" to /docs/*
for completeness here's the mod_rewrite <VirtualHost> configuration (Ubuntu)
<VirtualHost *>
ServerName www.mydomain.com
ServerAdmin wiki(a)mydomain.com
RewriteEngine On
RewriteLog /var/log/wiki_rewrite.log
RewriteLogLevel 2
CustomLog /var/log/wiki_custom.log common
ErrorLog /var/log/wiki_error.log
# use [P] for Proxy and NOT [R] for redirect !
RewriteRule ^/(.*) http://www.mydomain.com/appContext/$1
[L,P,E=proxy_ok:1]
ProxyPreserveHost On
</VirtualHost>
and this is the mod_proxy
<IfModule mod_proxy.c>
#turning ProxyRequests on and allowing proxying from all may allow
#spammers to use your proxy to send email.
ProxyRequests Off
<Proxy *>
AddDefaultCharset off
Order deny,allow
Deny from all
# Proxies just in case Proxy_ok is set
Allow from env=proxy_ok
</Proxy>
# Not sure whether we need this ...
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
ProxyVia On
</IfModule>
thanks for your support
Andreas