PDA

View Full Version : Autocomplete text form fields?



FB
23 Feb 2007, 7:34 AM
Hi Jack and all the Ext Community,

Firstable, congratulations for your great work.

Now a question. Is there any plan for autocomplete text form fields?

Kind regards,

Fernando

Webnet
23 Feb 2007, 7:56 AM
This would be HOT!!

FB
23 Feb 2007, 8:03 AM
More specifically, I would like to add dinamically (by javascript) autocomplete behaviour to certain (selected by class) text fields of a form created by simple HTML markup in the server side (JSP).

Fernando

gordon
23 Feb 2007, 8:16 AM
Jack,

We would also like to have a control like this. In fact you may recall you helped us to implement such a beast based on the YUI AutoComplete back in December.

Our requirements may be slightly different from Fernando's. Specifically, we want to:
* restrict the choice to a limited set of options
* populate the set of options synchronously (inline) or asynchronously via JSON
* require a configurable number of letters be typed before an asynchronous request is made
* support keyboard navigation
* operable by mouse also

I will attempt to implement this for my project myself next week. However, some documentation on how to create a custom editor and integrate it into a grid would be most welcome.

Thanks,

Gordon

p.s. I've got a read-only grid largely working with Ext 1.0. Now for the editable version!

jack.slocum
23 Feb 2007, 2:10 PM
That's fantastic Gordon. I'm glad to hear it.

I have question for you guys. How would you feel if the AC required a data store for loading? This way it supported all of the options (http, in memory, xml, json, array, etc) and added support for complex types (which I know you need Gordon). Obviously implementing a store is a little more long winded than implementing a simple json loader - but imagine how much power there could be.

If the store is ok, then it makes it easier for me. Let me know what you guys think.

FB
23 Feb 2007, 2:40 PM
That's fantastic Gordon. I'm glad to hear it.

I have question for you guys. How would you feel if the AC required a data store for loading? This way it supported all of the options (http, in memory, xml, json, array, etc) and added support for complex types (which I know you need Gordon). Obviously implementing a store is a little more long winded than implementing a simple json loader - but imagine how much power there could be.

If the store is ok, then it makes it easier for me. Let me know what you guys think.

Easier for you and more powerful... it seems is the way to do it!. In this case, what is the time frame are you considering?.

Another question, Will it be possible to provide AC behaviour to a text field previously created by HTML markup?

Thanks in advance Jack.

"Un admirador" of your work.

Fernando.

alindsay55661
23 Feb 2007, 2:43 PM
I definitely agree that a data store is the most desirable solution.

JeffHowden
23 Feb 2007, 4:27 PM
I'd like to add that I think it'd be nice if the autocomplete results were just a simple grid component so there was client-side sorting, column resizing (maybe), etc. It *might* be handy if it supported paging as well.

ilazarte
23 Feb 2007, 5:18 PM
As someone who went through the pain of implementing an autocomplete based of yui a while ago (without ext), I'll vote for this- and for the datastore option. There are so many parts where having this in Ext makes sense since a lot of it is built already. My own implementation took a lot of time, which was part rendering bugs and positioning.

The options I would like to see:
1. the templating of the return html / the same fantastic themeing we see in other ext items.
2. configurable time delay after last keypress before sending the request.
3. configurable max number of displayable results
4. shim so it works over select
5. effects configuration, (how it renders and destroys)

sounds like a lot, but considering how much low-level stuff Ext has taken care of already, it should be not so bad at all.

trbs
23 Feb 2007, 8:43 PM
That's fantastic Gordon. I'm glad to hear it.
If the store is ok, then it makes it easier for me. Let me know what you guys think.

i am all in favor of the store 8)

Animal
23 Feb 2007, 11:05 PM
Yes, use an Ext.data.Store. The consistency in Ext 1.0 is great now. We'll all soon get used to Store objects using Proxys and Readers.

