New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Hi, igor, or someone:

I took the liberty in writing an extensible autocomplete behavior based on
the AutocompleteTextField by Janne (jannehietamaki).



I was supposed to open a JIRA but as I've never done this, I wanted to get
some instructions on how to do it.

For those not following. The idea is to have an autocomplete behavior that
allows you to have *key* and *value* if you need it. This is done by either
including a hidden field or by adding an attribute to the
autocomplete-field, or it can be left out and works exactly like the one
that is know available in the extensions package. The thing started out as
the current implementation used a fixed "node path" to get the elements that
needed to render select etc. Now it uses an option/choice name.

To do this I had to re-write the JavaScript and All the abstract classes so
I did a new package all together.

And renamed all of the classes to have both of them without any conflicts. I
also included a new collection class in the javascript to help out and I
putted on a Wicket.Collection "package", and also named this autocomplete as
ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any
html markup you feel like and it will work (choose arrows etc),
*Choice* because
it can use key and value like a DropdownChoice, and *Autocomplete* because
it is an autocomplete.

All naming convention might be wrong and some of my code might not make the
grade for you guys, so what I would like is to have someone review it and
see if it is considered to be included somewhere.

Wicket is awesome, I get lots of help all the time, and just want to
contribute.

There are some algorithms in the JavaScript that didn't worked on IE 7 and
IE 6 because of a well known issue on IE that is that it does not refresh
document DOM on the assignment of the innerHTML property of an element. But
that is taken care of by using element.all collection that works for IE 7
and 6.

Also my code is usually considered heavily commented so as I see wicket code
in general is not, maybe the reviewer would have to erase some comments.

Feel Free is the key. I want to contribute, keep contributing in the future,
and learn a proper way not to step on any one's feet.

Best regards,
f(t)

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Yes, wicket is great.
I cannot agree with the scriptaculos. Both wicket-extenssions and
scriptaculos don't support any html. They both support putting <ul><li> with
inside them any html like images <img> and divs spans <p> etc. It also
supports puting <div><div> or span div or span span etc on wicket if you
change a little bit.

But that doesn't mean any html. For instance you cannot put a table with
rows and colunms and then have the rows painted over key controls like *up
down left & right* arrows.

In scriptaculous looks for ul and the wicket one lives that open with the
renderer but it is fixed on the JavaScript by looking at the,
menu.firstChild.childNodes, that means that inside the menu container you
cannot put any html that whould argue that path that is.

Menu Container
  Your Choices Container
    Your Choices

Inside a table you have:

Menu Container
   Your Table
      Your Table Body (this is put in the DOM whether you specify it or not.
         Your Rows

This is not accesible due to the firstChild.childNodes which in this case
would translate to table.tableBody and not the tr that you maight need. Also
the event handlers for key down key pressed etc are similar.


f(t)
On 7/24/07, Ryan Sonnek <ry...@gmail.com> wrote:
>
> Nice work.  It's pretty amazing how easy it is to create these "widgets"
> with wicket.
>
> One comment i have is that the scriptaculous autocomplete component
> supports
> "custom layouts" where you can display any any html for each autocomplete
> result.  It also supports the concept of a "key/value".  you can have any
> value posted back to the server, but it can display something different.
>
> I'm sure your usecase is different enough to warrent another contribution.
> Just wanted to mention that a widget already exists for a "similar"
> usecase.
>
> Ryan
>
> On 7/24/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> wrote:
> >
> > Hi, igor, or someone:
> >
> > I took the liberty in writing an extensible autocomplete behavior based
> on
> > the AutocompleteTextField by Janne (jannehietamaki).
> >
> >
> >
> > I was supposed to open a JIRA but as I've never done this, I wanted to
> get
> > some instructions on how to do it.
> >
> > For those not following. The idea is to have an autocomplete behavior
> that
> > allows you to have *key* and *value* if you need it. This is done by
> > either
> > including a hidden field or by adding an attribute to the
> > autocomplete-field, or it can be left out and works exactly like the one
> > that is know available in the extensions package. The thing started out
> as
> > the current implementation used a fixed "node path" to get the elements
> > that
> > needed to render select etc. Now it uses an option/choice name.
> >
> > To do this I had to re-write the JavaScript and All the abstract classes
> > so
> > I did a new package all together.
> >
> > And renamed all of the classes to have both of them without any
> conflicts.
> > I
> > also included a new collection class in the javascript to help out and I
> > putted on a Wicket.Collection "package", and also named this
> autocomplete
> > as
> > ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any
> > html markup you feel like and it will work (choose arrows etc),
> > *Choice* because
> > it can use key and value like a DropdownChoice, and *Autocomplete*
> because
> > it is an autocomplete.
> >
> > All naming convention might be wrong and some of my code might not make
> > the
> > grade for you guys, so what I would like is to have someone review it
> and
> > see if it is considered to be included somewhere.
> >
> > Wicket is awesome, I get lots of help all the time, and just want to
> > contribute.
> >
> > There are some algorithms in the JavaScript that didn't worked on IE 7
> and
> > IE 6 because of a well known issue on IE that is that it does not
> refresh
> > document DOM on the assignment of the innerHTML property of an element.
> > But
> > that is taken care of by using element.all collection that works for IE
> 7
> > and 6.
> >
> > Also my code is usually considered heavily commented so as I see wicket
> > code
> > in general is not, maybe the reviewer would have to erase some comments.
> >
> > Feel Free is the key. I want to contribute, keep contributing in the
> > future,
> > and learn a proper way not to step on any one's feet.
> >
> > Best regards,
> > f(t)
> >
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Ryan Sonnek <ry...@gmail.com>]

Nice work.  It's pretty amazing how easy it is to create these "widgets"
with wicket.

One comment i have is that the scriptaculous autocomplete component supports
"custom layouts" where you can display any any html for each autocomplete
result.  It also supports the concept of a "key/value".  you can have any
value posted back to the server, but it can display something different.

I'm sure your usecase is different enough to warrent another contribution.
Just wanted to mention that a widget already exists for a "similar" usecase.

Ryan

