Don Brown wrote:
Could you commit your version as a development branch, rather than to
trunk?  I'm using/improving Codebehind right now in some of the new
features both in core and the rest plugin.  I'd also like a chance to
fully review the changes before we dump the old.

On 12/6/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
I'm going to start working on the SmartURLs port. Here's what I'm planning:

1. Deprecate all the current codebehind annotations and classes

I'm still not convinced this is a good idea, but as I said, I'll
reserve judgment till the merge branch is ready.
As long as it's a deprecation and not deletion, I think it will be fine. i.e. in 2.1.x you can configure the app to use the old mechanism.

The only other (really small picky thing) is the name "codebehind". What I see Brian doing to providing mapping and configuration. When I think of "codebehind" I think of the code that looks up a result template following naming conventions. Although these may have been considered one-and-the-same, I think by separating them by names we can enhance both concurrently. i.e. rails scaffolding - introduce a plug-in that can generate JSP code by reflecting on the action

Reply via email to