> But this also shows that tight coupling between Generator and SmapUtil is
> flagile and error prone. I think it would be a better design if we
> decouple these two modules somehow. We could create additional data
> structure that captures the mapping info for template texts, with
Generator
> its producer and SmapUtil its comsumer. What do you think? I'll
> think about this more.
I thought about this a bit when I was copying the line feed logic from
Generator.java to SmapUtil.java to fix the line mappings for template text
nodes, because I didn't like duplicating code, but I didn't see an
alternative except to move the SMAPping into Generator. How would your
producer/consumer approach differ from that? If a data structure that
captures mapping info is what's needed, we already have SmapStratum
performing that function, so I don't see much difference between having
Generator produce a new mapping info data structure and just having
Generator produce the SMAP directly.
> BTW, the reason for "if (textSize <= 3)" is for performance optimization.
> "out.write('\n')" should be faster than "out.write("\n")" so it's OK that
> you move into the "if (ctxt.getOptions().genStringAsCharArray())" block,
> for now; but it should really be applied in all cases. Maybe we can
> write all "out.write()"'s in a single line, so that the mapping is not
> changed? Or we can revisit this later.
Yeah, I didn't know if putting "if (textSize <= 3)" outside the "if
(ctxt.getOptions().genStringAsCharArray())" block was intentional or not,
which is why I was hesitant to commit my fix. Thanks for clarifying. I
don't have a problem changing the SMAPs as long as we don't break them, so
do whatever you think best on the Generator side, and I'll just try to make
sure to check for SMAP regressions before the next release.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
