thanks a lot i'll look it up.
On 7/26/07, Tim O'Brien <[EMAIL PROTECTED]> wrote:
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
