Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
20 May
2010
20 May
'10
7:23 p.m.
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log:
XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form
elements
Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
Thanks
-Vincent
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
===================================================================
---
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20
17:11:02 UTC (rev 28949)
+++
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20
17:15:53 UTC (rev 28950)
@@ -609,11 +609,12 @@
for (var i = 0; i < this.inputs.length; ++i) {
var key = this.inputs[i].name;
if ((this.inputs[i].type == "radio") || (this.inputs[i].type ==
"checkbox")) {
- if (this.filters[key]) {
- if (this.filters[key] == this.inputs[i].value.strip()) {
- this.inputs[i].checked = true;
+ var filter = this.filters[key];
+ if (filter) {
+ if (Object.isArray(filter)) {
+ this.inputs[i].checked = (filter.indexOf(this.inputs[i].value.strip()) !=
-1);
} else {
- this.inputs[i].checked = false;
+ this.inputs[i].checked = (filter == this.inputs[i].value.strip());
}
}
} else {
@@ -624,14 +625,14 @@
}
for (var i = 0; i < this.selects.length; ++i) {
- if (!this.filters[this.selects[i].name]) {
- continue;
- }
- for (var j = 0; j < this.selects[i].options.length; ++j) {
- if (this.selects[i].options[j].value == this.filters[this.selects[i].name]) {
- this.selects[i].options[j].selected = true;
- } else {
- this.selects[i].options[j].selected = false;
+ var filter = this.filters[this.selects[i].name];
+ if (filter) {
+ for (var j = 0; j < this.selects[i].options.length; ++j) {
+ if (Object.isArray(filter)) {
+ this.selects[i].options[j].selected =
(filter.indexOf(this.selects[i].options[j].value) != -1);
+ } else {
+ this.selects[i].options[j].selected = (this.selects[i].options[j].value ==
filter);
+ }
}
}
}
@@ -649,7 +650,7 @@
// Ignore filters with blank value
if (!filters[i].value.blank()) {
if ((filters[i].type != "radio" && filters[i].type !=
"checkbox") || filters[i].checked) {
- result += ("&" + filters[i].name + "=" +
encodeURIComponent(filters[i].value));
+ result += ("&" + filters[i].serialize());
}
}
}
21 May
21 May
11:34 a.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net> wrote:
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
This would be nice to have. Building proper tests is not so easy, this could
be very long to setup, since you need to test in several browsers and you
need full AJAX interaction. I am not used to such automated testing, but I
am not sure the investment is worse the improvement we could get from them.
On the other side, I use livetables JS heavily, so you could be assured that
my fixes/improvements are either well tested or will be fixed ASAP since all
changes I introduce is already in production. We also usually test them on
all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4
(Mac) and Chrome (Mac)
FYI, I found this one when we have introduced the usage of hashes to provide
"Back to the list" links. I will soon commit an improvement supporting the
page size in hash as well, so you can really get very precise "back to the
list" return links.
Denis
Thanks
Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log:
XWIKI-5212 - Livetable filter serialization does not properly support
multi-valued
form elements
Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
12:04 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
Hi Denis,
On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
On Thu, May 20, 2010 at 19:23, Vincent Massol
<vincent(a)massol.net> wrote:
It's always worth it.
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
This would be nice to have. Building proper tests is not so easy, this could
be very long to setup, since you need to test in several browsers and you
need full AJAX interaction. I am not used to such automated testing, but I
am not sure the investment is worse the improvement we could get from them. Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log:
XWIKI-5212 - Livetable filter serialization does not properly support
multi-valued
form elements
Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
On the other side, I use livetables JS heavily, so you
could be assured that
my fixes/improvements are either well tested or will be fixed ASAP since all
changes I introduce is already in production.
While this is good enough for you as an individual we cannot rely on this at the project
level. We do need absolutely automated tests written for everything that gets committed to
ensure the quality of XWiki releases.
We also usually test them on
all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4
(Mac) and Chrome (Mac)
FYI, I found this one when we have introduced the usage of hashes to provide
"Back to the list" links. I will soon commit an improvement supporting the
page size in hash as well, so you can really get very precise "back to the
list" return links.
Denis
So you could either write a functional tests using ui-tests or define a new strategy for
testing "XWiki UI Components".
IMO you should start with livetable tests in ui-tests.
Thanks
-Vincent
12:05 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On May 21, 2010, at 12:04 PM, Vincent Massol wrote:
Hi Denis,
On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
Note that the hard part is getting started with it. Once you have your first test,
it's usually very easy to add a second test afterwards and it doesn't take long.
Thanks
-Vincent
On Thu, May 20, 2010 at 19:23, Vincent Massol
<vincent(a)massol.net> wrote:
It's always worth it.
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
This would be nice to have. Building proper tests is not so easy, this could
be very long to setup, since you need to test in several browsers and you
need full AJAX interaction. I am not used to such automated testing, but I
am not sure the investment is worse the improvement we could get from them. Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log:
XWIKI-5212 - Livetable filter serialization does not properly support
multi-valued
form elements
Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
On the other side, I use livetables JS heavily,
so you could be assured that
my fixes/improvements are either well tested or will be fixed ASAP since all
changes I introduce is already in production.
While this is good enough for you as an individual we cannot rely on this at the project
level. We do need absolutely automated tests written for everything that gets committed to
ensure the quality of XWiki releases.
We also usually test them on
all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4
(Mac) and Chrome (Mac)
FYI, I found this one when we have introduced the usage of hashes to provide
"Back to the list" links. I will soon commit an improvement supporting the
page size in hash as well, so you can really get very precise "back to the
list" return links.
Denis
So you could either write a functional tests using ui-tests or define a new strategy for
testing "XWiki UI Components".
IMO you should start with livetable tests in ui-tests.
Thanks
-Vincent
1:29 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On Fri, May 21, 2010 at 12:05, Vincent Massol <vincent(a)massol.net> wrote:
On May 21, 2010, at 12:04 PM, Vincent Massol wrote:
Fine, so I let you write all the tests for the initial and basic live table
functionalities, and once these are available, I will complete them to test
the new features I have recently added ;)
So, just to be serious, I completely agree with you regarding the advantage
of automated tests. But my current feeling about XWiki and its current UI is
that we are not moving fast enough compare to the competition. As well as
there is great components (ie new rendering), there are on the other side a
really bad/complex/tricky/not working UIs compare to similar products. If I
want to be able to continue my contribution on the project (and I d'like
to), I have to concentrate on improving the end user experience first, and
gets new clients paying for my work.
So I am sorry if I cannot currently meet your quality expectations, I just
hope that my intensive usage and testing already helps improving the product
quality, since this is the best I can do right now.
Denis
Hi Denis,
On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
> On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
>>
>>> Author: dgervalle
>>> Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
>>> New Revision: 28950
>>>
>>> Modified:
>>>
>>
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
>>> Log:
>>> XWIKI-5212 - Livetable filter serialization does not properly support
>> multi-valued form elements
>>> Merge from trunk r28947
>>
>> Do we have a test for this? How do we unit-test UI components?
>>
>
> This would be nice to have. Building proper tests is not so easy, this
could
> be very long to setup, since you need to test
in several browsers and
you
> need full AJAX interaction. I am not used to
such automated testing, but
I
> am not sure the investment is worse the
improvement we could get from
them.
It's always worth it.
Note that the hard part is getting started with it. Once you have your
first test, it's usually very easy to add a second test afterwards and it
doesn't take long.
Thanks
-Vincent
at the
project level. We do need absolutely automated tests written for
everything that gets committed to ensure the quality of XWiki releases.
new
strategy for testing "XWiki UI Components".
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
> On the other side, I use livetables JS heavily, so you could be assured
that
> my fixes/improvements are either well tested
or will be fixed ASAP since
all
changes I
introduce is already in production.
While this is good enough for you as an individual we cannot rely on this
> We also usually test them on
> all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4
> (Mac) and Chrome (Mac)
> FYI, I found this one when we have introduced the usage of hashes to
provide
> "Back to the list" links. I will
soon commit an improvement supporting
the
> page size in hash as well, so you can really
get very precise "back to
the
list" return links.
Denis
So you could either write a functional tests using ui-tests or define a
IMO you should start with livetable tests in ui-tests.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:05 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On May 21, 2010, at 1:29 PM, Denis Gervalle wrote:
On Fri, May 21, 2010 at 12:05, Vincent Massol
<vincent(a)massol.net> wrote:
This is already done Denis, you can check it out in selenium-tests. There's no test
specific for the livetable but there are tests for AllDocs (for example) which test some
basic features of the livetable.
So what is needed:
1) extract the livetable test part to ui-tests since that's the new architecture for
new tests
2) add new livetable tests
On May 21, 2010, at 12:04 PM, Vincent Massol wrote:
Fine, so I let you write all the tests for the initial and basic live table
functionalities, and once these are available, I will complete them to test
the new features I have recently added ;) Hi Denis,
On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
> On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
>>
>>> Author: dgervalle
>>> Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
>>> New Revision: 28950
>>>
>>> Modified:
>>>
>>
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
>>> Log:
>>> XWIKI-5212 - Livetable filter serialization does not properly support
>> multi-valued form elements
>>> Merge from trunk r28947
>>
>> Do we have a test for this? How do we unit-test UI components?
>>
>
> This would be nice to have. Building proper tests is not so easy, this
could
> be very long to setup, since you need to test
in several browsers and
you
> need full AJAX interaction. I am not used to
such automated testing, but
I
> am not sure the investment is worse the
improvement we could get from
them.
It's always worth it.
Note that the hard part is getting started with it. Once you have your
first test, it's usually very easy to add a second test afterwards and it
doesn't take long.
So, just to be serious, I completely agree with you
regarding the advantage
of automated tests. But my current feeling about XWiki and its current UI is
that we are not moving fast enough compare to the competition. As well as
there is great components (ie new rendering), there are on the other side a
really bad/complex/tricky/not working UIs compare to similar products. If I
want to be able to continue my contribution on the project (and I d'like
to), I have to concentrate on improving the end user experience first, and
gets new clients paying for my work.
So I am sorry if I cannot currently meet your quality expectations, I just
hope that my intensive usage and testing already helps improving the product
quality, since this is the best I can do right now.
IMO people should not be a committer because they're using XWiki for their projects.
They could just be a contributor for that. A committer goes beyond this. You become a
committer when you're interested in the product on the long term and to make it good
and stable.
We've been trying to improve the quality of our software and I've noticed a trend
lately that goes in the other direction, especially for UI-related things. This has
resulted in several UI things broken in recent releases that we discovered too late. Note
that Marius is doing a great job in writing automated tests whenever he makes changes to
the WYSIWYG editor and that's great.
Note that this is not directed just at you but at all of us (me included). I'd like
that when someone commits something without a test that could be written relatively easily
then other committers should ask that person to add tests, in an effort to improve our
global quality.
I understand you're busy but since you've been doing several modifications to the
livetable already and are planning to continue making improvements to it, it would be
great if you could manage your time to find some time to start a test suite for the
livetable at some point (when you find some free time). At the same time that'll allow
you to discover how we write functional tests, which is a must know for all XWiki
committers IMO.
Thanks
-Vincent
PS: Just so my message is not understood wrongly: I really love the work you've been
doing so far since you joined XWiki as a committer. It's great and it's helping
the project a lot and I thank you for this. I'm just trying to get us all to the next
step which is to control our quality on the UI side (on the java side, it's almost a
practice that is always followed).
PPS: I'm talking for myself here and not representing the dev community. I'm
curious to see if other devs agree with what I've said or not.
>>> On the other side, I use livetables JS
heavily, so you could be assured
> that
>>> my fixes/improvements are either well tested or will be fixed ASAP since
> all
>>> changes I introduce is already in production.
>>
>> While this is good enough for you as an individual we cannot rely on this
> at the project level. We do need absolutely automated tests written for
> everything that gets committed to ensure the quality of XWiki releases.
>>
>>> We also usually test them on
>>> all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4
>>> (Mac) and Chrome (Mac)
>>> FYI, I found this one when we have introduced the usage of hashes to
> provide
>>> "Back to the list" links. I will soon commit an improvement
supporting
> the
>>> page size in hash as well, so you can really get very precise "back to
> the
>>> list" return links.
>>>
>>> Denis
>>
>> So you could either write a functional tests using ui-tests or define a
> new strategy for testing "XWiki UI Components".
>>
>> IMO you should start with livetable tests in ui-tests.
>>
>> Thanks
>> -Vincent
3:44 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On Fri, May 21, 2010 at 14:05, Vincent Massol <vincent(a)massol.net> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On May 21, 2010, at 1:29 PM, Denis Gervalle wrote:
table
I know that, but there is a large difference between testing a working
AllDocs document, and testing all functionalities of the livetable. It would
require writing some intelligent sample, using all kind of filter, column
type and so on...
On Fri, May 21, 2010 at 12:05, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On May 21, 2010, at 12:04 PM, Vincent Massol wrote:
>
>> Hi Denis,
>>
>> On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
>>
>>> On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net>
> wrote:
>>>
>>>>
>>>> On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
>>>>
>>>>> Author: dgervalle
>>>>> Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
>>>>> New Revision: 28950
>>>>>
>>>>> Modified:
>>>>>
>>>>
>
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
>>>>> Log:
>>>>> XWIKI-5212 - Livetable filter serialization does not properly
support
>>>> multi-valued form elements
>>>>> Merge from trunk r28947
>>>>
>>>> Do we have a test for this? How do we unit-test UI components?
>>>>
>>>
>>> This would be nice to have. Building proper tests is not so easy, this
> could
>>> be very long to setup, since you need to test in several browsers and
> you
>>> need full AJAX interaction. I am not used to such automated testing,
but
> I
>>> am not sure the investment is worse the improvement we could get from
> them.
>>
>> It's always worth it.
>
> Note that the hard part is getting started with it. Once you have your
> first test, it's usually very easy to add a second test afterwards and
it
doesn't take long.
Fine, so I let you write all the tests for the initial and basic live functionalities, and once these are available, I
will complete them to
test
the new features I have recently added ;)
This is already done Denis, you can check it out in selenium-tests. There's
no test specific for the livetable but there are tests for AllDocs (for
example) which test some basic features of the livetable.
So what is needed:
1) extract the livetable test part to ui-tests since that's the new
architecture for new tests
2) add new livetable tests
I completely agree with you, and I am not only _using_ XWiki, but also
improving it as much as can. When I say "usage" here, I am just saying that
I do not just develop improvement, but I do use it on production platform,
which ensure I will have a lot of chance to receive any negative feedback on
my side before XWiki release is done. This also means that I am really
confident on the changes I am introducing.
Since I am doing so since 0.9, I imagine that I do so on the long term !
What has changes since I am commiter is that I am now able to share what I
have already done, and also extend or think about what I need for my
customer from a more generic PoV and therefore improve the product on a
larger scale. I d'love to see XWiki more good and stable, and especially
more spread.
So, just to be serious, I completely agree with
you regarding the
advantage
of automated tests. But my current feeling about
XWiki and its current UI
is
that we are not moving fast enough compare to the
competition. As well as
there is great components (ie new rendering), there are on the other side
a
really bad/complex/tricky/not working UIs compare
to similar products. If
I
want to be able to continue my contribution on
the project (and I d'like
to), I have to concentrate on improving the end user experience first,
and
gets new clients paying for my work.
So I am sorry if I cannot currently meet your quality expectations, I
just
hope that my intensive usage and testing already
helps improving the
product
quality, since this is the best I can do right
now.
IMO people should not be a committer because they're using XWiki for their
projects. They could just be a contributor for that. A committer goes beyond
this. You become a committer when you're interested in the product on the
long term and to make it good and stable.
We've been trying to improve the quality of our
software and I've noticed a
trend lately that goes in the other direction, especially for UI-related
things. This has resulted in several UI things broken in recent releases
that we discovered too late. Note that Marius is doing a great job in
writing automated tests whenever he makes changes to the WYSIWYG editor and
that's great.
I also agree, and you (with others, and myself, I hope) do a great job for
improving the quality and architecture of the project. And we also agree
that the UI has not been taken enough attention. What I try to say is that
it is urgent to first improve it to increase our "market share" in the short
terms, since we are not alone on this market, and we need to impose us, not
only to technicians but also to end users. Having feature like "forgot
password" broken, having a blog application that is not fully working (yes,
this is my feeling), having complex rights management, still having
complexity and issues in languages management, and a WYSIWYG editor that
does not allow simple left/center/right alignement, etc... currently impact
my ability to convince our customers to adopt XWiki. And you know how it is,
if I cannot pay myself, I will have to work on something else, something I
really want to avoid, since I really like working for XWiki.
Note that this is not directed just at you but at all of us (me included).
I'd like that when someone commits something
without a test that could be
written relatively easily then other committers should ask that person to
add tests, in an effort to improve our global quality.
Well, there also I agree with you. But, I would still prefer someone to
commit a fix without test, then leaving the issue open. The current thread
is about a fix on an issue that is there since the new
hash functionality has been introduced in the livetable. If there were a
test for that functionality, I would have update it. But there is even no
test for anything in livetable currently. The improvement I have added
recently to livetable has also suffer of the same situation. But, choosing
between not having them at all, or having them without test, but being
careful on it, I have choose the second option, and I have proposed them to
votes ! That was the time to disagree on functionality if you really think
missing test is worse a -1.
I understand you're busy but since you've been doing several modifications
to the livetable already and are planning to continue
making improvements to
it, it would be great if you could manage your time to find some time to
start a test suite for the livetable at some point (when you find some free
time). At the same time that'll allow you to discover how we write
functional tests, which is a must know for all XWiki committers IMO.
I would be pleased to do so as soon I have time for that. I even agree that
I am a good candidate to do so. But I am currenlty working on improving the
Blog Application, since it is currently almost useless for us and I suppose
others, since my improvement are absolutely generic, and aims to allow more
autonomous blogs. I expect to also share these improvements. Once again, you
will say, hey Denis, the testing of the application is poor, you should
improve it... but you should have request them from the first writer ! If I
were rewritting the whole application from scratch, I will understand that
missing test is blocking, but I do not agree, when I make small improvements
only.
So I am again sorry not being able to reach your expectation right now, but
I really feel the needs to fix what will helps me increase sales, and I do
it while taking care of keeping good quality and making improvement generic
enough to be redistributed. Once I get to the point that what exists is
working properly enough and have a good usability allowing the sales to
market the product properly, I will be more than happy to increase the
amount of automated testing.
In the meantime, I commit to maintain existing tests, and improve them when
it is trivial to do so. I hope you better understand my opinion here. This
is not laziness but more a matter of priority.
Thanks
-Vincent
PS: Just so my message is not understood wrongly: I really love the work
you've been doing so far since you joined XWiki as a committer. It's great
and it's helping the project a lot and I thank you for this. I'm just trying
to get us all to the next step which is to control our quality on the UI
side (on the java side, it's almost a practice that is always followed).
This is probably where I do not fully agree with you. The automated quality
control of the UI side is not the _next_ step for me, this is a _future_
step, but I feel we have more immediate steps to stabilize features or have
them improved to the current level of the competition. We are not Google, we
do not have their work force and this is why I sometime feel that you exceed
on quality control, while at the same time there is really and sometime well
know place that need immediate and quick improvement, event dirty fix, just
to make the product usable. And do not change anything, you should continue
to insist on QC, but I think you should also be more pragmatic at time.
PPS: I'm talking for myself here and not representing the dev community. I'm
curious to see if other devs agree with what I've
said or not.
As we all do, and I am also curious to know what others have to say on our
discussion.
>>> On the other side, I use livetables
JS heavily, so you could be
assured
> that
>>> my fixes/improvements are either well tested or will be fixed ASAP
since
> all
>>> changes I introduce is already in production.
>>
>> While this is good enough for you as an individual we cannot rely on
this
> at the project level. We do need absolutely
automated tests written for
> everything that gets committed to ensure the quality of XWiki releases.
>>
>>> We also usually test them on
>>> all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac),
Safari4
>>> (Mac) and Chrome (Mac)
>>> FYI, I found this one when we have introduced the usage of hashes to
> provide
>>> "Back to the list" links. I will soon commit an improvement
supporting
> the
>>> page size in hash as well, so you can really get very precise "back to
> the
>>> list" return links.
>>>
>>> Denis
>>
>> So you could either write a functional tests using ui-tests or define a
> new strategy for testing "XWiki UI Components".
>>
>> IMO you should start with livetable tests in ui-tests.
>>
>> Thanks
>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 May
22 May
4:34 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
Hi Denis,
On 05/21/2010 04:44 PM, Denis Gervalle wrote:
[snip]
a WYSIWYG editor that does not allow simple
left/center/right alignment
Some of the WYSIWYG editor features (including text alignment) are not
enabled by default in the standard XWiki Enterprise distribution. All
features are listed on
http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor .
[snip]
As we all do, and I am also curious to know what
others have to say on our
discussion.
I agree with Vincent when he says that the most difficult part is
setting up the test environment and the test framework. Writing tests
afterwards is easy and gives me a lot of confidence. Thus I think we
should focus on what is the best way to test each part of XWiki rather
than on arguing if making a feature available to the user early is
better than waiting till we have enough tests to be confident that that
feature meets a desired level of quality.
Denis, regarding testing live table features that are not present
anywhere in XE's documents, you can use the test setup to insert a
custom live table in a wiki page. For the WYSIWYG editor we enable all
the editing features during test setup to be able to test them all
(including alignment ;) ). For specific interactions that are not used
yet on XE but only on client projects we insert the editor in a wiki
page with custom configuration.
Thanks,
Marius
6:53 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On Sat, May 22, 2010 at 16:34, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Hi Denis,
On 05/21/2010 04:44 PM, Denis Gervalle wrote:
[snip]
Nice to know, I was not aware of that, since I have not use the editor much
myself since my browser is not officially supported.
But, could you explains why text alignement is not enable in XE, this seems
too me basic requirement for any user, so why hiding it ?
I will be able to enable it, but I may imagine not all XE administrator will
find it so easy.
a WYSIWYG editor that does not allow simple
left/center/right alignment
Some of the WYSIWYG editor features (including text alignment) are not
enabled by default in the standard XWiki Enterprise distribution. All
features are listed on
http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor .
[snip]
This is why I currently does not have provide test for the livetable.
As we all do, and I am also curious to know what
others have to say on
our
discussion.
I agree with Vincent when he says that the most difficult part is
setting up the test environment and the test framework. Writing tests
afterwards is easy and gives me a lot of confidence.
Thus I think we
Yes, this would be nice to have.
should focus on what is the best way to test each part
of XWiki rather
than on arguing if making a feature available to the user early is
better than waiting till we have enough tests to be confident that that
feature meets a desired level of quality.
I agree, but we should also agree on our quality requirement. On this, it
seems Vincent has a higher requirement level then I have.
Denis, regarding testing live table features that are
not present
anywhere in XE's documents, you can use the test setup to insert a
custom live table in a wiki page. For the WYSIWYG editor we enable all
the editing features during test setup to be able to test them all
(including alignment ;) ). For specific interactions that are not used
yet on XE but only on client projects we insert the editor in a wiki
page with custom configuration.
I am currently far from thinking about detaikls of tests setup, but I know
there are some solutions. What I have just said is that for proper testing,
we also need to be able to test all supported browser, else we will miss the
most common problem of UI testing which is browser incompatibilities.
Denis
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
10:04 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On 05/22/2010 07:53 PM, Denis Gervalle wrote:
On Sat, May 22, 2010 at 16:34, Marius Dumitru
Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
Hi Denis,
On 05/21/2010 04:44 PM, Denis Gervalle wrote:
[snip]
Nice to know, I was not aware of that, since I have not use the editor much
myself since my browser is not officially supported. a WYSIWYG editor that does not allow simple
left/center/right alignment
Some of the WYSIWYG editor features (including text alignment) are not
enabled by default in the standard XWiki Enterprise distribution. All
features are listed on
http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor .
But, could you explains why text alignement is not
enable in XE, this seems
too me basic requirement for any user, so why hiding it ?
I think the reason for disabling such features by default in XE is that
the formatting options they expose are most of the time not
web-friendly. Besides that, we encourage wiki users to focus more on the
content and less on the text formatting. Using multiple fonts (some of
which weren't made for the web but for print), text alignments and
colors on the same wiki page makes its content hard to read and breaks
the L&F consistency. This is also one of the reasons for having the
option to remove all the styles when importing office content.
This is just my opinion. We had a discussion at some point but I don't
remember the rest of the arguments. We can (re)discuss this in a
different thread.
I will be able to enable it, but I may imagine not all
XE administrator will
find it so easy.
I agree. Sadly, we are currently running the functional tests only on
FF3.5. What's worse it that most of the WYSIWYG editor Selenium tests
(and maybe others) won't run in IE even if we setup a dedicated build
agent for this because these tests use browser specific JavaScript code
that doesn't work in IE (e.g. code to place the caret at a given
position in the rich text area during a test).
Thanks,
Marius
[snip]
This is why I currently does not have provide test for the livetable.
As we all do, and I am also curious to know what
others have to say on
our
discussion.
I agree with Vincent when he says that the most difficult part is
setting up the test environment and the test framework. Writing tests
afterwards is easy and gives me a lot of
confidence. Thus I think we
Yes, this would be nice to have.
should focus on what is the best way to test each
part of XWiki rather
than on arguing if making a feature available to the user early is
better than waiting till we have enough tests to be confident that that
feature meets a desired level of quality.
I agree, but we should also agree on our quality requirement. On this, it
seems Vincent has a higher requirement level then I have.
Denis, regarding testing live table features that
are not present
anywhere in XE's documents, you can use the test setup to insert a
custom live table in a wiki page. For the WYSIWYG editor we enable all
the editing features during test setup to be able to test them all
(including alignment ;) ). For specific interactions that are not used
yet on XE but only on client projects we insert the editor in a wiki
page with custom configuration.
I am currently far from thinking about detaikls of tests setup, but I know
there are some solutions. What I have just said is that for proper testing,
we also need to be able to test all supported browser, else we will miss the
most common problem of UI testing which is browser incompatibilities.
Denis
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5328
days inactive
5330
days old
9 comments
3 participants
participants (3)
-
Denis Gervalle -
Marius Dumitru Florea -
Vincent Massol