On 7/24/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
wrote:
>
> Hi, igor, or someone:
>
> I took the liberty in writing an extensible autocomplete behavior based on
> the AutocompleteTextField by Janne (jannehietamaki).
>
>
>
> I was supposed to open a JIRA but as I've never done this, I wanted to get
> some instructions on how to do it.
>
> For those not following. The idea is to have an autocomplete behavior that
> allows you to have *key* and *value* if you need it. This is done by
> either
> including a hidden field or by adding an attribute to the
> autocomplete-field, or it can be left out and works exactly like the one
> that is know available in the extensions package. The thing started out as
> the current implementation used a fixed "node path" to get the elements
> that
> needed to render select etc. Now it uses an option/choice name.
>
> To do this I had to re-write the JavaScript and All the abstract classes
> so
> I did a new package all together.
>
> And renamed all of the classes to have both of them without any conflicts.
> I
> also included a new collection class in the javascript to help out and I
> putted on a Wicket.Collection "package", and also named this autocomplete
> as
> ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any
> html markup you feel like and it will work (choose arrows etc),
> *Choice* because
> it can use key and value like a DropdownChoice, and *Autocomplete* because
> it is an autocomplete.
>
> All naming convention might be wrong and some of my code might not make
> the
> grade for you guys, so what I would like is to have someone review it and
> see if it is considered to be included somewhere.
>
> Wicket is awesome, I get lots of help all the time, and just want to
> contribute.
>
> There are some algorithms in the JavaScript that didn't worked on IE 7 and
> IE 6 because of a well known issue on IE that is that it does not refresh
> document DOM on the assignment of the innerHTML property of an element.
> But
> that is taken care of by using element.all collection that works for IE 7
> and 6.
>
> Also my code is usually considered heavily commented so as I see wicket
> code
> in general is not, maybe the reviewer would have to erase some comments.
>
> Feel Free is the key. I want to contribute, keep contributing in the
> future,
> and learn a proper way not to step on any one's feet.
>
> Best regards,
> f(t)
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Ok. I am attaching the JIRA Right now.

On 7/25/07, Timo Rantalaiho <Ti...@ri.fi> wrote:
>
> On Tue, 24 Jul 2007, Francisco Diaz Trepat - gmail wrote:
> > I was supposed to open a JIRA but as I've never done this, I wanted to
> get
> > some instructions on how to do it.
>
> If you don't have an account to Apache Jira yet, create it
> here
>
> https://issues.apache.org/jira/secure/Signup!default.jspa
>
> Login here
>
> https://issues.apache.org/jira/secure/Dashboard.jspa
>
> and then click "CREATE NEW ISSUE".
>
> - Timo
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Eelco Hillenius <ee...@gmail.com>]

On 7/26/07, Francisco Diaz Trepat - gmail
<fr...@gmail.com> wrote:
> Eelco I have to leave the office now so I'll read and respond you properly
> latter to day if I come back sover... jaja sorry Birthday, today I am 28 and
> seems a good enough reason to get wasted. ajajajjajaa

I hope you don't have nasty hang-overs :) Congrats.

Eelco

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Eelco I have to leave the office now so I'll read and respond you properly
latter to day if I come back sover... jaja sorry Birthday, today I am 28 and
seems a good enough reason to get wasted. ajajajjajaa


bye


On 7/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > To finish up, If some where on the way of contributing this autocomplete
> > version I steped on anybodies toes then I am sorry and can bet that it
> was
> > not intended at all. I am not here to compete in any way with anybody.
>
> I don't think you did, and I think in general no-one in this community
> thinks along those lines. As for competition: well if you make a
> component that beats another, that's all for the better. The
> end-result benefits our users, and it's just natural that before
> components get really good they need a few iterations (from the same
> authors or others).
>
> Now, what I think Janne meant is that he wasn't satisfied with the
> quality of what you contributed. If there is obvious copy 'n paste
> code in it, it often means that you haven't been thinking it through
> properly yet. I hope you take no offense when I say that. Also, he
> asked for patches, which are much easier to apply for us. Just saves
> work and manual tweaking.
>
> Maybe at this point it is easier when you commit in a sandbox project
> first, e.g. on wicket-stuff. WDYT?
>
> Eelco
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Eelco Hillenius <ee...@gmail.com>]

> To finish up, If some where on the way of contributing this autocomplete
> version I steped on anybodies toes then I am sorry and can bet that it was
> not intended at all. I am not here to compete in any way with anybody.

I don't think you did, and I think in general no-one in this community
thinks along those lines. As for competition: well if you make a
component that beats another, that's all for the better. The
end-result benefits our users, and it's just natural that before
components get really good they need a few iterations (from the same
authors or others).

Now, what I think Janne meant is that he wasn't satisfied with the
quality of what you contributed. If there is obvious copy 'n paste
code in it, it often means that you haven't been thinking it through
properly yet. I hope you take no offense when I say that. Also, he
asked for patches, which are much easier to apply for us. Just saves
work and manual tweaking.

Maybe at this point it is easier when you commit in a sandbox project
first, e.g. on wicket-stuff. WDYT?

Eelco

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Sorry, forgot.

On 7/27/07, Janne Hietamäki <ja...@apache.org> wrote:
>
> Heh, I don't care what you do with my code, it's nice to see it's
> used, but I don't want to have duplicated code/bugs in Wicket.
>
> If you compare this:
>
> http://papernapkin.org/pastebin/view/1095
>
> and this:
>
> https://svn.apache.org/repos/asf/incubator/wicket/trunk/jdk-1.4/
> wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/
> markup/html/autocomplete/wicket-autocomplete.js
>
> There are for sure a load of duplicated code. Do you think i don't
> recognize my own code? :)


No, I think you mislead on purpose, I don't know why, but otherwise why
would you started all this discussion in public. :-) :-) :-)

