Hi,
Right now we check pages in our functional tests (xhtml validity, no error when executing the page, no failing macro).
I was wondering about the idea of having the checks done inside wiki pages so that we could provide a sanity check wiki page in the admin section for admins.
Then we would use that page from our junit test and people would also be able to run it too from inside their wiki.
Thus killing 2 birds with one stone
I think we're lacking such kind of tools for wiki admins and it could be interesting.
WDYT?
Thanks
-Vincent
----- "Denis Gervalle" <dgl(a)softec.lu> wrote:
> On Thu, May 6, 2010 at 15:43, Jerome Velociter <jerome(a)xwiki.com>
> wrote:
>
> > Hi Denis,
> >
> > It's pretty nice.
> >
> > I've added an annotation on the patch
> >
> >
> >
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer…
> >
> > The annotation dropped the end of my selection, it actually concerns
> the
> > following lines :
> >
> > + #if($!hasPageSize)
> > + document.observe("xwiki:livetable:${divid}:loadingEntries",
> function()
> > { $('${divid}-pagesize').addClassName("hidden"); } );
> > + document.observe("xwiki:livetable:${divid}:loadingComplete",
> > function() { $('${divid}-pagesize').removeClassName("hidden"); } );
> > + #end
> >
> >
> Well, I do not follow. The JS is able to display one or more control,
> anywhere you want.
As well as it could be able to do the hiding on all such controls (LiveTablePageSizer has a references on all said domNodes)
Choosing to put only one, and in the same place
> then the
> loading bar is just a design choice, that is the responsability of the
> code
> that produce the markup (the macro here). And the behavior of hiding
> the
> control is related.
I don't see why placing it somewhere else (or having more) you would want a different behavior.
In my opinion the macro should just consume the livetable JS constructor. If you need more JS code, it's probably that you need new options in the constructor (options which possibly be callback functions, not necessarly just flags/values).
Finally, I think the proper behavior here would be to disable the control, instead of hidding its container.
WDYT?
Jerome.
This is why I choose to add a additional even to
> the
> table, and put the observe in the macro.
>
> Denis
>
>
> > Jerome.
> >
> > ----- Original Message -----
> > From: "Guillaume Lerouge" <guillaume(a)xwiki.com>
> > To: "XWiki Developers" <devs(a)xwiki.org>
> > Sent: Thursday, May 6, 2010 3:10:01 PM GMT +01:00 Amsterdam / Berlin
> / Bern
> > / Rome / Stockholm / Vienna
> > Subject: Re: [xwiki-devs] [Proposal] Support choosing pagination
> size in
> > livetable UI
> >
> > Hi,
> >
> > On Thu, May 6, 2010 at 15:05, Denis Gervalle <dgl(a)softec.lu> wrote:
> >
> > > On Thu, May 6, 2010 at 14:55, Guillaume Lerouge
> <guillaume(a)xwiki.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu, May 6, 2010 at 14:33, Denis Gervalle <dgl(a)softec.lu>
> wrote:
> > > >
> > > > > Hi devs,
> > > > >
> > > > > Currently the number of rows displayed in a livetable is fixed
> at
> > > > creation
> > > > > time.
> > > > > I proposed to add UI controls (currently select) that allows
> to
> > change
> > > > the
> > > > > pagination size freely by the end user.
> > > > >
> > > > > This patch is be both a change in livetable.js to support
> these
> > > controls
> > > > > (one or more), and a change in the livetable macro to allow
> > displaying
> > > > > them.
> > > > > I have already a patch and some screenshots as well as bare
> > > > documentation,
> > > > > you can review them all at
> > > > >
> > > >
> > >
> >
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer
> > > > >
> > > > > I am currently testing different browsers to ensure there is
> no
> > > > regression.
> > > > >
> > > > > WDYT ?
> > > > >
> > > >
> > > > Sounds very nice to me, I was asked about it in the past so I'm
> +1.
> > > >
> > > > Only question -> is the preference remembered for the user? I
> guess not
> > > and
> > > > that the default still is the number chose by the livetable
> creator,
> > but
> > > > thought I'd ask.
> > > >
> > >
> > > Well this is mainly a new functionality on the livetable, no
> change in XE
> > > in
> > > my patch currently. My feeling is that keeping the information for
> the
> > user
> > > should not be done by the livetable itself (JS), but by the caller
> (the
> > > macro, why not). It would not be so difficult to do with cookies,
> it
> > would
> > > be a little bit more work to store the information in the user
> profile.
> > > Anyway, this is a second step.
> > >
> > > By the way, I have not proposed to change the current pages of XE,
> but it
> > > could be a nice idea. Do not hesitate to propose page you want me
> to
> > > improve. The other way, we may also set this new feature as a
> default, so
> > > it
> > > will apear on all existing livetables using the macro, and allow
> > disabling
> > > it. WDYT ?
> > >
> >
> > Yes, I'd make this available by default to all livetables, with a
> > configuration parameter allowing to disable it on a case-by-case
> basis.
> >
> > Guillaume
> >
> >
> > > Denis
> > >
> > > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > > eGuilde sarl - CTO
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> >
> > --
> > Guillaume Lerouge
> > Product Manager - XWiki SAS
> > Skype: wikibc
> > Twitter: glerouge
> > http://guillaumelerouge.com/
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hi devs,
Currently the number of rows displayed in a livetable is fixed at creation
time.
I proposed to add UI controls (currently select) that allows to change the
pagination size freely by the end user.
This patch is be both a change in livetable.js to support these controls
(one or more), and a change in the livetable macro to allow displaying them.
I have already a patch and some screenshots as well as bare documentation,
you can review them all at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer
I am currently testing different browsers to ensure there is no regression.
WDYT ?
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi,
How do I add a custom access levels to my xwiki. (eg : upload level, Here
the user can edit the page but can't add attachments to it) .
I tried to implant some solutions using groovy but i dind't succeed, so is
there any other way please let me know.
thanks.
Hi devs,
Due to special circumstances (hitting XWIKI-5166 while upgrade XWiki.org to 2.3), we've face the <body> database className conflict again, on code.xwiki.org.
What happens is that the "code" DOM class name is apposed to the body element (see htmlheader.vm), and this interferes with styles defined for the {{code}} macro. Potentially there are other scenarios where class names can conflict with database names.
I propose we prefix the apposed class name with "wiki-" (that's what we've been doing on xwiki.org for some time now) in order to avoid this.
Though, we need to agree on this, since it can be a breaking change for those who relied on that "feature" to skin differently different wikis on a farm.
WDYT ?
Jerome.
It might sound silly but if there are no security requirements then there are no security holes.
We all know when we see something which shouldn't happen but I don't think there is any page
defining exactly what the security requirements are.
1. Users should not be able to spawn additional processes on the server.
2. Users should not be able to commit changes to the database except through the saveDocument function.
3. Users should not be able to save documents without their name as the author or contentAuthor as applicable.
4. Guests should not be able to execute server side script except that which was written and saved by a user.
This list is doesn't cover much yet, I hope to see some additions and discussion of may code may violate some
the rules as well as how we can have 'untrusted' code which is unable to violate the rules.
I propose we put up a design page for maintenance of this list.
WDYT?
Caleb
On May 5, 2010, at 7:38 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-05-05 19:38:38 +0200 (Wed, 05 May 2010)
> New Revision: 28744
>
> Added:
> enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java
> Modified:
> enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java
> enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java
> Log:
> XWIKI-5161: Using XML symbols (<, >, &, ") inside the document title/name/space breaks various parts of the UI and causes the PDF export to throw exceptions
> Added test.
hmm shouldn't the test be more "functional"?
For example, if we test the create page use case using a page with a special char, we could test this use case at the same time, no?
Thanks
-Vincent
> Added: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java
> ===================================================================
> --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java (rev 0)
> +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java 2010-05-05 17:38:38 UTC (rev 28744)
> @@ -0,0 +1,46 @@
> +/*
> + * See the NOTICE file distributed with this work for additional
> + * information regarding copyright ownership.
> + *
> + * This is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License as
> + * published by the Free Software Foundation; either version 2.1 of
> + * the License, or (at your option) any later version.
> + *
> + * This software is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this software; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> + */
> +package org.xwiki.it.ui;
> +
> +import junit.framework.Assert;
> +
> +import org.junit.Test;
> +import org.xwiki.it.ui.framework.AbstractAdminAuthenticatedTest;
> +import org.xwiki.it.ui.framework.TestUtils;
> +
> +
> +/**
> + * Test various character escaping bugs.
> + *
> + * @version $Id$
> + * @since 2.4M1
> + */
> +public class EscapeTest extends AbstractAdminAuthenticatedTest {
> +
> + @Test
> + public void testEditReflectedXSS()
> + {
> + // tests for XWIKI-4758, XML symbols should be escaped
> + String page = "<>'?&\"";
> + TestUtils.gotoPage("Main", TestUtils.escapeURL(page), "edit", getDriver());
> + Assert.assertTrue(getDriver().getPageSource().indexOf(page) < 0);
> + }
> +}
> +
>
>
> Property changes on: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java
> ___________________________________________________________________
> Name: svn:keywords
> + Author Id Revision HeadURL
> Name: svn:eol-style
> + native
>
> Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java
> ===================================================================
> --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java 2010-05-05 16:17:06 UTC (rev 28743)
> +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java 2010-05-05 17:38:38 UTC (rev 28744)
> @@ -31,7 +31,7 @@
> /**
> * Represents a Form.
> *
> - * @version $Id:$
> + * @version $Id$
> * @since 2.4M1
> */
> public class FormPage extends BasePage
>
> Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java
> ===================================================================
> --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java 2010-05-05 16:17:06 UTC (rev 28743)
> +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java 2010-05-05 17:38:38 UTC (rev 28744)
> @@ -41,7 +41,7 @@
>
> public static void gotoPage(String space, String page, String action, WebDriver driver)
> {
> - gotoPage(space, page, "view", null, driver);
> + gotoPage(space, page, action, null, driver);
> }
>
> public static void gotoPage(String space, String page, String action, String queryString, WebDriver driver)
Release tags should not refer to SNAPSHOT dependencies. It seems the tag has
not been made with maven tag plugin.
Either you can "fix" the tag by changing the dependency to a non-SNAPSHOT
version (like 24), or try to build the trunk which should refer to more
recent deps (i.e., that still exists in the maven repo).
Regards,
Jerome.
--
View this message in context: http://xwiki.475771.n2.nabble.com/Curriki-1-8-5-Local-Installation-Pom-conf…
Sent from the XWiki- Dev mailing list archive at Nabble.com.