Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of hlship@gmail.com designates
 64.233.184.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=CGWW+W5ShBRFwjIS+PzeqfDerorDqbaXQeb/e6XbrqLOuGUR7yb0LRt2Uu67ZKb8m7LeNsQSdDZLQjwz4DscNd4Ild2aFccx5/51rmQwMmLWbGCfbwWfn6djhC059p0IuLIY8EHFrPBxhv4qeXf7znPvbhbirt6SITNclvIKNsw=
Message-ID: <ecd0e33105021109242878c8c6@mail.gmail.com>
Date: Fri, 11 Feb 2005 12:24:48 -0500
From: Howard Lewis Ship <hlship@gmail.com>
Reply-To: Howard Lewis Ship <hlship@gmail.com>
To: Tapestry development <tapestry-dev@jakarta.apache.org>
Subject: Re: html template comments
In-Reply-To: <6b281439390d5f5960d8650411a4567c@ehatchersolutions.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <006201c51054$ab8b0840$8f688f80@darden.virginia.edu>
	 <ecd0e33105021108176f187d66@mail.gmail.com>
	 <6b281439390d5f5960d8650411a4567c@ehatchersolutions.com>

Yes; because of HiveMind 1.1, you can contribute your own
implementation of the ITemplateParser service into the
tapestry.parse.TemplateParser service point.  In other words, you can
override the default implementation easily, with either a whole-cloth
replacement, or a customized subclass.

I still don't know about servlet filters as being the ultimate
panacea... re-parsing the HTML, however well-formed, after the fact is
just less efficient than getting the right HTML generated in the first
place.  It may also affect performance ... often, a Tapestry page will
be able to send down the size header in the response, allowing the
client web browser to keep the connection open when fetching images
(HTTP 1.1 stuff).  That may be a performance boost. A servlet filter
may not be able to do that (short of reading the entire page into an
in-memory buffer), which is one more stage and one more large block of
temporary memory allocated.

My concern is probably just Premature Optimization though.


On Fri, 11 Feb 2005 11:43:16 -0500, Erik Hatcher
<erik@ehatchersolutions.com> wrote:
> 
> On Feb 11, 2005, at 11:17 AM, Howard Lewis Ship wrote:
> > Perhaps ... we could change the Tapestry template parser to strip out
> > comments by default, and add meta data to allow comments to be kept?
> > Or perhaps keep comments by default (todays behavior) and add
> > org.apache.tapestry.strip-comments to get rid of them?
> 
> I'm not sure it is appropriate for Tapestry to do too much with the
> templates.  It is easy enough to add a servlet filter that can strip
> comments, squeeze whitespace, etc.  Keeping Tapestry focused on the
> "aspect" of parsing for components seems wise.
> 
> However, a pluggable/extendable template parser sounds like a great
> idea for flexibility.  Is this possible in 3.1 now?
> 
>         Erik
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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