I just implemented an autocomplete using standard YUI.. Looks like I'll have to refactor that too!

zquirm
24 Feb 2007, 1:35 AM
what would be nice too is to be able to attach events to certain typed phrases. I mentioned something like this before in this thread: http://www.yui-ext.com/forum/viewtopic.php?t=963

That way, in addition to everything that's being loaded from json (or whatever), you could have key phrases that not only auto complete, but trigger an event.

For example, lets say you have a car database and you're typing in an auto complete field that's connected to this database for certain types of cars. But if you type "deals", then an event is triggered to load car ad deals in the page. Or if they type "chevy", then maybe an info box about chevy's new line up appears.

I think there would be a lot of ways to use this.

thoughts?

lstroud
24 Feb 2007, 11:47 PM
That would be great.

I second the desire for it to be a grid. Having multiple columns, with column headers, in the autocomplete would be very nice to have.

Belgabor
25 Feb 2007, 7:51 AM
I don't think it was meant to be a grid, only to use the new database interaction layer of Ext 1 which, I gather, is designed for much more that "just" for the grid.
I second the datastore idea. I also think a paging interface (up down arrows for example) would be nice for the AC choices.

gordon
26 Feb 2007, 12:37 AM
If the store is ok, then it makes it easier for me. Let me know what you guys think.

Basing the autocomplete on a datastore seems very sensible to me. And it feels right too - you know you've got a well factored component when the right choice is also the easiest choice.

Thanks,

Gordon

mystix
26 Feb 2007, 12:40 AM
I second the store.

mnugter
27 Feb 2007, 2:39 AM
It doesn't use a store, the javascript is a bit `unclean` and buggy, you have to use XHTML 1.0 because of some css bugs but apart from all that I have a working combobox example :)

http://www.dinnersite.nl/ext/combo.php

Maby nice for some inspiration.

It uses the Jsonview class to display the list. The json-source returns an array for each item in the list containing a key and a value. It supports key-navigation (up, down, pageup, pagedown).

When you add this to your form it will be submitted in two parts, the original input element will contain the key, a new element with the name of the original element with -display appended will contain the displayed value.

EDIT: I limited the results serverside to 50.

KimH
27 Feb 2007, 3:30 AM
As everyone else says it would be great to have the datastore.

I currently use the WICK (Web Input Completion Kit) from http://wick.sourceforge.net/ in a textarea where the user can write names of people that should have access to the content. WICK doesn't, however, support entering a new name on a new line (after a carriage-return) and nor does it support inserting a new line between two names and start typing a third name. It only supports you writing new names at the end of a long list... making it hard to read and not very user-friendly. What I would love to have is some way to have auto-completion to not only simple text-fields and combobox'es but also in textarea's.

When the user is typing it should be possible to have the suggested list of entries to include columns (sortable) as well as images.

jack.slocum
27 Feb 2007, 8:35 AM
mnugter, that looks pretty nice. I also have a combo built somewhere but the code does support a store or loading at the moment. And I imagine I will be using some kind of view as well :)

SteveEisner
27 Feb 2007, 8:42 AM
I can guarantee you a new commercial license if you build an "unobtrusive" auto-complete control with comparable functionality to something like a ComponentArt or Telerik dropdown. No need for the fanciest stuff like multi-column dropdowns

Primary concerns:
* low overhead in HTML - can be added to a normal INPUT type="text" by JS code
* support for multiple on one page (10-20)
* testable by Selenium IDE
* skinnable with CSS
* good keyboard support (or at least let us hook in keyboard support ourselves)

jack.slocum
27 Feb 2007, 9:16 AM
All are reasonable except I've never heard of this one "testable by Selenium IDE". Let me hit google.

jack.slocum
27 Feb 2007, 9:17 AM
Hmm, how could I not have that? :shock:

FB
27 Feb 2007, 10:59 AM
* low overhead in HTML - can be added to a normal INPUT type="text" by JS code


Again, I support this! :wink:

