Thanks David, that sounds great, I'll get to work on it. Regards Scott
2008/6/23 David E Jones <[EMAIL PROTECTED]>: > > There is actually an alternate way of doing autocomplete that is easier, > and for now both will exist as the opinions and discussions around them have > diverged. > > On the drop-down element in the form widget there is a "type" attribute > that has two option: "traditional", "auto-complete-server". The > "traditional" one is the default. If you set it to "auto-complete-server" > then it will render a text box and when you start typing it will do a > server-side autocomplete and show options based on what has been typed in. > > The design goals are these: > > 1. setting this attribute is all that needs to be done to do an > autocomplete > 2. it is a variation of the drop-down because the query constraints to use > in the autocomplete are the same as are needed for a drop-down; when the > auto-complete query is done these constraints will be used plus one > additional constraint to filter the displayed fields (according to the > content of the description shown in drop-down/autocomplete box) > 3. no custom code is required; a generic event will be the target of the > background server request and it will simply include the name of the form > and the name of the field and the partial text entered as parameters, > leaving all control of the query constraints in the form definition (ie on > the drop-down element with the type="auto-complete-server" attribute); for > more security the session would be used with a key added as a session > attribute that would be specified in a request parameter and used to look > the field and form names in the session (preset by the form widget while > rendering); that is important because security is normally controlled in > views using screen section conditions, and those would be skipped when > getting autocomplete options, opening the door to spoofing parameters > > In general the idea with the form and screen widgets are to make things as > easy as possible, requiring no additional programming to have access to > features, just specify the options desired. > > The XSD has been modified for the above, and someone was going to work on > implementing this after the initial commit to the XSD, but I guess it hasn't > been finished yet (I took at peek at the ModelFormField.DropDown class and > didn't see anything there yet). > > -David > > > > > On Jun 22, 2008, at 1:40 PM, Scott Gray wrote: > > Hi Adrian >> >> Thanks for explanation, but isn't an autocomplete something that could >> just >> as easily be used in a swing environment? I don't see anything about it's >> behaviour that is ajax specific. The more I think about it I see can't >> why >> we don't just have an autocomplete element, all we'd be telling the >> platform >> specific renderer to do is take the user input and search a list of values >> for any matches then show them to the user so they can select one. >> >> Regards >> Scott >> >> 2008/6/23 Adrian Crum <[EMAIL PROTECTED]>: >> >> --- On Sun, 6/22/08, Scott Gray <[EMAIL PROTECTED]> wrote: >>> >>>> While we're (sort of) on the topic of the >>>> autocomplete, does anybody really >>>> find the following intuitive? >>>> <field name="exampleFeatureId" >>>> id-name="exampleFeatureId"> >>>> <text/> >>>> <on-field-event-update-area >>>> event-type="change" >>>> area-id="exampleFeatureId" >>>> area-target="findExampleFeatures"/> >>>> </field> >>>> >>> >>> The ajax stuff is still being developed. One thing that was suggested was >>> to have an additional attribute to describe the type of server-side >>> action: >>> >>> <on-field-event-update-area >>> event-type="change" >>> area-id="exampleFeatureId" >>> area-target="findExampleFeatures" >>> server-action="autocomplete"/> >>> >>> I can't think of a better element name. It's expressing "On a field >>> event, >>> update an area of the screen." >>> >>> The event type (in the HTML world) would be either change or click. >>> >>> The area id is the area (HTML container) to be updated when the event >>> occurs. >>> >>> The area target is the URL called to update the area specified in >>> area-id. >>> >>> The server action is a description of what type of response the server >>> will >>> put in the area. >>> >>> If anyone has suggestions for better names, then this is a good time to >>> make them - before we get any further into Ajax development. Just keep in >>> mind that the syntax shouldn't be Ajax-specific - because the widgets are >>> intended to support more than one rendering format. Also keep in mind >>> that >>> more than one ajax event can be triggered by a field event. >>> >>> -Adrian >>> >>> >>> >>> >>> >>> >
