Ted Husted wrote:
On 11/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
Well I initially proposed it back in September and took the lack of
objections to imply agreement...
I think Niall's and Joe's comments, while not strictly "objections",
did imply some disagreement, which Hubert has affirmed. If a committer
comments on a ticket, I think it's important that we address those
concerns before applyng a patch. Code changes are subject to
consensus, which means that all the committers (or at least PMC
members) have to agree, or at least not disagree.
Why do we all have to agree? Because we are all on the hook to support
any changes made to the codebase. We all own all of the codebase, not
just the parts we change ourselves. If one of us is unavailable, the
rest have to be ready to pick up the slack.
Of course, Struts is a "commit-then-review" project, so it's perfectly
all right to make changes first, and then see if people like it. But,
when we do this, we just have to be prepared to answer any concerns
afterwards (as we are doing now), which could include reversing the
change, or implementing the change in an totally different way.
Meanwhile, I'm setting up the Extras subproject now. One idea would be
to put a "CGDynaActionForm" class there. We might want to move other
very optional classes there too, and keep only the "cannonical"
classes in the Core (or Action Framework) subproject.
Yes, I agree with all of that, I wasn't trying to duck Hubert's comments
;-) In fact I was pretty much working on the assumption of
'commit-then-review' and fully expecting commentary.
So, the question now is what to do with the code I committed; I'd
planned to add a check for CGLIB and not attempt the enhancement if the
library wasn't present, to address Hubert's concerns. Having just looked
through Nial's comments on the Bugzilla ticket [1], though, it seems
like I should go a step further, and make this something you have to
explicitly enable.
I was planning to look at adding the idea Ryan proposed [2], making it
possible to specify an interface for the dyna bean to implement. So, how
about an 'interface' attribute on form-property, which can take either
the value 'auto' or the FQCN of an actual interface, where 'auto' would
give you the behaviour I just added.
That way, the existing behaviour doesn't change by default. Or, I can
roll back the commit and look at creating a seperate (set of) classes to
be included in the Extras subproject when it's set up.
I'm open to either option, or alternative proposals, whatever gives us
consensus.
L.
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=36794
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=37301
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