Janne
>
> On 27.7.2007, at 1.30, Francisco Diaz Trepat - gmail wrote:
>
> > I see you still claiming copy except for the comments. at least you
> > gave me that.
> > petty you fail to specify as I ask.
> >
> > On 7/26/07, Janne Hietamäki <ja...@apache.org> wrote:
> >> Hi,
> >>
> >> I did not mean to criticise you in any way, but for sure there is a
> >> quite a lot of duplicate code/functionality in both javascript and
> >> java.  When I compare these two versions of javascript, most of the
> >> code is exactly equal (ok, you have added some comments). Duplicated
> >> code means always duplicated bugs, and that is always a bad thing.
> >> Specially with javascript is bad, because a new browser version tend
> >> to break things that have earlier been working just fine. When almost
> >> the same code is in two places, the work needed to fix all the bugs,
> >> test everything etc. is duplicated. Less is really more.
> >>
> >> I see no point of having alternate version of autocomplete for doing
> >> almost the same thing as the old one, that will only bloat the API
> >> and increases the amount of code. I would like to see the
> >> autocomplete extended so it can handle the use case you have. That
> >> should be quite straightforward thing to do, and really, you have
> >> already done that. Now we have to find a way to integrate you work
> >> into Wicket.
> >>
> >> Patches are a good thing, because now it seems you have worked with a
> >> version from the 1.2 branch, but trunk already has some fixes which
> >> your code does not contain. It's easier to handle the changes with
> >> patches, so we can see what you really have changed.
> >>
> >> Janne
> >>
> >>
> >> On 26.7.2007, at 21.39, Francisco Diaz Trepat - gmail wrote:
> >>
> >> > Janne I thought some more about this mail. And I wanted to say a
> >> > couple of things:
> >> >
> >> > 1) It is not my intention in any way to replace the code for the
> >> > auto-complete you and Igor developed.
> >> >
> >> > 2) It is not my intention to criticise it either.
> >> >
> >> > 3) I had to develop an alternative, as I wrote in the code, I based
> >> > the extensible autocomplete code on the one that you and Igor
> >> > developed.
> >> >
> >> > 4) Here are some Print Screens taken to the Open Source WinMerge
> >> > application on the tree key files which are the JavaScript, the
> >> > Abstract extension of the AbstractDefaultAjaxBehavior and the
> >> > extension of that that implements the renderer interface. As you
> >> > might notice the codes are far from similar and far far far far
> >> > away from a copy paste.
> >> >
> >> > 5) If a patch is the proper thing to upload instead of whatever I
> >> > did, then please tell me and I'll be more than happy to follow the
> >> > procedure, although it was not my intention to submit a patch to
> >> > anything, just a new feature based on an existing one.
> >> >
> >> > To finish up, If some where on the way of contributing this
> >> > autocomplete version I steped on anybodies toes then I am sorry and
> >> > can bet that it was not intended at all. I am not here to compete
> >> > in any way with anybody.
> >> > Wicket struck awesome to me and to my team mates as well. And
> >> > inspire me and them to help out whenever possible without
> >> > compromising company policies. We hope to be able to keep
> >> > contributing but don't want to get wrong impressions.
> >> >
> >> > Respectfully,
> >> > Francisco Díaz Trepat
> >> >
> >> >
> >> > On 7/25/07, Francisco Diaz Trepat - gmail
> >> > <fr...@gmail.com> wrote:
> >> > Would you be a bit more specific please?
> >> >
> >> >
> >> > I thought I rewrote most of it. Perhaps I am mistaken.
> >> >
> >> >
> >> > Which part?
> >> >
> >> >
> >> > Best Wishes,
> >> > f(t)
> >> >
> >> >
> >> > On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
> >> > Hi,
> >> >
> >> > 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 and try to integrate the code with the
> >> > old autocomplete. Also, patches would be nicer.
> >> >
> >> > Janne
> >> >
> >> > On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
> >> >
> >> > > I'm such a user... So anxious some times...
> >> > >
> >> > > Thanks, I have now attached a file named AutocompleteTestCase.rar
> >> > > (badly
> >> > > named, but...) with the code and a page with 3 samples.
> >> > >
> >> > > Until I am a master in maven and contribute some more, please be
> >> > > patient
> >> > > with details, like not putting all in the quick-start given
> >> sample
> >> > > (as igor
> >> > > suggested correctly). I'll get there.
> >> > >
> >> > > ++
> >> > >
> >> > > I'm still working in the code thinking now I am going to add two
> >> > more
> >> > > features to it:
> >> > >
> >> > > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> >> > > *Selects the choice without further need of interaction if
> >> only one
> >> > > choice
> >> > > is returned by the ajax call. Good for zipcodes, areacode,  and
> >> > > general code
> >> > > data entry.*
> >> > >
> >> > > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> >> > > the server
> >> > > to look up choices. Again good for zipcodes, and general code
> >> > > entering data
> >> > > entry slaves who usually enter data very fast.
> >> > >
> >> > > regards,
> >> > >
> >> > > f(t)
> >> > >
> >> > >
> >> > > On 7/25/07, Eelco Hillenius < eelco.hillenius@gmail.com > wrote:
> >> > >>
> >> > >> On 7/25/07, Francisco Diaz Trepat - gmail
> >> > >> < francisco.diaztrepat@gmail.com> wrote:
> >> > >> > Wait a minute, I am creating the jira but when do I upload the
> >> > >> code?
> >> > >>
> >> > >> Right after you created it.
> >> > >>
> >> > >> Eelco
> >> > >>
> >> >
> >> >
> >> >
> >> >
> >>
> >>
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Fine, whatever. I'm tired to arguee about this issue.

I am still planning in improving Your code further. Adding delay in
milliseconds to call the ajax funciton so that fast data entry may call only
once to the server and refactor onblur event so that it will select the last
autocomplete result if one choice only was returned by the ajax call.

Also Scrollbars and scrollTo functions so that keyboard arrow events would
trigger the srolling followup.


f(t)