simeon
27 Feb 2007, 11:12 AM
Jack if your investigating testing apps. The QA guy here says he has had better success using sahi:

http://sahi.co.in/

Not sure why he didn't like Selenium ...

Simeon

SteveEisner
27 Feb 2007, 4:39 PM
Jack - to clarify, I would have assumed that too. Unfortunately, it seems like there are real issues out there:

http://www.telerik.com/community/forums/thread/b311D-tbkgb.aspx
http://www.telerik.com/community/forums/thread/b311D-gehhh.aspx
http://72.14.203.104/search?q=cache:4J-DqODwwWMJ:osdir.com/ml/gmane.comp.web.selenium.user/2006-11/msg00034.html+componentart+selenium&hl=en&ct=clnk&cd=1&gl=us
etc.

It seems like Selenium IDE (the automatic test recorder) has issues locating testable items if they don't have IDs and such. Just wanted to bring it up!

Thanks,
Steve

San
27 Feb 2007, 5:48 PM
Autocomplete in textareas (ala gmail email address completion) would be sweet.


As everyone else says it would be great to have the datastore.

I currently use the WICK (Web Input Completion Kit) from http://wick.sourceforge.net/ in a textarea where the user can write names of people that should have access to the content. WICK doesn't, however, support entering a new name on a new line (after a carriage-return) and nor does it support inserting a new line between two names and start typing a third name. It only supports you writing new names at the end of a long list... making it hard to read and not very user-friendly. What I would love to have is some way to have auto-completion to not only simple text-fields and combobox'es but also in textarea's.

When the user is typing it should be possible to have the suggested list of entries to include columns (sortable) as well as images.

mnugter
28 Feb 2007, 1:44 AM
I can guarantee you a new commercial license if you build an "unobtrusive" auto-complete control with comparable functionality to something like a ComponentArt or Telerik dropdown. No need for the fanciest stuff like multi-column dropdowns

Primary concerns:
* low overhead in HTML - can be added to a normal INPUT type="text" by JS code


As you can see in the source the only thing required is to have an input element with an ID and one line of javascript.



* support for multiple on one page (10-20)


I haven't tried 10-20 on 1 page but I do have three of them in one page, works fine.

EDIT: Well, as you can see, I updated the example and there are now 15 comboboxes on the page. I did find another small bug in the list (no background and incorrect positioning).



* testable by Selenium IDE


I have no idea. I tried running the firefox plugin but I don't really understand what I'm possosed to do with it.



* skinnable with CSS


Well, I fully skinned it with css, just overwrite the css classes and you can skin it yourself :) Maby I should drop the span around the input field, that's just because the rest of our input fields are styled that way.
The css bugs for html 4.01 are still there btw.



* good keyboard support (or at least let us hook in keyboard support ourselves)


Well, I have some keyboard support, I can only imagine the LEFT and RIGHT keys to page in the results. Now that I mention paging, maby I should support this :)


I would like to use the datastore but I just don't see yet how I can implement this. I'd also like to append the paging toolbar to the dropdown list but I'm not sure how to add this exactly. If anyone can give me some pointers for the datastore and the paging I'd be happy to update my example.

Oh and Jack, any suggestions on improving my Javascript? I did update it to make it a little more efficient and I added a lot of comments. I also fixed a bug in the autocomplete function.

SteveEisner
28 Feb 2007, 5:17 AM
Thanks! That looks great, and I really like your unobtrusive code. There are some little fit & finish details such as not popping down the combo when you hit the down key, etc. but I'm sure it'll be easy to clean up since it already works so well ;)

Note also that there can be some interesting behavior issues when you start matching against more than just a prefix. Imagine your typeahead could match against the city, not just the street, and you'll see what I mean. Our app does need this, which is something I hadn't thought of in my original list of requirements. Gmail's compose window typeahead is a good model for the correct behavior...

