Code Finder seems not to work on HTML Filter for attributes
Original [issue 276](https://code.google.com/p/okapi/issues/detail?id=276) created by @ysavourel on 2012-09-27T02:44:22.000Z:
code finder expressions working on element content seems to have no effect on attribute values in HTML Filter.
Comments (9)
-
Account Deleted -
Account Deleted Comment [2.](https://code.google.com/p/okapi/issues/detail?id=276#c2) originally posted by @ysavourel on 2012-09-27T18:31:25.000Z:
Hum, attributes should be extracted as individual TextUnits - so code finder should be working on those too. But that means the attribute would have to be specified as translatable/localizaible to be extracted.
-
Account Deleted Comment [3.](https://code.google.com/p/okapi/issues/detail?id=276#c3) originally posted by @ysavourel on 2012-10-01T14:47:06.000Z:
I've tested on this:
<p>text VAR1 <img src='abc.png' alt="text VAR2 alt"> text</p>
with this code finder rule (in addition to the normal HTML rules):
useCodeFinder: true codeFinderRules: "\#v1
ncount.i=1
nrule0=
bVAR
d
b"and, indeed, the element content VAR1 is seen as in-line code, but while the value of alt is correctly extracted, VAR2 is not set as in-line code.
I'll look at it more. It's probably a call we don't do for attributes. -ys
-
Account Deleted Comment [4.](https://code.google.com/p/okapi/issues/detail?id=276#c4) originally posted by @ysavourel on 2012-10-01T17:26:39.000Z:
It seems EventBuilder.embeddedTextUnit() called in processAllEmbedded() is not applying the code-finder to the extracted text.
I'm guessing postProcessTextUnit() should be called in processAllEmbedded() or embeddedTextUnit().
Jim: I can try to make the fix, but you may want to confirm it's the wat to do it. I'll wait to hear back from you. No rush.
-
Account Deleted Comment [5.](https://code.google.com/p/okapi/issues/detail?id=276#c5) originally posted by @ysavourel on 2012-10-01T17:50:21.000Z:
I'll put it on my list to check - but you are probably right - just a matter of adding the callback. Though could be some trickiness.
Jim
-
Account Deleted Comment [6.](https://code.google.com/p/okapi/issues/detail?id=276#c6) originally posted by @ysavourel on 2012-10-01T18:22:06.000Z:
postProcessTextUnit() is already called in endTextUnit - which theoretically should cover all cases. But it seems I hard code TU creation in some cases by-passing the EventBuilder API's.
A quick workaround should be to add postProcessTextUnit to embeddedTextUnit - that should cover the remaining cases. We'll just need to be careful in the future so this is not called twice if we end up creating the textunit with startTU and endTu
Jim
-
Account Deleted Comment [7.](https://code.google.com/p/okapi/issues/detail?id=276#c7) originally posted by @ysavourel on 2012-10-01T19:14:29.000Z:
OK. I'll work on the change. and make sure to have a unit test for it. Thanks.
-
Account Deleted - changed status to resolved
Comment [8.](https://code.google.com/p/okapi/issues/detail?id=276#c8) originally posted by @ysavourel on 2012-10-01T19:32:39.000Z:
Done. I've added a unit test too. Should be in my next push.
-
Account Deleted Comment [9.](https://code.google.com/p/okapi/issues/detail?id=276#c9) originally posted by @ysavourel on 2012-10-01T20:28:09.000Z:
This issue was closed by revision 51a41b25fc25.
- Log in to comment
Comment [1.](https://code.google.com/p/okapi/issues/detail?id=276#c1) originally posted by @ysavourel on 2012-09-27T05:50:14.000Z:
It seems we don't call AbstractMarkerEventBuilder.postProcessTextUnit() for attributes. Jim: I'll try to look where translatable attribute create their text unit and fix this.