below... On 7/26/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 7/26/07, Francisco Diaz Trepat - gmail <[EMAIL PROTECTED]> wrote: > > Igor, with ALL DUE RESPECT ok?, because I feel that part is getting out. > And I am not attacking anyone here. > > But it is clearly stated that: > > "It seems you have copy-pasted a quite bunch of code, and if you're > going to develop this further there is no point for me to try to > remove the code duplication" > all janne said is that the code needs refactoring. and if you are still planning on working on it shortterm there is no point for him to refactor it now - it should be done once the dust settles. the problem is that you do not have committer access, so both of you cannot collaborate if he would refactor and merge it in until you learn how to make patches. you shouldnt put your code out there unless you have thick skin, cause it will get reviewed/critiqued. if you are lucky it will be done by a better developer so you can learn something from the result if you are interested in learning. anyways, patches... pretty easy. i use eclipse so let me explain real quick. check out the project from svn hack away after you are done hacking right click the project go to team/createpatch - done
If you don't use Eclipse, there is a page detailing the patch creation process from the command-line on the Jakarta project's site: http://jakarta.apache.org/site/source.html#Patches on the mirror side janne can take your patch, right click wicket, do
team/apply patch - and immediately see your code/changes/blah -igor I don't intend to replace any code. You get my code and do whatever you feel > with it. Change it - refactor it - renamed it. Don't include it in wicket > extension, whatever. > > But don't say it is just a copy-paste and is not worth replacing code that > is a copy o something that already exist. I think this is clearly stated. > > > > what he is saying is that > > because you separated everything into a different package and did not do > > this as a patch it makes it a hell of a lot harder to merge it into > > extensions codebase and to see exactly where the differences are. > > > In every mail message I try to explain this to be a first time for me, and > try asking for concrete directions. I'll hope to do better the next time. if > any. > > screenshots are nice (the mailing list stripped them btw) but having those > > differences open inside an ide is much better. > > > Can you see these attachments now? or are they still being stripped out? > > so here are my two cents: > > > > there are two ways of integrating this into our codebase if that is what > > you > > want: > > > > a) replace our autocomplete with this one - in which case we need to > > decide > > how to do it since you did not do this as a patch. > > > NO no no no no. The autocomplete version I submitted to the jira is for > key and value options and that is eventually an exception to the normal case > in which someone would just want an autocomplete and that is that. > > Although feel free to take my implementation of the way the HTML elements > get created and referenced to be able to have a table. But once more this is > an exception and not a normal autocomplete behavior. > > > b) put this as an alternative into wicket-stuff, maybe wicketstuff-minis > > project. the added bonus is that you can directly maintain it, the con > > being > > that we will essentially have two "competing" implementations of the > > same > > thing. competing in the sense that users will have to choose one. > > > Excelent, the option any of you guys defined for me is fine by me. The > only thing I don't want is to generate any confussions. And be able to help > out. > > -igor > > > > >
-- ------ Tim O'Brien: (847) 863-7045