On 7/27/07, Janne Hietamäki <ja...@apache.org> wrote:
>
> Heh, I don't care what you do with my code, it's nice to see it's
> used, but I don't want to have duplicated code/bugs in Wicket.
>
> If you compare this:
>
> http://papernapkin.org/pastebin/view/1095
>
> and this:
>
> https://svn.apache.org/repos/asf/incubator/wicket/trunk/jdk-1.4/
> wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/
> markup/html/autocomplete/wicket-autocomplete.js
>
> There are for sure a load of duplicated code. Do you think i don't
> recognize my own code? :)
>
>
> Janne
>
> On 27.7.2007, at 1.30, Francisco Diaz Trepat - gmail wrote:
>
> > I see you still claiming copy except for the comments. at least you
> > gave me that.
> > petty you fail to specify as I ask.
> >
> > On 7/26/07, Janne Hietamäki <ja...@apache.org> wrote:
> >> Hi,
> >>
> >> I did not mean to criticise you in any way, but for sure there is a
> >> quite a lot of duplicate code/functionality in both javascript and
> >> java.  When I compare these two versions of javascript, most of the
> >> code is exactly equal (ok, you have added some comments). Duplicated
> >> code means always duplicated bugs, and that is always a bad thing.
> >> Specially with javascript is bad, because a new browser version tend
> >> to break things that have earlier been working just fine. When almost
> >> the same code is in two places, the work needed to fix all the bugs,
> >> test everything etc. is duplicated. Less is really more.
> >>
> >> I see no point of having alternate version of autocomplete for doing
> >> almost the same thing as the old one, that will only bloat the API
> >> and increases the amount of code. I would like to see the
> >> autocomplete extended so it can handle the use case you have. That
> >> should be quite straightforward thing to do, and really, you have
> >> already done that. Now we have to find a way to integrate you work
> >> into Wicket.
> >>
> >> Patches are a good thing, because now it seems you have worked with a
> >> version from the 1.2 branch, but trunk already has some fixes which
> >> your code does not contain. It's easier to handle the changes with
> >> patches, so we can see what you really have changed.
> >>
> >> Janne
> >>
> >>
> >> On 26.7.2007, at 21.39, Francisco Diaz Trepat - gmail wrote:
> >>
> >> > Janne I thought some more about this mail. And I wanted to say a
> >> > couple of things:
> >> >
> >> > 1) It is not my intention in any way to replace the code for the
> >> > auto-complete you and Igor developed.
> >> >
> >> > 2) It is not my intention to criticise it either.
> >> >
> >> > 3) I had to develop an alternative, as I wrote in the code, I based
> >> > the extensible autocomplete code on the one that you and Igor
> >> > developed.
> >> >
> >> > 4) Here are some Print Screens taken to the Open Source WinMerge
> >> > application on the tree key files which are the JavaScript, the
> >> > Abstract extension of the AbstractDefaultAjaxBehavior and the
> >> > extension of that that implements the renderer interface. As you
> >> > might notice the codes are far from similar and far far far far
> >> > away from a copy paste.
> >> >
> >> > 5) If a patch is the proper thing to upload instead of whatever I
> >> > did, then please tell me and I'll be more than happy to follow the
> >> > procedure, although it was not my intention to submit a patch to
> >> > anything, just a new feature based on an existing one.
> >> >
> >> > To finish up, If some where on the way of contributing this
> >> > autocomplete version I steped on anybodies toes then I am sorry and
> >> > can bet that it was not intended at all. I am not here to compete
> >> > in any way with anybody.
> >> > Wicket struck awesome to me and to my team mates as well. And
> >> > inspire me and them to help out whenever possible without
> >> > compromising company policies. We hope to be able to keep
> >> > contributing but don't want to get wrong impressions.
> >> >
> >> > Respectfully,
> >> > Francisco Díaz Trepat
> >> >
> >> >
> >> > On 7/25/07, Francisco Diaz Trepat - gmail
> >> > <fr...@gmail.com> wrote:
> >> > Would you be a bit more specific please?
> >> >
> >> >
> >> > I thought I rewrote most of it. Perhaps I am mistaken.
> >> >
> >> >
> >> > Which part?
> >> >
> >> >
> >> > Best Wishes,
> >> > f(t)
> >> >
> >> >
> >> > On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
> >> > Hi,
> >> >
> >> > 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 and try to integrate the code with the
> >> > old autocomplete. Also, patches would be nicer.
> >> >
> >> > Janne
> >> >
> >> > On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
> >> >
> >> > > I'm such a user... So anxious some times...
> >> > >
> >> > > Thanks, I have now attached a file named AutocompleteTestCase.rar
> >> > > (badly
> >> > > named, but...) with the code and a page with 3 samples.
> >> > >
> >> > > Until I am a master in maven and contribute some more, please be
> >> > > patient
> >> > > with details, like not putting all in the quick-start given
> >> sample
> >> > > (as igor
> >> > > suggested correctly). I'll get there.
> >> > >
> >> > > ++
> >> > >
> >> > > I'm still working in the code thinking now I am going to add two
> >> > more
> >> > > features to it:
> >> > >
> >> > > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> >> > > *Selects the choice without further need of interaction if
> >> only one
> >> > > choice
> >> > > is returned by the ajax call. Good for zipcodes, areacode,  and
> >> > > general code
> >> > > data entry.*
> >> > >
> >> > > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> >> > > the server
> >> > > to look up choices. Again good for zipcodes, and general code
> >> > > entering data
> >> > > entry slaves who usually enter data very fast.
> >> > >
> >> > > regards,
> >> > >
> >> > > f(t)
> >> > >
> >> > >
> >> > > On 7/25/07, Eelco Hillenius < eelco.hillenius@gmail.com > wrote:
> >> > >>
> >> > >> On 7/25/07, Francisco Diaz Trepat - gmail
> >> > >> < francisco.diaztrepat@gmail.com> wrote:
> >> > >> > Wait a minute, I am creating the jira but when do I upload the
> >> > >> code?
> >> > >>
> >> > >> Right after you created it.
> >> > >>
> >> > >> Eelco
> >> > >>
> >> >
> >> >
> >> >
> >> >
> >>
> >>
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Janne Hietamäki <ja...@apache.org>]

Heh, I don't care what you do with my code, it's nice to see it's  
used, but I don't want to have duplicated code/bugs in Wicket.

If you compare this:

http://papernapkin.org/pastebin/view/1095

and this:

https://svn.apache.org/repos/asf/incubator/wicket/trunk/jdk-1.4/ 
wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/ 
markup/html/autocomplete/wicket-autocomplete.js

There are for sure a load of duplicated code. Do you think i don't  
recognize my own code? :)

Janne

On 27.7.2007, at 1.30, Francisco Diaz Trepat - gmail wrote:

> I see you still claiming copy except for the comments. at least you
> gave me that.
> petty you fail to specify as I ask.
>
> On 7/26/07, Janne Hietamäki <ja...@apache.org> wrote:
>> Hi,
>>
>> I did not mean to criticise you in any way, but for sure there is a
>> quite a lot of duplicate code/functionality in both javascript and
>> java.  When I compare these two versions of javascript, most of the
>> code is exactly equal (ok, you have added some comments). Duplicated
>> code means always duplicated bugs, and that is always a bad thing.
>> Specially with javascript is bad, because a new browser version tend
>> to break things that have earlier been working just fine. When almost
>> the same code is in two places, the work needed to fix all the bugs,
>> test everything etc. is duplicated. Less is really more.
>>
>> I see no point of having alternate version of autocomplete for doing
>> almost the same thing as the old one, that will only bloat the API
>> and increases the amount of code. I would like to see the
>> autocomplete extended so it can handle the use case you have. That
>> should be quite straightforward thing to do, and really, you have
>> already done that. Now we have to find a way to integrate you work
>> into Wicket.
>>
>> Patches are a good thing, because now it seems you have worked with a
>> version from the 1.2 branch, but trunk already has some fixes which
>> your code does not contain. It's easier to handle the changes with
>> patches, so we can see what you really have changed.
>>
>> Janne
>>
>>
>> On 26.7.2007, at 21.39, Francisco Diaz Trepat - gmail wrote:
>>
>> > Janne I thought some more about this mail. And I wanted to say a
>> > couple of things:
>> >
>> > 1) It is not my intention in any way to replace the code for the
>> > auto-complete you and Igor developed.
>> >
>> > 2) It is not my intention to criticise it either.
>> >
>> > 3) I had to develop an alternative, as I wrote in the code, I based
>> > the extensible autocomplete code on the one that you and Igor
>> > developed.
>> >
>> > 4) Here are some Print Screens taken to the Open Source WinMerge
>> > application on the tree key files which are the JavaScript, the
>> > Abstract extension of the AbstractDefaultAjaxBehavior and the
>> > extension of that that implements the renderer interface. As you
>> > might notice the codes are far from similar and far far far far
>> > away from a copy paste.
>> >
>> > 5) If a patch is the proper thing to upload instead of whatever I
>> > did, then please tell me and I'll be more than happy to follow the
>> > procedure, although it was not my intention to submit a patch to
>> > anything, just a new feature based on an existing one.
>> >
>> > To finish up, If some where on the way of contributing this
>> > autocomplete version I steped on anybodies toes then I am sorry and
>> > can bet that it was not intended at all. I am not here to compete
>> > in any way with anybody.
>> > Wicket struck awesome to me and to my team mates as well. And
>> > inspire me and them to help out whenever possible without
>> > compromising company policies. We hope to be able to keep
>> > contributing but don't want to get wrong impressions.
>> >
>> > Respectfully,
>> > Francisco Díaz Trepat
>> >
>> >
>> > On 7/25/07, Francisco Diaz Trepat - gmail
>> > <fr...@gmail.com> wrote:
>> > Would you be a bit more specific please?
>> >
>> >
>> > I thought I rewrote most of it. Perhaps I am mistaken.
>> >
>> >
>> > Which part?
>> >
>> >
>> > Best Wishes,
>> > f(t)
>> >
>> >
>> > On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
>> > Hi,
>> >
>> > 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 and try to integrate the code with the
>> > old autocomplete. Also, patches would be nicer.
>> >
>> > Janne
>> >
>> > On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
>> >
>> > > I'm such a user... So anxious some times...
>> > >
>> > > Thanks, I have now attached a file named AutocompleteTestCase.rar
>> > > (badly
>> > > named, but...) with the code and a page with 3 samples.
>> > >
>> > > Until I am a master in maven and contribute some more, please be
>> > > patient
>> > > with details, like not putting all in the quick-start given  
>> sample
>> > > (as igor
>> > > suggested correctly). I'll get there.
>> > >
>> > > ++
>> > >
>> > > I'm still working in the code thinking now I am going to add two
>> > more
>> > > features to it:
>> > >
>> > > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
>> > > *Selects the choice without further need of interaction if  
>> only one
>> > > choice
>> > > is returned by the ajax call. Good for zipcodes, areacode,  and
>> > > general code
>> > > data entry.*
>> > >
>> > > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
>> > > the server
>> > > to look up choices. Again good for zipcodes, and general code
>> > > entering data
>> > > entry slaves who usually enter data very fast.
>> > >
>> > > regards,
>> > >
>> > > f(t)
>> > >
>> > >
>> > > On 7/25/07, Eelco Hillenius < eelco.hillenius@gmail.com > wrote:
>> > >>
>> > >> On 7/25/07, Francisco Diaz Trepat - gmail
>> > >> < francisco.diaztrepat@gmail.com> wrote:
>> > >> > Wait a minute, I am creating the jira but when do I upload the
>> > >> code?
>> > >>
>> > >> Right after you created it.
>> > >>
>> > >> Eelco
>> > >>
>> >
>> >
>> >
>> >
>>
>>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

