On Fri, Oct 1, 2021 at 5:36 AM Ben Weidig <b...@netzgut.net> wrote: > Hi, >
Hi! > Because the String->JSONArray CoercionTuple added in tapestry-json is the > root of the problem in TAP5-2688. > Without including tapestry-json, everything's fine. > That's why the coercion tests in tapestry-core didn't reveal the problem, > and the tapestry-json tests didn't include the special-case. > So couldn't we have the test in tapestry-json but the coercion in commons? > Well, I think that's how it's doing it right now, but it ignores "exact" > matches if a "good enough" is found earlier. > Great catch! We should definitely favor exact matches when they're available. My patch prefers targetType matches over just "isAssignable", and is trying > to find one regardless of the intermediate steps. > Maybe going deeper for lookups isn't necessary. > But checking all the available tuples at the current level to find a > targetType match and not just the first "isAssignableFrom". > Agreed. > That, of course, leads to the problem of detecting the number of steps in > compound coercions. > Right now, I don't see a way to see how many intermediate coercions are > involved. > But it could be added to Coercion, with the default being "1", and > CompoundCoercion to actually calculate it. > Good idea. > Or a coercion tuple could be marked as "exact target types only". > So JSONArray won't match for Collection. > I'd implement this only if preferring exact matches doesn't work. > Looks like I have to investigate further and write more tests, but I think > I'm on the right track to improve coercions. > I agree. Keep up the good work! > > > > > > > > > > What do you think? > > > > > > Cheers, > > > Ben > > > > > > > > > -- > > Thiago > > > > > Cheers, > Ben > -- Thiago
