> Date: Mon, 15 Sep 2003 22:57:32 -0700
> From: Eric Carmichael <[EMAIL PROTECTED]>
> Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
> X-Originating-IP: [64.203.49.21]
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> X-Priority: 3
> X-MSMail-priority: Normal
> X-Originating-Email: [EMAIL PROTECTED]
> X-OriginalArrivalTime: 16 Sep 2003 05:57:41.0966 (UTC)
FILETIME=[7112DEE0:01C37C17]
>
> > 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.
>
I think keeping an array (in the Template node) of the source line that
corresponds to each of the Java line we generate is probably enough. I'll
commit some codes today and you'll see what I mean.
There are reasons for not doing SMAP generation in Generator. Generator is
already the biggest module in Jasper, and I'd like not to make it any more
complicated. Also, some codes are generated out of order, in buffers that
got appended at the end of generating the main method, so that the mappings
cannot be determined when codes are generated.
SMAP generation is one of the area that does not got enough test and use.
You seem to be one of the few who actually look at it. Are you doing anything
with it?
-Kin-man
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