If something like this becomes a fully supported part of Ext (hope you understand, for my client it has to be "official") then we're most of the way to not needing Telerik controls at all - a pattern-masked input box like "(###) ###-####" is the only other control we use that's not supported in Ext yet.

We're still waiting on the Ext 1.0 final before they can really do the evaluation but this library is really shaping up! They weren't expecting to use it as a component library, just for border layout, so it's a pleasant surprise :)

mnugter
28 Feb 2007, 5:37 AM
Thanks! That looks great, and I really like your unobtrusive code. There are some little fit & finish details such as not popping down the combo when you hit the down key, etc. but I'm sure it'll be easy to clean up since it already works so well ;)

Thanks :) About the popping down, the list that pops down when clicking on the expand button is just the list without any filter. Should I update this to filter the value in the input field?

I will match the behavior of the down key to the expand button (when the list is not expanded).



Note also that there can be some interesting behavior issues when you start matching against more than just a prefix. Imagine your typeahead could match against the city, not just the street, and you'll see what I mean. Our app does need this, which is something I hadn't thought of in my original list of requirements. Gmail's compose window typeahead is a good model for the correct behavior...


Nice idea, but how would I implement the autocomplete in this case?

The data returned is dependant on the query to execute serverside. Now I perform a LIKE 'value%' WHERE statement, you can change this to '%value%' to represent your search mode.

Ofcourse, the autocomplete feature would be impossible. Should I implement an option to disable autocomplete?



If something like this becomes a fully supported part of Ext (hope you understand, for my client it has to be "official") then we're most of the way to not needing Telerik controls at all - a pattern-masked input box like "(###) ###-####" is the only other control we use that's not supported in Ext yet.


I wouldn't recommend using it in any application yet, it hasn't even been tested properly, css breaks in html 4.01 and I have no idea if it works in safari/opera/ie7 (works in ff2 and ie6 though :)).

EDIT: The masked input got me thinking, I want that too. I found something here:
http://jsfromhell.com/forms/masked-input

Maby it's a good starting point for an Ext implementation. Man I hate/love regular expressions..



We're still waiting on the Ext 1.0 final before they can really do the evaluation but this library is really shaping up! They weren't expecting to use it as a component library, just for border layout, so it's a pleasant surprise :)

Ext sure is looking amazing, every day I'm amazed at the power of this library. I tried making the combobox before but it was simply too much work (and my javascript knowledge was just not enough) but with Ext it was even fun to do :)




EDIT: Btw, anyone any idea how to nicely(!) solve the css bug in doctype HTML 4.01?

mnugter
28 Feb 2007, 7:26 AM
Another thing that is bugging me, any idea for a better solution that the div element to position the image? I don't like it because the div is rendered as a block and therefore I have to use a table to position it next to a label.

I used the div because the image is placed too high if I just place the image tag next to the input element.

jack.slocum
28 Feb 2007, 8:58 AM
Use an Ext.BLANK_IMAGE_URL image, set it's height as the same as the input field and use a css background image to actually apply the image. Position the css background image in the center and voila.

