Code Finder seems not to work on HTML Filter for attributes

[Former user]

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.

[Former user]

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.

[Former user]

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.

[Former user]

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

[Former user]

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.

[Former user]

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

[Former user]

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

[Former user]

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.

[Former user]

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.

[Former user]

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.