I see you still claiming copy except for the comments. at least you
gave me that.
petty you fail to specify as I ask.

On 7/26/07, Janne Hietamäki <ja...@apache.org> wrote:
> Hi,
>
> I did not mean to criticise you in any way, but for sure there is a
> quite a lot of duplicate code/functionality in both javascript and
> java.  When I compare these two versions of javascript, most of the
> code is exactly equal (ok, you have added some comments). Duplicated
> code means always duplicated bugs, and that is always a bad thing.
> Specially with javascript is bad, because a new browser version tend
> to break things that have earlier been working just fine. When almost
> the same code is in two places, the work needed to fix all the bugs,
> test everything etc. is duplicated. Less is really more.
>
> I see no point of having alternate version of autocomplete for doing
> almost the same thing as the old one, that will only bloat the API
> and increases the amount of code. I would like to see the
> autocomplete extended so it can handle the use case you have. That
> should be quite straightforward thing to do, and really, you have
> already done that. Now we have to find a way to integrate you work
> into Wicket.
>
> Patches are a good thing, because now it seems you have worked with a
> version from the 1.2 branch, but trunk already has some fixes which
> your code does not contain. It's easier to handle the changes with
> patches, so we can see what you really have changed.
>
> Janne
>
>
> On 26.7.2007, at 21.39, Francisco Diaz Trepat - gmail wrote:
>
> > Janne I thought some more about this mail. And I wanted to say a
> > couple of things:
> >
> > 1) It is not my intention in any way to replace the code for the
> > auto-complete you and Igor developed.
> >
> > 2) It is not my intention to criticise it either.
> >
> > 3) I had to develop an alternative, as I wrote in the code, I based
> > the extensible autocomplete code on the one that you and Igor
> > developed.
> >
> > 4) Here are some Print Screens taken to the Open Source WinMerge
> > application on the tree key files which are the JavaScript, the
> > Abstract extension of the AbstractDefaultAjaxBehavior and the
> > extension of that that implements the renderer interface. As you
> > might notice the codes are far from similar and far far far far
> > away from a copy paste.
> >
> > 5) If a patch is the proper thing to upload instead of whatever I
> > did, then please tell me and I'll be more than happy to follow the
> > procedure, although it was not my intention to submit a patch to
> > anything, just a new feature based on an existing one.
> >
> > To finish up, If some where on the way of contributing this
> > autocomplete version I steped on anybodies toes then I am sorry and
> > can bet that it was not intended at all. I am not here to compete
> > in any way with anybody.
> > Wicket struck awesome to me and to my team mates as well. And
> > inspire me and them to help out whenever possible without
> > compromising company policies. We hope to be able to keep
> > contributing but don't want to get wrong impressions.
> >
> > Respectfully,
> > Francisco Díaz Trepat
> >
> >
> > On 7/25/07, Francisco Diaz Trepat - gmail
> > <fr...@gmail.com> wrote:
> > Would you be a bit more specific please?
> >
> >
> > I thought I rewrote most of it. Perhaps I am mistaken.
> >
> >
> > Which part?
> >
> >
> > Best Wishes,
> > f(t)
> >
> >
> > On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
> > Hi,
> >
> > 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 and try to integrate the code with the
> > old autocomplete. Also, patches would be nicer.
> >
> > Janne
> >
> > On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
> >
> > > I'm such a user... So anxious some times...
> > >
> > > Thanks, I have now attached a file named AutocompleteTestCase.rar
> > > (badly
> > > named, but...) with the code and a page with 3 samples.
> > >
> > > Until I am a master in maven and contribute some more, please be
> > > patient
> > > with details, like not putting all in the quick-start given sample
> > > (as igor
> > > suggested correctly). I'll get there.
> > >
> > > ++
> > >
> > > I'm still working in the code thinking now I am going to add two
> > more
> > > features to it:
> > >
> > > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> > > *Selects the choice without further need of interaction if only one
> > > choice
> > > is returned by the ajax call. Good for zipcodes, areacode,  and
> > > general code
> > > data entry.*
> > >
> > > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> > > the server
> > > to look up choices. Again good for zipcodes, and general code
> > > entering data
> > > entry slaves who usually enter data very fast.
> > >
> > > regards,
> > >
> > > f(t)
> > >
> > >
> > > On 7/25/07, Eelco Hillenius < eelco.hillenius@gmail.com > wrote:
> > >>
> > >> On 7/25/07, Francisco Diaz Trepat - gmail
> > >> < francisco.diaztrepat@gmail.com> wrote:
> > >> > Wait a minute, I am creating the jira but when do I upload the
> > >> code?
> > >>
> > >> Right after you created it.
> > >>
> > >> Eelco
> > >>
> >
> >
> >
> >
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Janne Hietamäki <ja...@apache.org>]

