Do not email me. Remove me from your mail list.

["www.cmttrading.com" <sa...@cmttrading.com>]

Do not email me. Remove me from your mail list.

IMPORTANT:
Please make sure to provide previous correspondences with www.cmttrading.com
so we may better assist you with your inquiries.

Be sure to check out our new Car Audio Superstore at www.gotcmt.com.

----- Original Message ----- 
From: "Kin-Man Chung" <Ki...@Eng.Sun.COM>
To: <to...@jakarta.apache.org>
Sent: Tuesday, September 16, 2003 10:34 AM
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties


>
> > Date: Mon, 15 Sep 2003 22:57:32 -0700
> > From: Eric Carmichael <ec...@alumni.rice.edu>
> > 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 <to...@jakarta.apache.org>
> > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> > X-Priority: 3
> > X-MSMail-priority: Normal
> > X-Originating-Email: [eric_carmichael@hotmail.com]
> > 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: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org