cvs commit: jakarta-turbine-tdk/src/examples WebMacro.properties

[jv...@apache.org]

jvanzyl     01/05/17 00:42:48

  Added:       src/examples WebMacro.properties
  Log:
  - adding this here. it will be integrated into the TDK.
  
  Revision  Changes    Path
  1.1                  jakarta-turbine-tdk/src/examples/WebMacro.properties
  
  Index: WebMacro.properties
  ===================================================================
  #
  # $Id: WebMacro.properties,v 1.1 2001/05/17 07:42:46 jvanzyl Exp $
  #
  # This is the configuration file for WebMacro.  It is picked up from
  # the location specified in TurbineResources.properties, in the key
  # services.WebMacroService.properties.
  #
  
  
  #
  # NOTE FOR NT USERS.
  #
  # Beware that the '\' character is the escape character in a Java
  # properties file.  You must either double it ('\\') or use the Unix
  # style (/) file separator in this file.  Both should work.  Also,
  # when you set TemplatePath, be sure and use the NT path separator (;)
  # rather than the Unix separator (:).
  #
  
  
  
  ###########################################################
  #
  # BASIC CONFIGURATION:
  #
  # You will probably have to change a few of these entries.
  #
  
  
  #
  # You should set TemplatePath, at the very least! It is a list of
  # directories which will be searched for your templates, if you give a
  # relative filename.  It is a list of directories separated by a : (on
  # Unix) or a ; (on NT).
  #
  #
  # IMPORTANT NOTE
  #
  # Template path is handled by Turbine; see
  # services.TurbineWebMacroService.templates entry in
  # /WEB-INF/Turbine.properties.  Therefore, DO NOT set this value here!
  #
  # TemplatePath = /home/webmacro
  #
  
  
  #
  # WebMacro compiles and caches templates for efficiency.  During
  # development you will want to turn this off by setting the following
  # value to 0, so that your template changes are immediately reflected
  # on the website.  In production systems, this it the number of
  # milliseconds of idle time that a cached template will be retained,
  # ie: 600000 is ten minutes (10 * 60 * 1000).
  #
  # TemplateExpireTime == 600000
  TemplateExpireTime = 0
  
  
  #
  # LogLevel can be: ALL, DEBUG, EXCEPTION, ERROR, WARNING, INFO, or
  # NONE, in order of most information to least information displayed.
  #
  LogLevel = EXCEPTION
  
  
  #
  # LogTraceExceptions causes exception stack traces to be included in
  # the log.  This causes exceptions to be verbose, but may point out the
  # exact line or method which is causing a fault.
  #
  LogTraceExceptions = TRUE
  
  
  #
  # Uncomment the following to log to a file rather than stderr.  If
  # your standard error writes to a useful log already, you don't need
  # this, but many servlet runners simply eat standard error.
  #
  LogFile = /home/logs/webmacro.log
  
  
  #
  # Set the template (relative to TemplateDirectory) used for errors.
  # You can edit this template to customize the way script failures
  # appear.
  #
  ErrorTemplate = error.wm
  
  
  
  ###########################################################
  #
  # ADVANCED CONFIGURATION
  #
  # Don't change these values unless you know what you're doing.  They
  # allow you to fine-tune, extend, and customize WebMacro's behavior.
  # A possible exception is the C-Blocks entry; it will be important to
  # set it to false if you want to put Javascript code in your
  # templates.
  #
  
  
  #
  # Allow C-Style blocks in WebMacro templates.  This means that you can
  # use '{' and '}' to delimit blocks in the template, instead of
  # "#begin" and "#end".  This is important if you have a set of legacy
  # 0.89 or earlier WebMacro templates and you need them to be
  # supported.  Otherwise, leave it off since the '{' and '}' characters
  # interfere with JavaScript.
  #
  C-Blocks = true
  
  
  #
  # ResourceProviders are pluggable modules that are used to load
  # important data and code.  You can create your own ResourceProviders
  # to add new modules to WebMacro, or replace existing modules.  They
  # are all implementations of org.webmacro.broker.ResourceProvider
  #
  #
  # IMPORTANT NOTE
  #
  # The template provider is handled by Turbine; see
  # service.TurbineWebMacroService.templates.provider entry in
  # Turbine.properties.
  #
  Providers = org.webmacro.resource.HandlerProvider \
              org.webmacro.resource.UrlProvider \
              org.webmacro.engine.DirectiveProvider \
              org.webmacro.engine.ParserProvider
  
  
  #
  # The DirectiveProvider uses this list to serve up directives to
  # parsers.  You can control what script directives WebMacro uses by
  # changing this list -- you could even add your own.  They are all
  # implementations of org.webmacro.engine.Directive.
  #
  Directives = org.webmacro.engine.IncludeDirective \
               org.webmacro.engine.ParseDirective \
               org.webmacro.engine.SetDirective \
               org.webmacro.engine.IfDirective \
               org.webmacro.engine.ElseDirective \
               org.webmacro.engine.UseDirective \
               org.webmacro.engine.ParamDirective \
               org.webmacro.engine.FilterDirective \
               org.webmacro.engine.ForeachDirective \
               org.webmacro.engine.LocalDirective \
               org.webmacro.engine.PropertyDirective \
               org.webmacro.engine.ToolDirective
  
  
  #
  # The following are tools which are added to your WebContext.  You can
  # customize your WebContext with special tools of your own by adding
  # them to this list of classes.  The only requirement is that the
  # class be public, and have a public default constructor.  The
  # instance will be shared betwen all instantiations of WebContext, so
  # beware of threading issues.  If it implements the Macro interface,
  # it can gain access to a copy of the Webcontext at runtime.  The
  # object will appear in your WebContext as a variable named after its
  # class, minus the word "Tool" if it appears.  So CGITool below
  # becomes the variable $CGI in your Template.
  #
  # The CGITool adds a $CGI variable with subproperties named after the
  # familiar CGI variable names, such as $CGI.QUERY_STRING, etc.
  #
  # The FormTool adds a $Form variable to your context, with
  # subproperties named after the available Form fieldnames.  For
  # example, $Form.Name would return the value of
  # HttpServletRequest.getParameterValues("Name")[0].  The FormList tool
  # is similar, but returns the Form value as an array rather than as a
  # single entry (and is $FormList in the template).
  #
  # CookieTool creates a $Cookie variable which can be used to get and
  # set cookies by name.  For example, $Cookie.Passowrd
  #
  # SessionTool creates a $Session variable that resovles to the
  # HttpSession of the current request.
  #
  WebContextTools = org.webmacro.servlet.CGITool \
                    org.webmacro.servlet.FormTool \
                    org.webmacro.servlet.FormListTool \
                    org.webmacro.servlet.CookieTool \
                    org.webmacro.servlet.ResponseTool \
                    org.webmacro.servlet.RequestTool \
                    org.webmacro.servlet.SessionTool
  
  
  #
  # The following are tools that are used to all contexts (not only
  # WebContexts).  We currently don't have any need for these.
  #
  ContextTools =
  
  
  #
  # The following are the parsers available to WebMacro.  The parser
  # which answers to "wm" will be used for most things, but you can
  # invoke a different parser by way of the #use directive, if it has
  # been included.  These parsers all implement
  # org.webmacro.engine.Parser.
  #
  Parsers = org.webmacro.engine.WMParser \
            org.webmacro.engine.NullParser \
            org.webmacro.engine.TextParser
  
  
  

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