Hi,

I did not mean to criticise you in any way, but for sure there is a  
quite a lot of duplicate code/functionality in both javascript and  
java.  When I compare these two versions of javascript, most of the  
code is exactly equal (ok, you have added some comments). Duplicated  
code means always duplicated bugs, and that is always a bad thing.  
Specially with javascript is bad, because a new browser version tend  
to break things that have earlier been working just fine. When almost  
the same code is in two places, the work needed to fix all the bugs,  
test everything etc. is duplicated. Less is really more.

I see no point of having alternate version of autocomplete for doing  
almost the same thing as the old one, that will only bloat the API  
and increases the amount of code. I would like to see the  
autocomplete extended so it can handle the use case you have. That  
should be quite straightforward thing to do, and really, you have  
already done that. Now we have to find a way to integrate you work  
into Wicket.

Patches are a good thing, because now it seems you have worked with a  
version from the 1.2 branch, but trunk already has some fixes which  
your code does not contain. It's easier to handle the changes with  
patches, so we can see what you really have changed.

Janne


On 26.7.2007, at 21.39, Francisco Diaz Trepat - gmail wrote:

> Janne I thought some more about this mail. And I wanted to say a  
> couple of things:
>
> 1) It is not my intention in any way to replace the code for the  
> auto-complete you and Igor developed.
>
> 2) It is not my intention to criticise it either.
>
> 3) I had to develop an alternative, as I wrote in the code, I based  
> the extensible autocomplete code on the one that you and Igor  
> developed.
>
> 4) Here are some Print Screens taken to the Open Source WinMerge  
> application on the tree key files which are the JavaScript, the  
> Abstract extension of the AbstractDefaultAjaxBehavior and the  
> extension of that that implements the renderer interface. As you  
> might notice the codes are far from similar and far far far far  
> away from a copy paste.
>
> 5) If a patch is the proper thing to upload instead of whatever I  
> did, then please tell me and I'll be more than happy to follow the  
> procedure, although it was not my intention to submit a patch to  
> anything, just a new feature based on an existing one.
>
> To finish up, If some where on the way of contributing this  
> autocomplete version I steped on anybodies toes then I am sorry and  
> can bet that it was not intended at all. I am not here to compete  
> in any way with anybody.
> Wicket struck awesome to me and to my team mates as well. And  
> inspire me and them to help out whenever possible without  
> compromising company policies. We hope to be able to keep  
> contributing but don't want to get wrong impressions.
>
> Respectfully,
> Francisco Díaz Trepat
>
>
> On 7/25/07, Francisco Diaz Trepat - gmail  
> <fr...@gmail.com> wrote:
> Would you be a bit more specific please?
>
>
> I thought I rewrote most of it. Perhaps I am mistaken.
>
>
> Which part?
>
>
> Best Wishes,
> f(t)
>
>
> On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
> Hi,
>
> 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 and try to integrate the code with the
> old autocomplete. Also, patches would be nicer.
>
> Janne
>
> On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
>
> > I'm such a user... So anxious some times...
> >
> > Thanks, I have now attached a file named AutocompleteTestCase.rar
> > (badly
> > named, but...) with the code and a page with 3 samples.
> >
> > Until I am a master in maven and contribute some more, please be
> > patient
> > with details, like not putting all in the quick-start given sample
> > (as igor
> > suggested correctly). I'll get there.
> >
> > ++
> >
> > I'm still working in the code thinking now I am going to add two  
> more
> > features to it:
> >
> > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> > *Selects the choice without further need of interaction if only one
> > choice
> > is returned by the ajax call. Good for zipcodes, areacode,  and
> > general code
> > data entry.*
> >
> > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> > the server
> > to look up choices. Again good for zipcodes, and general code
> > entering data
> > entry slaves who usually enter data very fast.
> >
> > regards,
> >
> > f(t)
> >
> >
> > On 7/25/07, Eelco Hillenius < eelco.hillenius@gmail.com > wrote:
> >>
> >> On 7/25/07, Francisco Diaz Trepat - gmail
> >> < francisco.diaztrepat@gmail.com> wrote:
> >> > Wait a minute, I am creating the jira but when do I upload the
> >> code?
> >>
> >> Right after you created it.
> >>
> >> Eelco
> >>
>
>
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Eelco Hillenius <ee...@gmail.com>]

> 3.  sounds great. I'll throw away netbeans and start working with
> eclipse. sounds pretty straight forward.

That's pretty drastic :) I think you can do this with Netbeans as
well. Save the diff as a patch (see
http://subversion.netbeans.org/teepee/functional-spec.html).

Eelco

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

1. I'm on my cel with the gmail mobile app.

2. Once again, sad.

3.  sounds great. I'll throw away netbeans and start working with
eclipse. sounds pretty straight forward.


4. Don't mind having my code reviewed and criticised. its good to get pointers.

thanks igor,
f(t)

On 7/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> 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
>
> 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
> > >
> >
> >
> >
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Igor Vaynberg <ig...@gmail.com>]

On 7/26/07, Tim O'Brien <to...@discursive.com> wrote:
>
>
> If you don't use Eclipse,


thats crazy talk! :)

-igor

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

thanks a lot i'll look it up.

On 7/26/07, Tim O'Brien <to...@discursive.com> wrote:
> below...
>
> On 7/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> > 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
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Tim O'Brien <to...@discursive.com>]

below...

On 7/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> 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

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Igor Vaynberg <ig...@gmail.com>]

On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
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

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
> >
>
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

My comments.


On 7/26/07, Igor Vaynberg <ig...@gmail.com> wrote:

> On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> wrote:
> >
> > To finish up, If some where on the way of contributing this autocomplete
> > version I steped on anybodies toes then I am sorry and can bet that it
> was
> > not intended at all. I am not here to compete in any way with anybody.
> >
>
> heh
>
> i dont think this is what janne meant at all.


 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"

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
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Igor Vaynberg <ig...@gmail.com>]

On 7/26/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
wrote:
>
> To finish up, If some where on the way of contributing this autocomplete
> version I steped on anybodies toes then I am sorry and can bet that it was
> not intended at all. I am not here to compete in any way with anybody.
>

heh

i dont think this is what janne meant at all. 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.
screenshots are nice (the mailing list stripped them btw) but having those
differences open inside an ide is much better.

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.

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.

-igor

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Janne I thought some more about this mail. And I wanted to say a couple of
things:

1) It is not my intention in any way to replace the code for the
auto-complete you and Igor developed.

2) It is not my intention to criticise it either.

3) I had to develop an alternative, as I wrote in the code, I based the
extensible autocomplete code on the one that you and Igor developed.

4) Here are some Print Screens taken to the Open Source WinMerge application
on the tree key files which are the JavaScript, the Abstract extension of
the AbstractDefaultAjaxBehavior and the extension of that that implements
the renderer interface. As you might notice the codes are far from similar
and far far far far away from a copy paste.

