RE: Re[2]: Whitespace, redux

[Kevin Baynes <kb...@seagullsw.com>]

I really like the pluggable preprocessor idea. It's flexible and backwards
compatible. Whitespace handling becomes a matter of choice.

An intriguing part is the ability to write preprocessors that can mimic
other widely used syntaxes: JSP, ASP, ColdFusion, PHP, etc.

If a company has designers that have been working in one of the other
syntaxes it would shorten the learning curve... Velocity would feel natural
because it could mimic their current working environment. Like skins, or
plug-ins.

Then the core can stay clean and simple, but is extensible. Think there
really should be an #output("on/off") directive? Fine, write it into your
preprocessor.


-------------------------------
Kevin Baynes
Software Engineer
SEAGULL Software
kbaynes at seagullsw dot com



> -----Original Message-----
> From: Daniel Dekany [mailto:ddekany@freemail.hu]
> Sent: Friday, April 19, 2002 1:45 PM
> To: Velocity Users List
> Subject: Re[2]: Whitespace, redux
>
>
> Friday, April 19, 2002, 5:44:47 PM, Christoph Reck wrote:
>
> > "Geir Magnusson Jr." wrote:
> >>
> >> On 4/19/02 11:05 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> >> > No, I would really hate those flags. In my proposal vm calls was NOT
> >> > directives, so read the ENBF with Directive+ as such. BTW I have
> >> > changed my mind. What about that the only think that gobbles
> >> > whitespace is: #if, #else, #elsif, #end, #set, #foreach,
> #stop, #macro
> >> > and comments (note that I have omitted #include and #parse).
> >> > Everything else prevents whitespace gobbling in its line. So instead
> >> > of Directive+ I say WhiteSpaceGobbler+.
> >
> > With flags i meant something within the AST nodes for the directives,
> > which you will just the same need if you want to mark the above
> > list as gobbling...
>
> You know the list of whitespace gobbler directives on compile time so
> it is really simple. What would be complicated, say, if we have a
> mechanism to flag user defined vm-s (gobble whitesapce or not to) or
> if we allow users to specify which directive gobbles whitespace but
> this is not the case here.
>
> >>
> >> Doesn't this just keep the problem but move it around a bit?
>
> As we know there is no ultimate solution even if we assume that we
> have HTML templates only (which is not the case). I only say that it
> is far better than the current rule, and also it is IMO somewhat
> better than the rule with "Directive". But read on...
>
> > So it seems to me.
> >
> > How do you avoid leading whitespaces from indented comments?
>
> If you look into the list of whitespace gobblers (WhiteSpaceGobbler+)
> then "comments" are there. But read on...
>
> > This is why I wanted it to be "Directive" without that "+", which
> [snip >:)]
>
> This debate just does not worth the bandwidth/time (I think many
> subscriber will agree). As I'm responsible for this cascade (again...)
> I would like to stop it here. So let it be "Directive" if you like it.
> This is somewhat matter of taste.
>
> Instead, IMO it would better to concentrate on the other subthread
> (OK, that was started by me too... sorry): No whitespace gobbling in
> the core, and add pluggable template preprocessors. No backward
> compatibility problems, no pollution of the core by application
> specific behavior (and miss-design... /-:), allows application/taste
> specific whitespace gobbling, and adds other functionality eg.:
> override default encoding (chatset) based on the content (<?xml ...
> encoding="..."?>), allows JSP-tag-like syntax, allows application
> specific escaping rules (IF we ever add #echo and allow #echo-ing
> non-visual characters...), etc.
>
> So if we would agree in it (no w.s. gobbling etc) then we could look
> into the pluggabe preprocessor proposal, and then everybody can use
> his/her favorite whitespace eater method. OK, a "standard"
> preprocessor for HTML/XML is still needed, and then let it be the
> Christoph Reck whitespace gobbler then, and implement that as a
> preprocessor. Anybody disagree with the Christoph Reck whitespace
> gobbler?
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Error Handling

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/15/02 7:09 AM, "Emyr James" <em...@OrbisUK.com> wrote:

> Dear all,
> I'm writing a servlet application using velocity under tomcat. At the moment
> I'm
> doing something like this...
> 
> public class MyServlet extends VelocityServlet {
>   public Template handleRequest( HttpServletRequest request,
> HttpServletResponse
> response, Context context ){
> Template template=null;
> try {
>   //stuff that may throw an error
> } catch( Exception e ) {
>  context.put("error",e.toString());
>  try {
>   template=getTemplate("error.vm");
>  } catch( Exception ee ) {
>   ee.printStackTrace();
>   System.exit(0);
>  }
> }
> return template;
> 
> I want to make this complete by changing the System.exit(0) stuff to send
> stuff
> back on the servlets output stream directly, circumventing velocity entirely.
> How can I get access to this stuff so that the servlet behaves like a typical
> servlet under certain circumstances.

That's easy :   just use the request/response objects as normal, and return
null.

When the baseclass sees the 'null' returned, it assumes you took care of the
request, and does nothing else.

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Error Handling

[Emyr James <em...@OrbisUK.com>]

Dear all,
I'm writing a servlet application using velocity under tomcat. At the moment I'm
doing something like this...

public class MyServlet extends VelocityServlet {
    public Template handleRequest( HttpServletRequest request, HttpServletResponse
response, Context context ){
  Template template=null;
  try {
    //stuff that may throw an error
  } catch( Exception e ) {
   context.put("error",e.toString());
   try {
    template=getTemplate("error.vm");
   } catch( Exception ee ) {
    ee.printStackTrace();
    System.exit(0);
   }
  }
  return template;

I want to make this complete by changing the System.exit(0) stuff to send stuff
back on the servlets output stream directly, circumventing velocity entirely.
How can I get access to this stuff so that the servlet behaves like a typical
servlet under certain circumstances.

Cheers,
Emyr



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>