Fluent API Redesign

[GoogleCodeExporter]

The API is a little bit "clumpsy".

Just compare this:

assertConstraints(issues.errorsOnly().inLine(1).under(Modul.class, 
"bla").named("x").oneOfThemContains("Anzeigename"));

to:

assertHas(issues.inLine(1).under(Modul.class, 
"bla").for("x").errorContaining("Anzeigename"));

*Has to be rewritten in English*

Hier jetzt die Punkte, die mir aufgefallen sind:

1) theOneAndOnlyContains kann eigentlich weg, weil ja eh ein Fehler kommt, wenn 
es am Ende unassertete Issues gibt. 
2) oneOfThemContains Der Name ist irreführend. Der Code macht, was  
anyOfThemContains heißen müsste
3) allOfThemContain auch über, weil wenn bei warnings/errorsContaining(..) 
einer überbleibt gibts einen Fehler
4) sizeIs Klingt als bräuchten wir das auch nicht mehr. Man kann ja dann auch 
Assert.isEqual(issues.size(), 3) schreiben.
5) named, forType und forElement könnte zu for zusammengefasst werden. Muss ja 
für ein Element sein. named könnte auch bedeuten, dass das issue einen Namen 
hat.
6) under könnte noch einen Overload für nur name gebrauchen

Aktuell schreibt man auch eher nicht dran, ob es eine Warnung oder ein Fehler 
ist. Mit  errorsOnly  und dem von mir hinzugefügten warningsOnly ging das zwar 
schon, liest sich aber noch ein bisschen holprig.

Vorschlag für ein neues Set an Methoden: (neu, weg)

-forType(Class<? extends EObject>)-
inLine(int)
withStringFeatureValue(String, String)
except(Set<Issue>)
errorsOnly()
warningsOnly()
withSeverity(Severity...)
-named(String)-
-forElement(Class<? extends EObject>, String)-
for(Class<? extends EObject>)
for(String)
for(Class<? extends EObject, String)
under(Class<? extends EObject>)
under(String)
under(Class<? extends EObject>, String)
-sizeIs(int)-
-oneOfThemContains(String)-
warningContaining(string substring)
errorContaining(string substring)
-nOfThemContain(int, String)-
warningsContaining(int n, string substring)
errorsContaining(int n, string substring)
-allOfThemContain(String)-
-theOneAndOnlyContains(String)-

Wenn dann alle Methoden wie Filter klingen, passt assertHas besser als 
assertConstraints.

assertHas(issues.warningContaining("Bla"));

....

Original issue reported on code.google.com by lcorneliussen@googlemail.com on 28 Jul 2011 at 8:09

[GoogleCodeExporter]

My understanding of German is not great, so I hope this is not a copy of what 
has been said, but if there will be a redisign of the FluentIssueCollection, I 
would like to input an addition.

Since an issue code is less variable then the message, it would be useful to 
add a filter for this as well. Something along these lines could be added to 
the code:

public FluentIssueCollection withCode( String code ) {
    FluentIssueCollection res = new FluentIssueCollection(resource, messages);
    for (Issue i: issues) {
        if ( i.getCode().equals(code)) {
            res.addIssue( i );
        }
    }
    if (res.getIssueCount() == 0 ) {
        res.addMessage("no issues found with code '"+code+"'");
    }
    return res;
}

Original comment by edwin.va...@gmail.com on 6 Sep 2011 at 3:18

[GoogleCodeExporter]

The suggestion makes sense, opened issue#11 for it.
This issue is about general redesign.

Original comment by karsten....@googlemail.com on 26 Apr 2012 at 9:29

[GoogleCodeExporter]

Original comment by karsten....@googlemail.com on 26 Apr 2012 at 9:30

• Added labels: Component-unittesting
• Removed labels: Subproject-Xtext-Utils