5) If a patch is the proper thing to upload instead of whatever I did, then
please tell me and I'll be more than happy to follow the procedure, although
it was not my intention to submit a patch to anything, just a new feature
based on an existing one.

To finish up, If some where on the way of contributing this autocomplete
version I steped on anybodies toes then I am sorry and can bet that it was
not intended at all. I am not here to compete in any way with anybody.
Wicket struck awesome to me and to my team mates as well. And inspire me and
them to help out whenever possible without compromising company policies. We
hope to be able to keep contributing but don't want to get wrong
impressions.

Respectfully,
Francisco Díaz Trepat


On 7/25/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
wrote:
>
> Would you be a bit more specific please?
>
> I thought I rewrote most of it. Perhaps I am mistaken.
>
>
> Which part?
>
>
> Best Wishes,
> f(t)
>
> On 7/25/07, Janne Hietamäki <janne@apache.org > wrote:
> >
> > Hi,
> >
> > 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 and try to integrate the code with the
> > old autocomplete. Also, patches would be nicer.
> >
> > Janne
> >
> > On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
> >
> > > I'm such a user... So anxious some times...
> > >
> > > Thanks, I have now attached a file named AutocompleteTestCase.rar
> > > (badly
> > > named, but...) with the code and a page with 3 samples.
> > >
> > > Until I am a master in maven and contribute some more, please be
> > > patient
> > > with details, like not putting all in the quick-start given sample
> > > (as igor
> > > suggested correctly). I'll get there.
> > >
> > > ++
> > >
> > > I'm still working in the code thinking now I am going to add two more
> > > features to it:
> > >
> > > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> > > *Selects the choice without further need of interaction if only one
> > > choice
> > > is returned by the ajax call. Good for zipcodes, areacode,  and
> > > general code
> > > data entry.*
> > >
> > > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> > > the server
> > > to look up choices. Again good for zipcodes, and general code
> > > entering data
> > > entry slaves who usually enter data very fast.
> > >
> > > regards,
> > >
> > > f(t)
> > >
> > >
> > > On 7/25/07, Eelco Hillenius <eelco.hillenius@gmail.com > wrote:
> > >>
> > >> On 7/25/07, Francisco Diaz Trepat - gmail
> > >> <fr...@gmail.com> wrote:
> > >> > Wait a minute, I am creating the jira but when do I upload the
> > >> code?
> > >>
> > >> Right after you created it.
> > >>
> > >> Eelco
> > >>
> >
> >
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Would you be a bit more specific please?
I thought I rewrote most of it. Perhaps I am mistaken.

Which part?

Best Wishes,
f(t)

On 7/25/07, Janne Hietamäki <ja...@apache.org> wrote:
>
> Hi,
>
> 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 and try to integrate the code with the
> old autocomplete. Also, patches would be nicer.
>
> Janne
>
> On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:
>
> > I'm such a user... So anxious some times...
> >
> > Thanks, I have now attached a file named AutocompleteTestCase.rar
> > (badly
> > named, but...) with the code and a page with 3 samples.
> >
> > Until I am a master in maven and contribute some more, please be
> > patient
> > with details, like not putting all in the quick-start given sample
> > (as igor
> > suggested correctly). I'll get there.
> >
> > ++
> >
> > I'm still working in the code thinking now I am going to add two more
> > features to it:
> >
> > *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> > *Selects the choice without further need of interaction if only one
> > choice
> > is returned by the ajax call. Good for zipcodes, areacode,  and
> > general code
> > data entry.*
> >
> > DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to
> > the server
> > to look up choices. Again good for zipcodes, and general code
> > entering data
> > entry slaves who usually enter data very fast.
> >
> > regards,
> >
> > f(t)
> >
> >
> > On 7/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >>
> >> On 7/25/07, Francisco Diaz Trepat - gmail
> >> <fr...@gmail.com> wrote:
> >> > Wait a minute, I am creating the jira but when do I upload the
> >> code?
> >>
> >> Right after you created it.
> >>
> >> Eelco
> >>
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Janne Hietamäki <ja...@apache.org>]

Hi,

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 and try to integrate the code with the  
old autocomplete. Also, patches would be nicer.

Janne

On 25.7.2007, at 23.14, Francisco Diaz Trepat - gmail wrote:

> I'm such a user... So anxious some times...
>
> Thanks, I have now attached a file named AutocompleteTestCase.rar  
> (badly
> named, but...) with the code and a page with 3 samples.
>
> Until I am a master in maven and contribute some more, please be  
> patient
> with details, like not putting all in the quick-start given sample  
> (as igor
> suggested correctly). I'll get there.
>
> ++
>
> I'm still working in the code thinking now I am going to add two more
> features to it:
>
> *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> *Selects the choice without further need of interaction if only one  
> choice
> is returned by the ajax call. Good for zipcodes, areacode,  and  
> general code
> data entry.*
>
> DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to  
> the server
> to look up choices. Again good for zipcodes, and general code  
> entering data
> entry slaves who usually enter data very fast.
>
> regards,
>
> f(t)
>
>
> On 7/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>
>> On 7/25/07, Francisco Diaz Trepat - gmail
>> <fr...@gmail.com> wrote:
>> > Wait a minute, I am creating the jira but when do I upload the  
>> code?
>>
>> Right after you created it.
>>
>> Eelco
>>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Sorry, also I hope I filled the JIRA fields like (it is an improvement, on
what version, etc) correctly.

And please write all the comments you like.

regards,
f(t)


On 7/25/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
wrote:
>
> I'm such a user... So anxious some times...
>
> Thanks, I have now attached a file named AutocompleteTestCase.rar (badly
> named, but...) with the code and a page with 3 samples.
>
> Until I am a master in maven and contribute some more, please be patient
> with details, like not putting all in the quick-start given sample (as igor
> suggested correctly). I'll get there.
>
> ++
>
> I'm still working in the code thinking now I am going to add two more
> features to it:
>
> *AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
> *Selects the choice without further need of interaction if only one choice
> is returned by the ajax call. Good for zipcodes, areacode,  and general code
> data entry.*
>
> DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to the
> server to look up choices. Again good for zipcodes, and general code
> entering data entry slaves who usually enter data very fast.
>
> regards,
>
> f(t)
>
>
>  On 7/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > On 7/25/07, Francisco Diaz Trepat - gmail
> > <francisco.diaztrepat@gmail.com > wrote:
> > > Wait a minute, I am creating the jira but when do I upload the code?
> >
> > Right after you created it.
> >
> > Eelco
> >
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

I'm such a user... So anxious some times...

Thanks, I have now attached a file named AutocompleteTestCase.rar (badly
named, but...) with the code and a page with 3 samples.

Until I am a master in maven and contribute some more, please be patient
with details, like not putting all in the quick-start given sample (as igor
suggested correctly). I'll get there.