SteveEisner
28 Feb 2007, 10:21 AM
I like Jack's suggestion.
In the past I have done something else: style the input field itself. I give it a right-side padding, and then a background image that is right justified and vertically centered. Such an icon will appear inside the text box.
But I have never done this in a way where I would need to monitor clicks on the icon itself (I suppose you could test event.X etc. to see whether it's "so far" from the edge) Nor have I tested this cross-browser...

jack.slocum
28 Feb 2007, 10:22 AM
Safari won't allow background images on text fields. :(

SteveEisner
28 Feb 2007, 11:35 AM
Nice idea, but how would I implement the autocomplete in this case?
The data returned is dependant on the query to execute serverside. Now I perform a LIKE 'value%' WHERE statement, you can change this to '%value%' to represent your search mode.
Ofcourse, the autocomplete feature would be impossible. Should I implement an option to disable autocomplete?

Well, in our case we are using a search engine to match results so we actually are not concerned about the server-side code, but I can see how it would be difficult as a SQL statement. You could always test it with LIKE 'value%' OR LIKE '% value%' but that's gonna be slower ;)

As you point out, we don't need auto-complete, I guess we need what could be called "auto-completion". The ability to type whatever you want, with it automatically suggesting a list under the input box from which you can select with the up and down keys + enter. When you select the item the entire input is replaced with the selected value.

An even better typeahead/combo control would simulate the "display text vs. value" that is available from combos and lists. So as you are editing the text box, a hidden field is set to the list value that corresponds to that display text. This lets you have a display name match a code or unique ID, etc.


EDIT: The masked input got me thinking, I want that too. I found something here:
http://jsfromhell.com/forms/masked-input
Very nice! Thanks

SteveEisner
28 Feb 2007, 11:36 AM
Safari won't allow background images on text fields. :(
Ah, yeah, of course ... rounded inputs :( Thanks

mnugter
1 Mar 2007, 12:57 AM
I updated the combobox again: css-fixes, down-arrow opens the list (without any filter), it now works in HTML 4.01 :) and I removed some of the elements (no containing div and no span around the input field).


Use an Ext.BLANK_IMAGE_URL image, set it's height as the same as the input field and use a css background image to actually apply the image. Position the css background image in the center and voila.

Well it works but now I have to give the input field a bottom margin of 5px (ie6: 4px) to make the image align properly. Positioning the background image doesn't work completely either, the bottom part of the image simply disappears. Any suggestions on fixing this without the bottom margin?



Well, in our case we are using a search engine to match results so we actually are not concerned about the server-side code, but I can see how it would be difficult as a SQL statement. You could always test it with LIKE 'value%' OR LIKE '% value%' but that's gonna be slower ;)


I updated my example to do different fetches on the server (the second combobox now does a LIKE '%value%' query.



As you point out, we don't need auto-complete, I guess we need what could be called "auto-completion". The ability to type whatever you want, with it automatically suggesting a list under the input box from which you can select with the up and down keys + enter. When you select the item the entire input is replaced with the selected value.


I added a config option to disable the auto-complete (enabled by default).



An even better typeahead/combo control would simulate the "display text vs. value" that is available from combos and lists. So as you are editing the text box, a hidden field is set to the list value that corresponds to that display text. This lets you have a display name match a code or unique ID, etc.


You really should have tried to place it in a form, this was already supported :) the combobox changes the name and the id of the input-element (it adds -display) and adds a hidden input element with the original id and name.

The default value of the input field is set through javascript, as shown by the third combobox example. You have to supply the value and key as configuration parameters. I did it this way because there is no room in the input field to contain two seperate values and I don't want to query the server just to fetch the value corresponding to the supplied key.


The only things remaining (?) are paging and using a datastore (paging should be much easier when using the datastore).

mnugter
1 Mar 2007, 2:40 AM
Well, after another 1,5 hours of coding I added and changed the following:

* Now using Ext.View instead of Ext.Jsonview
* A Ext.data.Store is now used for retrieving the data (a custom store can be passed through the config, defaults to a json-http-oriented store)
* added paging support (can be disabled by setting paging to false in the config)
* Ext.apply is used for the for the configuration.
* autocomplete is renamed to typeahead
* pageSize configuration added
* defaults is renamed to defaultValues


the config now accepts:


pageSize: 50 //number of results displayed in the list
url: 'url' //datastore url (required if the store is not provided)
store: Ext.Data.Store //(optional) The store used for the list (the combobox creates a default json-http-oriented store with root: data and totalProperty: count). If supplied the recordset should consist of a `key` field and a `value` field
paging: true //true to enable paging, false to disable paging
typeahead:true //True to enable typeahead, false to disable typeahead
defaultValues: {key: 'key', value: 'value'} //The default values.



There are some bugs/missing features. The key-navigation doesn't work yet when you used the paging toolbar and I want the LEFT and RIGHT arrows to trigger the paging.

EDIT: Just though the LEFT and RIGHT through, we don't want this. If it triggers paging your can't use the arrows in the input field itself to navigate your cursor :)


