You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by bu...@apache.org on 2002/03/25 19:35:02 UTC

DO NOT REPLY [Bug 7456] New: - Improving the Velocity Context interface

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7456>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7456

Improving the Velocity Context interface

           Summary: Improving the Velocity Context interface
           Product: Velocity
           Version: 1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Build
        AssignedTo: velocity-dev@jakarta.apache.org
        ReportedBy: matt@stream-tech.com


Let me start by saying that I think Velocity is a great product that nearly 
every application can use.  I've written a framework similar to Velocity, and 
have been using it for some time now.  I'm glad to see there are so many 
similarities - it really reinforces that what I'm doing might actually be 
acceptable by the open-source community.  Maybe what I have learned while 
developing and implementing my template engine might offer something to your 
initiative.  At any rate, here goes...

Removing the put, remove, and getKeys methods from the Context interface will 
make it easier to implement, while limiting the responsibility of the Context 
to the absolute minimum.  There's no sense in forcing a Context to provide 
mutator methods when it might not need (or want) to.  I suggest putting that 
functionality in a more specialized implementation of Context.  Can't the 
template merge a context with itself using only the get and containsKey methods?

Thanks for listening - I hope this is useful in some way.  If possible, please 
let me know what you think.

Best Regards,
Matt Nicolls

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