++

I'm still working in the code thinking now I am going to add two more
features to it:

*AUTOSELECT_ON_ONE_RESULT* = true / false configuration;
*Selects the choice without further need of interaction if only one choice
is returned by the ajax call. Good for zipcodes, areacode,  and general code
data entry.*

DELAY_AJAX_CODE_MS = number of milliseconds to delay the call to the server
to look up choices. Again good for zipcodes, and general code entering data
entry slaves who usually enter data very fast.

regards,

f(t)


On 7/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 7/25/07, Francisco Diaz Trepat - gmail
> <fr...@gmail.com> wrote:
> > Wait a minute, I am creating the jira but when do I upload the code?
>
> Right after you created it.
>
> Eelco
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Eelco Hillenius <ee...@gmail.com>]

On 7/25/07, Francisco Diaz Trepat - gmail
<fr...@gmail.com> wrote:
> Wait a minute, I am creating the jira but when do I upload the code?

Right after you created it.

Eelco

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Wait a minute, I am creating the jira but when do I upload the code?


Sorry if too novice...

f(t)


On 7/25/07, Timo Rantalaiho <Ti...@ri.fi> wrote:
>
> On Tue, 24 Jul 2007, Francisco Diaz Trepat - gmail wrote:
> > I was supposed to open a JIRA but as I've never done this, I wanted to
> get
> > some instructions on how to do it.
>
> If you don't have an account to Apache Jira yet, create it
> here
>
> https://issues.apache.org/jira/secure/Signup!default.jspa
>
> Login here
>
> https://issues.apache.org/jira/secure/Dashboard.jspa
>
> and then click "CREATE NEW ISSUE".
>
> - Timo
>
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Timo Rantalaiho <Ti...@ri.fi>]

On Tue, 24 Jul 2007, Francisco Diaz Trepat - gmail wrote:
> I was supposed to open a JIRA but as I've never done this, I wanted to get
> some instructions on how to do it.

If you don't have an account to Apache Jira yet, create it 
here

  https://issues.apache.org/jira/secure/Signup!default.jspa

Login here

  https://issues.apache.org/jira/secure/Dashboard.jspa

and then click "CREATE NEW ISSUE".

- Timo

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Francisco Diaz Trepat - gmail <fr...@gmail.com>]

Sorry I wasn't @ the office or @home (sad)

I have the code + an example.

In a Netbeans project. Should I send it to you? Personally.

built is 3.4 MB

f(t)


On 7/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> where is the code?
>
> -igor
>
>
> On 7/24/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
> wrote:
> >
> > Hi, igor, or someone:
> >
> > I took the liberty in writing an extensible autocomplete behavior based
> on
> > the AutocompleteTextField by Janne (jannehietamaki).
> >
> >
> >
> > I was supposed to open a JIRA but as I've never done this, I wanted to
> get
> > some instructions on how to do it.
> >
> > For those not following. The idea is to have an autocomplete behavior
> that
> > allows you to have *key* and *value* if you need it. This is done by
> > either
> > including a hidden field or by adding an attribute to the
> > autocomplete-field, or it can be left out and works exactly like the one
> > that is know available in the extensions package. The thing started out
> as
> > the current implementation used a fixed "node path" to get the elements
> > that
> > needed to render select etc. Now it uses an option/choice name.
> >
> > To do this I had to re-write the JavaScript and All the abstract classes
> > so
> > I did a new package all together.
> >
> > And renamed all of the classes to have both of them without any
> conflicts.
> > I
> > also included a new collection class in the javascript to help out and I
> > putted on a Wicket.Collection "package", and also named this
> autocomplete
> > as
> > ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any
> > html markup you feel like and it will work (choose arrows etc),
> > *Choice* because
> > it can use key and value like a DropdownChoice, and *Autocomplete*
> because
> > it is an autocomplete.
> >
> > All naming convention might be wrong and some of my code might not make
> > the
> > grade for you guys, so what I would like is to have someone review it
> and
> > see if it is considered to be included somewhere.
> >
> > Wicket is awesome, I get lots of help all the time, and just want to
> > contribute.
> >
> > There are some algorithms in the JavaScript that didn't worked on IE 7
> and
> > IE 6 because of a well known issue on IE that is that it does not
> refresh
> > document DOM on the assignment of the innerHTML property of an element.
> > But
> > that is taken care of by using element.all collection that works for IE
> 7
> > and 6.
> >
> > Also my code is usually considered heavily commented so as I see wicket
> > code
> > in general is not, maybe the reviewer would have to erase some comments.
> >
> > Feel Free is the key. I want to contribute, keep contributing in the
> > future,
> > and learn a proper way not to step on any one's feet.
> >
> > Best regards,
> > f(t)
> >
>

Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review

[Igor Vaynberg <ig...@gmail.com>]

where is the code?

-igor


On 7/24/07, Francisco Diaz Trepat - gmail <fr...@gmail.com>
wrote:
>
> Hi, igor, or someone:
>
> I took the liberty in writing an extensible autocomplete behavior based on
> the AutocompleteTextField by Janne (jannehietamaki).
>
>
>
> I was supposed to open a JIRA but as I've never done this, I wanted to get
> some instructions on how to do it.
>
> For those not following. The idea is to have an autocomplete behavior that
> allows you to have *key* and *value* if you need it. This is done by
> either
> including a hidden field or by adding an attribute to the
> autocomplete-field, or it can be left out and works exactly like the one
> that is know available in the extensions package. The thing started out as
> the current implementation used a fixed "node path" to get the elements
> that
> needed to render select etc. Now it uses an option/choice name.
>
> To do this I had to re-write the JavaScript and All the abstract classes
> so
> I did a new package all together.
>
> And renamed all of the classes to have both of them without any conflicts.
> I
> also included a new collection class in the javascript to help out and I
> putted on a Wicket.Collection "package", and also named this autocomplete
> as
> ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any
> html markup you feel like and it will work (choose arrows etc),
> *Choice* because
> it can use key and value like a DropdownChoice, and *Autocomplete* because
> it is an autocomplete.
>
> All naming convention might be wrong and some of my code might not make
> the
> grade for you guys, so what I would like is to have someone review it and
> see if it is considered to be included somewhere.
>
> Wicket is awesome, I get lots of help all the time, and just want to
> contribute.
>
> There are some algorithms in the JavaScript that didn't worked on IE 7 and
> IE 6 because of a well known issue on IE that is that it does not refresh
> document DOM on the assignment of the innerHTML property of an element.
> But
> that is taken care of by using element.all collection that works for IE 7
> and 6.
>
> Also my code is usually considered heavily commented so as I see wicket
> code
> in general is not, maybe the reviewer would have to erase some comments.
>
> Feel Free is the key. I want to contribute, keep contributing in the
> future,
> and learn a proper way not to step on any one's feet.
>
> Best regards,
> f(t)
>