Btw Jack: Is it a bug that the background of the paging toolbar is not visible in ie6? If I remove the background color from the paging container div the paging toolbar is transparent. I also noticed that the Store fires the load event while the proxy has fired the loadexception event, shouldn't the load event be prevented when the loadexception event is fired?

Now that the component is more complete can you please check if the source out? I'm very curious what you would have done differently or just plain don't like :)

medium
1 Mar 2007, 3:43 AM
Hi mnugter, nice work with the autocomplete.

What do you think about changing the url to a function rather then using static string. There are times (my current use case) where you need to append stuff to the url which is on the form (i.e user can change before autocompleting).

Thanks

Huy

mnugter
1 Mar 2007, 4:53 AM
The Store itself supports the possibility to alter the baseParams of the request. This way you can add any parameter to the url.
I actually had to update the combobox to alter the baseParams because the pagingtoolbar ignored the filter value when paging.

You can easily access the baseParams:



var combo1 = new Ext.Combobox('combo_test1', {url: 'combo_source.php'});
combo1.store.baseParams.testParam = true;


I updated the example to demonstrate this feature.


EDIT: I updated the css, it now uses the .ext_ie class to specify the ie css. no more css hacks are used.

EDIT2: As per earlier requests (by gorden/ilazarte) I added two configuration options:

* minCharacters: 1, Minimal number of characters before triggering a load
* autocompleteDelay: 500, Number of milliseconds before triggering a load

medium
1 Mar 2007, 5:51 AM
Thanks for pointer with the baseParams. However, is it not better to have a more declarative approach.

eg.


function getURL() {
return "datasource.php?selectCountry=" + Ext.get('selectCountry').value
}

var combo1 = new Ext.Combobox('city', {url: getURL});

so depending on the current value of the country select box, the city autocomplete will append the relevant country onto the url. With the previous method you outlined, I would have to put an onchange event on the selectbox to change the parameter. I think this is more intrusive and can get much uglier when you have more fields which are part of the filter.

One other issue I had with the autocompleter. The part where you are creating the hidden element. I had to change to this to make it work for me.

//Change the id and name of the original input field. We add a hidden field to provide the value (key)

var oldId = this.el.dom.id;
var oldName = this.el.dom.name;

this.el.dom.id = this.id + '-display';
this.el.dom.autocomplete = 'off'; //We handle this ourselfs.
this.el.dom.name = this.id + '-display';
this.el = Ext.get(this.id + '-display');

//Create the element that will contain the key value
this.hiddenEl = Ext.DomHelper.insertAfter(this.el,
{tag: 'input', type:'hidden', id: oldId, name: oldName},
true
);

mnugter
1 Mar 2007, 6:03 AM
I fixed the id/name issue, thanks for spotting the bug :)


About the url, I directly pass the url to the Store which creates a Ext.data.Connection with this url. The Ext.data.Connection doesn't support altering the url after making the connection. As far as I can see it's therefore currently impossible to alter the url after setting up the Store.

