<commit_before><?xml version="1.0"?>

<document>

 <header>
  <title>Velocity Todo</title>
  <subtitle>Velocity Todo</subtitle>
  <authors>
   <person name="Velocity Documentation Team" email="<EMAIL>"/>
  </authors>
 </header>

<body>

<s1 title="Todo">

<p>
This is an informal document describing what needs to
be done in the Velocity code base, and the 
Velocity documentation. If you need more detailed help, please 
send mail to the mailing list 
(<link href="mailto:<EMAIL>"><EMAIL></link>)
and ask your specific questions there. The list below is vaguely in order of
importance.
</p>

</s1>

<s1 title="The List">

    <strong>Runtime API</strong>
    <br/>
        The Velocity Runtime is the single access point for all
        of Velocity's functionality. A standard API for the
        Runtime should be defined so that in the span between
        the 0.5 Milestone release and a 1.0 release, the Runtime
        API changes as little as possible.
    <p/>

    <strong>JUnit Test Suite</strong>
    <br/>
        A JUnit test suite would allow Velocity developers to
        aggressively add, refactor, and optimize code. We need
        a comprehensive test suite so that we can
        be assured changes in the code base have no adverse
        effects for users. <link href="mailto:<EMAIL>"><NAME></link>
        has started us off with some code so you may want to contact
        him if you are interested in working on a JUnit test suite.
    <p/>

    <strong>Directive Interface</strong>
    <br/>
        Right now there is a very thin interface for directives, but
        some knowledge of JavaCC is required. The directive
        interface is not intended to be used outside core Velocity
        developers (it is not intended to be a public API), but it
        probably makes sense to shield directive creators from JavaCC.
    <p/>

    <strong>Context</strong>
    <br/>
        The Velocity Context class is still fairly primitive. It
        loosely adheres to a Map, but it definitely needs some
        thinking. It works fine now, but it might be good to
        think about: how to load standard tools and how to
        make that process efficient; how to stamp items in
        the context with expiry durations so that items can
        be cached and how this might work.
    <p/>

    <strong>Sample Applications</strong>
    <br/>
        Any type of sample application would be useful to
        help kickstart new developers get acquainted with
        Velocity. Any suggestions are welcome.
    <p/>

    <strong>User Guide</strong>
    <br/>
        This would be a guide for designers who would
        be using the Velocity Template Language (VTL) to
        create templates. The users guide would give
        example usage and a definitive description
        of the VTL syntax. <link href="mailto:<EMAIL>"><NAME></link>
        has started work on this with <NAME>, but any and all
        suggestions are welcome.
    <p/>
    
    <strong>Developer Guide</strong>
    <br/>
        This would be a guide for developers who would use
        Velocity as a stand-alone servlet tool, or in conjuction
        with a servlet controller framework like Turbine.
        <link href="mailto:<EMAIL>"><NAME></link> is
        currently working on this guide, but any and all suggestions
        are welcome.
    <p/>
    
    <strong>Template Loader System</strong>
    <br/>
        The template loader system is functional but could probably use an
        overhaul. There is currently a double template instantiation
        problem. It is not causing any serious problems, but it
        should probably be corrected. We could probably utilize some
        object caching/pooling code from Turbine, or JServ, or the
        Avalon Server Framework.
    <p/>

    <strong>Caching</strong>
    <br/>
        It would be good to have a discussion about how objects
        in the context should be cached, how the caching
        should be specified, and who should control the
        caching: the designer by specifying something in the template, the developer
        by place expiry times on objects placed in the context,
        or a third party like a content manager. For example,
        say an array consisting of a top 10 list of books is
        placed in the context. This top 10 list might be valid
        for a 24 hour period: how should that be specified? Say
        a content manager decides that this list is now valid
        for a week. Do they tell the designer, who in turn changes
        the template, or could we provide a mechanism that would
        allow a content manager to change the default expiry time
        for that particular context object with the aid of a webapp 
        of some sort? The groundwork has be laid for a flexible
        caching system in Velocity, but this discussion would be
        one of usage and policy.
    <p/>

    <strong>Parser Pool</strong>
    <br/>
        It would be good to create a pool of parsers that could
        be utilized by the Runtime. Right now there is only a single
        parser and the parsing is synchronized. The parsing doesn't
        happen all that often in production, but a small pool of
        parsers might alleviate any potential bottlenecks. Again,
        object caching/pooling code could be borrowed from Turbine,
        JServ, or the Avalon Server Framework.
    <p/>

    <strong>Velocity Profiling</strong>
    <br/>
        If someone is handy with one of the standard profilers,
        it would be great to start hunting for bottlenecks. No
        serious optimization has been started. But in conjuction
        with the presence of a JUnit test suite, optimization
        changes could be made with confidence. It would be nice
        to have a configuration of a setup for a common profiling
        so that anyone who wanted to do some profiling could do
        so in a consistent manner.
    <p/>

    <strong>Encoding Caching</strong>
    <br/>
        What would this entail? And how could we implement an
        efficient encoding caching mechanism.
    <p/>
    
    <strong>Plugins</strong>
    <br/>
        It would be good to allow plugins in the form of JAR files
        to be picked up the Velocity Runtime during startup. This
        would be a good way for Velocity developers to share tools<commit_msg>- updating todo. PR: Obtained from: Submitted by: Reviewed by:<commit_after><?xml version="1.0"?>