Maybe this is a satisfactory solution to your problem (haven't tested it though):



var combo1 = new Ext.Combobox('combo_test1', {url: 'combo_source.php'});
combo1.store.on('beforeload', function(e) {
this.baseParams.selectCountry = Ext.get('selectCountry').value;
}, combo1.store);


EDIT: I changed the margin of the input box to zero and to compensate I added a negative bottom margin to the image (positioning of the button).

San
1 Mar 2007, 6:10 AM
Love it. How challenging would it be to allow multiple autocomplete in a TEXTAREA along the lines of Yahoo Mail or GMail when you enter in email addresses?

jack.slocum
1 Mar 2007, 11:07 AM
That's looking really nice. mnugter, any chance you have IM? I would love to help you work on this and incorporate it into Ext. I have a few suggestions, recommendations. I can send you my IM if you'd like. PM me.

FB
1 Mar 2007, 11:28 AM
Great work mnugter!

Just two comments:

- I think if the user deletes the some letters (e.g. pressing backspaces) the list update should be re-trigered

- When the mouse pointer is positioned over an option, this should be highlighted


Regards,

Fernando

SteveEisner
1 Mar 2007, 12:58 PM
Just wanted to add too: this is some really great work and I would love to see it incorporated into Ext. If my project load lightens a bit I may have some time to contribute as well (since I have so many requirements for the control :) )

medium
1 Mar 2007, 5:58 PM
Hi mnugter,

Theres another small problem I noticed.

You need to also save the old value and reassign to the created hidden value.

Belgabor
1 Mar 2007, 6:07 PM
One small problem: When you turn off typeahead, the full content of the edit box is selected as soon as the list is fetched successfully, so if you just continue typing, what you already had is erased.

I also added a small feature to make a displayed key input box possible:
- Replaced hiddenEl with keyElement
- Changed some code in the constructor to allow keyElement as config option:

if(typeof(this.keyElement) == 'object') {
// Leave as is
} else if (typeof(this.keyElement) == 'string') {
this.keyElement = Ext.get(this.keyElement);
} else { // Whatever it is, not something we can use.
//Change the id and name of the original input field. We add a hidden field to provide the value (key)

var oldId = this.el.dom.id, oldName = this.el.dom.name;
this.el.dom.id = this.id + '-display';
this.el.dom.autocomplete = 'off'; //We handle this ourselfs.
this.el.dom.name = this.id + '-display';
this.el = Ext.get(this.id + '-display');

//Create the element that will contain the key value
this.keyElement = Ext.DomHelper.insertAfter(this.el,
{tag: 'input', type:'hidden', id: oldId, name: oldName},
true
);
}

This is just indended to display the key, there is no reverse handling (meaning the key input box is supposed to be read only).

jack.slocum
1 Mar 2007, 6:42 PM
I have already started hacking at this (it was the next item on my list). Here are the key things I am doing:

- Replace custom key nav function with Ext.KeyNav so repeating and cancelling of events work cross browser.

- Change entire initialization to follow the Ext 1.0 Component model. It will actually be a subclass of Ext.form.TextField, allowing for dynamic/unobtrusive creation. This will also allow it to be used within an Ext.Editor and the the related GridEditor.

- Use Ext.Layer for the container, allowing for shimming, shadows and negative offsets (for FF Mac scrollbars) etc.

- Customizable templating

I would have to preferred to wait, but my deadline for the AC is Monday so there's no time to waste.

Belgabor
1 Mar 2007, 7:02 PM
As Jack now works on this I probably don't need to mention it, but this control lacks an event to signify a set key when a choice is made =)

mnugter
2 Mar 2007, 1:45 AM
I have already started hacking at this (it was the next item on my list). Here are the key things I am doing:

- Replace custom key nav function with Ext.KeyNav so repeating and cancelling of events work cross browser.

- Change entire initialization to follow the Ext 1.0 Component model. It will actually be a subclass of Ext.form.TextField, allowing for dynamic/unobtrusive creation. This will also allow it to be used within an Ext.Editor and the the related GridEditor.

- Use Ext.Layer for the container, allowing for shimming, shadows and negative offsets (for FF Mac scrollbars) etc.

- Customizable templating

I would have to preferred to wait, but my deadline for the AC is Monday so there's no time to waste.


That's perfect. I hope my code will help you along nicely :) I'm very curious what you will make of it. I was planning on some of the things you are doing now but I think you'd do a better job.

Eagerly awaiting your version of the combobox :)

FB
6 Mar 2007, 8:54 AM
I would have to preferred to wait, but my deadline for the AC is Monday so there's no time to waste.

Any news on it?

jack.slocum
6 Mar 2007, 6:39 PM
It's almost there. I am adding support for value/display (like a select) and then I need to get the examples/demos working. I got a litle caught up in the form stuff (which by the way are coming along nicely). I expect to put out a rev tonight/tomorrow morning.

jack.slocum
7 Mar 2007, 2:18 AM
Everything appears to be working well. I will put together a few examples of it and the new form stuff when I wake up (it's 5am) and get a new rev up tomorrow.

I added in a cool feature:


var tranny = new Ext.form.ComboBox({
typeAhead: true,
triggerAction: 'all',
transform:'light', // <-- replace select "light" with combo
forceSelection:true
});

So you can unobtrusively turn selects into filtering combos (that don't have the rendering issues).

This is particularly useful with grid editors where selects flicker and in general look terrible.

Here's an excerpt from the editor grid examples ColumnModel def:


,{
header: "Light",
dataIndex: 'light',
width: 130,
editor: new Ed(new Ext.form.ComboBox({
typeAhead: true,
triggerAction: 'all',
transform:'light',
lazyRender:true
}))
}

It "transforms" the original select box "light" into the combo and sets it to lazy render (required for "transformed" grid editors).

It's pretty flexible too. I have a working local "Live Forum Search" using the combo + a template:


var ds = new Ext.data.Store({
proxy: new Ext.data.HttpProxy({
url: '/forum2/topics-remote.php'
}),

// create reader that reads the Topic records
reader: new Ext.data.JsonReader({
root: 'topics',
totalProperty: 'totalCount',
id: 'topic_id'
}, [
{name: 'title', mapping: 'topic_title'},
{name: 'postId', mapping: 'post_id'},
{name: 'author', mapping: 'author'},
{name: 'excerpt', mapping: 'post_text'}
])
});

var combo = new Ext.form.ComboBox({
store: ds,
displayField:'title',
typeAhead: false,
loadingText: 'Searching...',
listWidth:600,
pageSize:10,
width:150,
tpl: '<div class="search-item"><h3><span>{lastPost:date("M j, Y")}
' +
'by {author}</span>{title}</h3>{excerpt}</div>',
title: 'Search Results',
onSelect: function(record, item){ // override default onSelect to do redirect
window.location = '/forum/viewtopic.php?t='+record.id+'#'+record.data.postId;
}
});

combo.applyTo('markup-combo');

Notice the Ext.Template format function. First time usage in an example. :D

KimH
7 Mar 2007, 3:01 AM
Hi Jack!

I can't see you are using the Ext.Template in your example :?

By the way... isn't Ext.Template already using in feedviewer.js, organizer.js and chooser.js? :wink:

San
7 Mar 2007, 3:08 AM
Check out the date format in the example he posted. Sweet.

BTW, Jack - does the JSON reader always need a root element? (if so, any reason we can't get rid of it?)


Hi Jack!

I can't see you are using the Ext.Template in your example :?

By the way... isn't Ext.Template already using in feedviewer.js, organizer.js and chooser.js? :wink:

jack.slocum
7 Mar 2007, 3:09 AM
Here's the template above:


tpl: '<div class="search-item"><h3><span>{lastPost:date("M j, Y")}
' +
'by {author}</span>{title}</h3>{excerpt}</div>'

This is a first example usage of Ext.Template format functions in an example. :) They allow you to use the prefined (or you can add your own) functions to format template variables. Above, I am formating the incoming date object (lastPost) into a nice date string. Take a look in this forum for aconran's link to a short tutorial about using the format functions.

FB
7 Mar 2007, 3:44 AM
It's almost there. I am adding support for value/display (like a select) and then I need to get the examples/demos working. I got a litle caught up in the form stuff (which by the way are coming along nicely). I expect to put out a rev tonight/tomorrow morning.

That's a real Wow!

Thanks a lot Jack.