<document>

 <header>
  <title>Velocity Todo</title>
  <subtitle>Velocity Todo</subtitle>
  <authors>
   <person name="Velocity Documentation Team" email="<EMAIL>"/>
  </authors>
 </header>

<body>

<s1 title="Todo">

<p>
This is an informal document describing what needs to
be done in the Velocity code base, and the 
Velocity documentation. If you need more detailed help, please 
send mail to the mailing list 
(<link href="mailto:<EMAIL>"><EMAIL></link>)
and ask your specific questions there. The list below is vaguely in order of
importance.
</p>

</s1>

<s1 title="The List">

    <strong>Runtime API</strong>
    <br/>
        The Velocity Runtime is the single access point for all
        of Velocity's functionality. A standard API for the
        Runtime should be defined so that in the span between
        the 0.5 Milestone release and a 1.0 release, the Runtime
        API changes as little as possible.
    <p/>

    <strong>JUnit Test Suite</strong>
    <br/>
        A JUnit test suite would allow Velocity developers to
        aggressively add, refactor, and optimize code. We need
        a comprehensive test suite so that we can
        be assured changes in the code base have no adverse
        effects for users. <link href="mailto:<EMAIL>"><NAME></link>
        has started us off with some code so you may want to contact
        him if you are interested in working on a JUnit test suite.
    <p/>

    <strong>Directive Interface</strong>
    <br/>
        Right now there is a very thin interface for directives, but
        some knowledge of JavaCC is required. The directive
        interface is not intended to be used outside core Velocity
        developers (it is not intended to be a public API), but it
        probably makes sense to shield directive creators from JavaCC.
    <p/>

    <strong>Context</strong>
    <br/>
        The Velocity Context class is still fairly primitive. It
        loosely adheres to a Map, but it definitely needs some
        thinking. It works fine now, but it might be good to
        think about: how to load standard tools and how to
        make that process efficient; how to stamp items in
        the context with expiry durations so that items can
        be cached and how this might work.
    <p/>

    <strong>Sample Applications</strong>
    <br/>
        Any type of sample application would be useful to
        help kickstart new developers get acquainted with
        Velocity. Any suggestions are welcome.
    <p/>

    <strong>User's Guide</strong>
    <br/>
        This would be a guide for designers who would
        be using the Velocity Template Language (VTL) to
        create templates. The users guide would give
        example usage and a definitive description
        of the VTL syntax. <link href="mailto:<EMAIL>"><NAME></link>
        has started work on this with <NAME>, but any and all
        suggestions are welcome.
    <p/>
    
    <strong>Developer Guide</strong>
    <br/>
        This would be a guide for developers who would use
        Velocity as a stand-alone servlet tool, or in conjuction
        with a servlet controller framework like Turbine.
        <link href="mailto:<EMAIL>"><NAME></link> is
        currently working on this guide, but any and all suggestions
        are welcome.
    <p/>
    
    <strong>Template Loader System</strong>
    <br/>
        The template loader system is functional but could probably use an
        overhaul. There is currently a double template instantiation
        problem. It is not causing any serious problems, but it
        should be corrected. We could utilize some
        object caching/pooling code from Turbine, or JServ, or the
        Avalon Server Framework.
    <p/>

    <strong>Caching</strong>
    <br/>
        It would be good to have a discussion about how objects
        in the context should be cached, how the caching
        should be specified, and who should control the
        caching: the designer by specifying something in the template, the developer
        by place expiry times on objects placed in the context,
        or a third party like a content manager. For example,
        say an array consisting of a top 10 list of books is
        placed in the context. This top 10 list might be valid
        for a 24 hour period: how should that be specified? Say
        a content manager decides that this list is now valid
        for a week. Do they tell the designer, who in turn changes
        the template, or could we provide a mechanism that would
        allow a content manager to change the default expiry time
        for that particular context object with the aid of a webapp 
        of some sort? The groundwork has be laid for a flexible
        caching system in Velocity, but this discussion would be
        one of usage and policy.
    <p/>

    <strong>Parser Pool</strong>
    <br/>
        It would be good to create a pool of parsers that could
        be utilized by the Runtime. Right now there is only a single
        parser and the parsing is synchronized. The parsing doesn't
        happen all that often in production, but a small pool of
        parsers might alleviate any potential bottlenecks. Again,
        object caching/pooling code could be borrowed from Turbine,
        JServ, or the Avalon Server Framework.
    <p/>

    <strong>Velocity Profiling</strong>
    <br/>
        If someone is handy with one of the standard profilers,
        it would be great to start hunting for bottlenecks. No
        serious optimization has been started. But in conjuction
        with the presence of a JUnit test suite, optimization
        changes could be made with confidence. It would be nice
        to have a configuration of a setup for a common profiler
        so that anyone who wanted to do some profiling could do
        so in a consistent manner.
    <p/>

    <strong>Encoding Caching</strong>
    <br/>
        What would this entail? And how could we implement an
        efficient encoding caching mechanism.
    <p/>
    
    <strong>Plugins</strong>
    <br/>
        It would be good to allow plugins in the form of JAR files
        to be picked up the Velocity Runtime during startup. This
        would be a good way for Velocity developers to share tools
{'fraction_non_alphanumeric': 0.05441911305434104, 'fraction_numerical': 0.0023422860712054966, 'mean_word_length': 2.497815401419989, 'pattern_counts': {'":': 0, '<': 175, '<?xml version=': 2, '>': 175, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5125026', 'n_tokens_mistral': 3297, 'n_tokens_neox': 3176, 'n_words': 1744}