Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
Locked
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
 
Administrator
|
Of course when I began to work on this I tried to use description-field-name but was unable to access it and discovered it was
useless in the autocomplete context. BTW using jQuery for this should be far easier as the http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/ is now part of jQuery.ui... Jacques From: <[hidden email]> > Author: jleroux > Date: Tue Sep 7 19:55:49 2010 > New Revision: 993508 > > URL: http://svn.apache.org/viewvc?rev=993508&view=rev > Log: > Introduces a very simple mean to set a dependent Id field when using a Name field as a lookup (the fields must have the same > prefix, eg: partyName, partyId). > It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a description in the > autocomplete part. > It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). > At least it easy to set and it works well for simples case for now (eg PartyGroup) > > I did not find another way since Ajax.Autocompleter can't update another field. > The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair. > But it's more difficult to demonstrate in Example component > > Modified: > ofbiz/trunk/framework/images/webapp/images/selectall.js > > Modified: ofbiz/trunk/framework/images/webapp/images/selectall.js > URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/images/webapp/images/selectall.js?rev=993508&r1=993507&r2=993508&view=diff > ============================================================================== > --- ofbiz/trunk/framework/images/webapp/images/selectall.js (original) > +++ ofbiz/trunk/framework/images/webapp/images/selectall.js Tue Sep 7 19:55:49 2010 > @@ -232,6 +232,7 @@ function confirmActionFormLink(msg, form > * @param target The URL to call to update the HTML container > * @param targetParams The URL parameters > */ > + > function ajaxUpdateArea(areaId, target, targetParams) { > waitSpinnerShow(); > new Ajax.Updater(areaId, target, {parameters: targetParams, evalScripts: true, > @@ -377,7 +378,23 @@ function setLookDescription(textFieldId, > if (description) { > var start = description.lastIndexOf(' ['); > if (start != -1) { > + // To allow to set a dependent Id field when using a Name field as a lookup (the fields must have the same prefix, > eg: partyName, partyId) > + // It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a > description in the autocomplete part. > + // It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). > + // At least it easy to set and it works well for simples case for now (eg PartyGroup) > + var dependentId = textFieldId.replace(/Name/, "Id"); // Raw but ok for now, needs safe navigation... > + // I did not find another way since Ajax.Autocompleter can't update another field > + // The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair > + // But it's more difficult to demonstrate in Example component > + // dependentId = (textFieldId.next('div').down('input[type=hidden]'); > + $(dependentId).clear(); > + var dependentIdValue = (description.substring(start + 1, description.length).replace(/\[/g, "")).replace(/\]/g, ""); > + if ($(dependentId)) { > + $(dependentId).value = dependentIdValue; > + } > + > description = description.substring(0, start); > + $(dependentId).value = description; > } > } > var lookupWrapperEl = $(textFieldId).up('.field-lookup'); > > |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
Administrator
|
From: "Jacques Le Roux" <[hidden email]>
> Of course when I began to work on this I tried to use description-field-name but was unable to access it and discovered it was > useless in the autocomplete context. BTW using jQuery for this should be far easier as the > http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/ is now part of jQuery.ui... > > Jacques Actually I'm really tired because it seems there is the same problem with jQuery...Anyway, later... Jacques > From: <[hidden email]> >> Author: jleroux >> Date: Tue Sep 7 19:55:49 2010 >> New Revision: 993508 >> >> URL: http://svn.apache.org/viewvc?rev=993508&view=rev >> Log: >> Introduces a very simple mean to set a dependent Id field when using a Name field as a lookup (the fields must have the same >> prefix, eg: partyName, partyId). >> It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a description in the >> autocomplete part. >> It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >> At least it easy to set and it works well for simples case for now (eg PartyGroup) >> >> I did not find another way since Ajax.Autocompleter can't update another field. >> The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair. >> But it's more difficult to demonstrate in Example component >> >> Modified: >> ofbiz/trunk/framework/images/webapp/images/selectall.js >> >> Modified: ofbiz/trunk/framework/images/webapp/images/selectall.js >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/framework/images/webapp/images/selectall.js?rev=993508&r1=993507&r2=993508&view=diff >> ============================================================================== >> --- ofbiz/trunk/framework/images/webapp/images/selectall.js (original) >> +++ ofbiz/trunk/framework/images/webapp/images/selectall.js Tue Sep 7 19:55:49 2010 >> @@ -232,6 +232,7 @@ function confirmActionFormLink(msg, form >> * @param target The URL to call to update the HTML container >> * @param targetParams The URL parameters >> */ >> + >> function ajaxUpdateArea(areaId, target, targetParams) { >> waitSpinnerShow(); >> new Ajax.Updater(areaId, target, {parameters: targetParams, evalScripts: true, >> @@ -377,7 +378,23 @@ function setLookDescription(textFieldId, >> if (description) { >> var start = description.lastIndexOf(' ['); >> if (start != -1) { >> + // To allow to set a dependent Id field when using a Name field as a lookup (the fields must have the same prefix, >> eg: partyName, partyId) >> + // It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a >> description in the autocomplete part. >> + // It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >> + // At least it easy to set and it works well for simples case for now (eg PartyGroup) >> + var dependentId = textFieldId.replace(/Name/, "Id"); // Raw but ok for now, needs safe navigation... >> + // I did not find another way since Ajax.Autocompleter can't update another field >> + // The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair >> + // But it's more difficult to demonstrate in Example component >> + // dependentId = (textFieldId.next('div').down('input[type=hidden]'); >> + $(dependentId).clear(); >> + var dependentIdValue = (description.substring(start + 1, description.length).replace(/\[/g, "")).replace(/\]/g, ""); >> + if ($(dependentId)) { >> + $(dependentId).value = dependentIdValue; >> + } >> + >> description = description.substring(0, start); >> + $(dependentId).value = description; >> } >> } >> var lookupWrapperEl = $(textFieldId).up('.field-lookup'); >> >> > |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
In reply to this post by Jacques Le Roux
Jacques, Why do you say that the description-field-name attribute is "useless in the autocomplete context"? It looks like in his initial implementation you chose to determine the related field (the "description" field) based on how the fields are named. In other word if the autocomplete ended with "Id", like partyId, if would remove the "Id" and add "Name" and look for a field with that name to put the description in. What it sounds like you are proposing is to do is to determine the related field to populate by looking for the next field in the form, instead of using the description-field-name attribute like the lookup does. In order to be consistent with the lookup window, and allow the fields to be named anything, the autocomplete stuff should use the existing lookup -> description-field-name attribute to determine the related field to populate instead of doing so based on the name by swapping out suffixes. Doing anything else seems like a hack to me. So, back to the original question, why not use the value of the description-field-name attribute as the related field to populate with the description? -David On Sep 7, 2010, at 2:59 PM, Jacques Le Roux wrote: > Of course when I began to work on this I tried to use description-field-name but was unable to access it and discovered it was > useless in the autocomplete context. BTW using jQuery for this should be far easier as the > http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/ is now part of jQuery.ui... > > Jacques > > From: <[hidden email]> >> Author: jleroux >> Date: Tue Sep 7 19:55:49 2010 >> New Revision: 993508 >> >> URL: http://svn.apache.org/viewvc?rev=993508&view=rev >> Log: >> Introduces a very simple mean to set a dependent Id field when using a Name field as a lookup (the fields must have the same >> prefix, eg: partyName, partyId). >> It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a description in the >> autocomplete part. >> It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >> At least it easy to set and it works well for simples case for now (eg PartyGroup) >> >> I did not find another way since Ajax.Autocompleter can't update another field. >> The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair. >> But it's more difficult to demonstrate in Example component >> >> Modified: >> ofbiz/trunk/framework/images/webapp/images/selectall.js >> >> Modified: ofbiz/trunk/framework/images/webapp/images/selectall.js >> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/images/webapp/images/selectall.js?rev=993508&r1=993507&r2=993508&view=diff >> ============================================================================== >> --- ofbiz/trunk/framework/images/webapp/images/selectall.js (original) >> +++ ofbiz/trunk/framework/images/webapp/images/selectall.js Tue Sep 7 19:55:49 2010 >> @@ -232,6 +232,7 @@ function confirmActionFormLink(msg, form >> * @param target The URL to call to update the HTML container >> * @param targetParams The URL parameters >> */ >> + >> function ajaxUpdateArea(areaId, target, targetParams) { >> waitSpinnerShow(); >> new Ajax.Updater(areaId, target, {parameters: targetParams, evalScripts: true, >> @@ -377,7 +378,23 @@ function setLookDescription(textFieldId, >> if (description) { >> var start = description.lastIndexOf(' ['); >> if (start != -1) { >> + // To allow to set a dependent Id field when using a Name field as a lookup (the fields must have the same prefix, >> eg: partyName, partyId) >> + // It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a >> description in the autocomplete part. >> + // It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >> + // At least it easy to set and it works well for simples case for now (eg PartyGroup) >> + var dependentId = textFieldId.replace(/Name/, "Id"); // Raw but ok for now, needs safe navigation... >> + // I did not find another way since Ajax.Autocompleter can't update another field >> + // The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair >> + // But it's more difficult to demonstrate in Example component >> + // dependentId = (textFieldId.next('div').down('input[type=hidden]'); >> + $(dependentId).clear(); >> + var dependentIdValue = (description.substring(start + 1, description.length).replace(/\[/g, "")).replace(/\]/g, ""); >> + if ($(dependentId)) { >> + $(dependentId).value = dependentIdValue; >> + } >> + >> description = description.substring(0, start); >> + $(dependentId).value = description; >> } >> } >> var lookupWrapperEl = $(textFieldId).up('.field-lookup'); >> >> > > |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
Administrator
|
David,
I totally agree, and of course I tried to use it rather than the hack I used, or the slightly better one I propose (less constraints for projects using already a similar form: lookup field, then just after related - often hidden - field, ie no needs to rename already used fields). I 1st tried to use it where it can be used (in the Java context, since it can't be used in the Ajax/DOM context as it's not there anymore, and that's what I mean by "useless in the autocomplete context") and tried to play with it in ModelFormField.renderLookupField where the autoCompleterTarget is used to build the updateAreas (which is used after by createAjaxParamsFromUpdateAreas to create the ajaxUrl(s) where all things are). But the problem here is that it (Prototype Ajax.autocompleter) all depends on the action on the field (2d arg of ModelForm.UpdateArea). We don't have any actions from the user on the other field (only letter typed in the lookup field are handled by the autocompleter). I thought that I could find a way to trigger an action later in the process on the other field (passed in updateAreas) but gave up at this stage because anyway I would still need to fill the field... There is maybe another way, but I did not find it in the limited time I assigned to this. That's why I decided to use this hack. In other words, there is no means in Prototype Ajax.autocompleter to fill a second field with a value of your choice grabbed during the server call. The afterUpdateElement callback (called setSelection in our case) has only "two parameters, the input field specified for autocompletion, and the selected item (the <li> item selected)". There are no places for the description-field-name. So we have to put a hack in the callback to handle the change in the other field. It's the same in jQuery Autocomplete where afterUpdateElement is named select, but there maybe something called change could be used (I doubt). Anyway the same problem arises: where is the field we want to change and the value to put in it? If I missed something I would be happy to learn... If we are really unhappy with my hack I guess we will need to introduce something more (div?) in the lookup field structure in order to be able to address a sub-field by a simple DOM navigation (thinking at it, OOTB we could use the group element but then other problems arises, notably alignment). Else, in my last propostion not already coded, the constraint would simply be to put the other input field just after the lookup field. BTW, for clarity sake, I think we should better have all the Ajax code out of selectall.js in its own file (ajax.js?) Jacques From: "David E Jones" <[hidden email]> > Jacques, > > Why do you say that the description-field-name attribute is "useless in the autocomplete context"? > > It looks like in his initial implementation you chose to determine the related field (the "description" field) based on how the > fields are named. In other word if the autocomplete ended with "Id", like partyId, if would remove the "Id" and add "Name" and > look for a field with that name to put the description in. > > What it sounds like you are proposing is to do is to determine the related field to populate by looking for the next field in the > form, instead of using the description-field-name attribute like the lookup does. > > In order to be consistent with the lookup window, and allow the fields to be named anything, the autocomplete stuff should use the > existing lookup -> description-field-name attribute to determine the related field to populate instead of doing so based on the > name by swapping out suffixes. Doing anything else seems like a hack to me. > > So, back to the original question, why not use the value of the description-field-name attribute as the related field to populate > with the description? > > -David > > > On Sep 7, 2010, at 2:59 PM, Jacques Le Roux wrote: > >> Of course when I began to work on this I tried to use description-field-name but was unable to access it and discovered it was >> useless in the autocomplete context. BTW using jQuery for this should be far easier as the >> http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/ is now part of jQuery.ui... >> >> Jacques >> >> From: <[hidden email]> >>> Author: jleroux >>> Date: Tue Sep 7 19:55:49 2010 >>> New Revision: 993508 >>> >>> URL: http://svn.apache.org/viewvc?rev=993508&view=rev >>> Log: >>> Introduces a very simple mean to set a dependent Id field when using a Name field as a lookup (the fields must have the same >>> prefix, eg: partyName, partyId). >>> It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a description in the >>> autocomplete part. >>> It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >>> At least it easy to set and it works well for simples case for now (eg PartyGroup) >>> >>> I did not find another way since Ajax.Autocompleter can't update another field. >>> The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair. >>> But it's more difficult to demonstrate in Example component >>> >>> Modified: >>> ofbiz/trunk/framework/images/webapp/images/selectall.js >>> >>> Modified: ofbiz/trunk/framework/images/webapp/images/selectall.js >>> URL: >>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/images/webapp/images/selectall.js?rev=993508&r1=993507&r2=993508&view=diff >>> ============================================================================== >>> --- ofbiz/trunk/framework/images/webapp/images/selectall.js (original) >>> +++ ofbiz/trunk/framework/images/webapp/images/selectall.js Tue Sep 7 19:55:49 2010 >>> @@ -232,6 +232,7 @@ function confirmActionFormLink(msg, form >>> * @param target The URL to call to update the HTML container >>> * @param targetParams The URL parameters >>> */ >>> + >>> function ajaxUpdateArea(areaId, target, targetParams) { >>> waitSpinnerShow(); >>> new Ajax.Updater(areaId, target, {parameters: targetParams, evalScripts: true, >>> @@ -377,7 +378,23 @@ function setLookDescription(textFieldId, >>> if (description) { >>> var start = description.lastIndexOf(' ['); >>> if (start != -1) { >>> + // To allow to set a dependent Id field when using a Name field as a lookup (the fields must have the same prefix, >>> eg: partyName, partyId) >>> + // It uses the description (Id) shown with the Name. Hence the Lookup screen must be set in order to show a >>> description in the autocomplete part. >>> + // It seems this is not always easy notably when you need to show at least 2 parts for the Name (eg Person). >>> + // At least it easy to set and it works well for simples case for now (eg PartyGroup) >>> + var dependentId = textFieldId.replace(/Name/, "Id"); // Raw but ok for now, needs safe navigation... >>> + // I did not find another way since Ajax.Autocompleter can't update another field >>> + // The alternative would be navigation to the next hidden field, at least it would avoid the mandatory Id/Name pair >>> + // But it's more difficult to demonstrate in Example component >>> + // dependentId = (textFieldId.next('div').down('input[type=hidden]'); >>> + $(dependentId).clear(); >>> + var dependentIdValue = (description.substring(start + 1, description.length).replace(/\[/g, "")).replace(/\]/g, >>> ""); >>> + if ($(dependentId)) { >>> + $(dependentId).value = dependentIdValue; >>> + } >>> + >>> description = description.substring(0, start); >>> + $(dependentId).value = description; >>> } >>> } >>> var lookupWrapperEl = $(textFieldId).up('.field-lookup'); >>> >>> >> >> > |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
|
On Sep 8, 2010, at 12:10 PM, Jacques Le Roux wrote: > I 1st tried to use it where it can be used (in the Java context, since it can't be used in the Ajax/DOM context as it's not there > anymore, and that's what I mean by "useless in the autocomplete context") and tried to play with it in > ModelFormField.renderLookupField where the autoCompleterTarget is used to build the updateAreas (which is used after by > createAjaxParamsFromUpdateAreas to create the ajaxUrl(s) where all things are). > > But the problem here is that it (Prototype Ajax.autocompleter) all depends on the action on the field (2d arg of > ModelForm.UpdateArea). We don't have any actions from the user on the other field (only letter typed in the lookup field are > handled by the autocompleter). I thought that I could find a way to trigger an action later in the process on the other field (passed in updateAreas) but gave up at this stage because anyway I would still need to fill the field... There is maybe another way, but I did not find it in the limited time I assigned to this. That's why I decided to use this hack. > > In other words, there is no means in Prototype Ajax.autocompleter to fill a second field with a value of your choice grabbed during > the server call. The afterUpdateElement callback (called setSelection in our case) has only "two parameters, the input field > specified for autocompletion, and the selected item (the <li> item selected)". There are no places for the description-field-name. > So we have to put a hack in the callback to handle the change in the other field. It's the same in jQuery Autocomplete where > afterUpdateElement is named select, but there maybe something called change could be used (I doubt). Anyway the same problem arises: where is the field we want to change and the value to put in it? If I missed something I would be happy to learn... Yes, one way or another that method will need access to the information. It's just code, so there's always a way... It may be possible to put the information in a separately available structure to avoid changing the Ajax.autocompleter code. -David |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
Administrator
|
From: "David E Jones" <[hidden email]>
> On Sep 8, 2010, at 12:10 PM, Jacques Le Roux wrote: > >> I 1st tried to use it where it can be used (in the Java context, since it can't be used in the Ajax/DOM context as it's not there >> anymore, and that's what I mean by "useless in the autocomplete context") and tried to play with it in >> ModelFormField.renderLookupField where the autoCompleterTarget is used to build the updateAreas (which is used after by >> createAjaxParamsFromUpdateAreas to create the ajaxUrl(s) where all things are). >> >> But the problem here is that it (Prototype Ajax.autocompleter) all depends on the action on the field (2d arg of >> ModelForm.UpdateArea). We don't have any actions from the user on the other field (only letter typed in the lookup field are >> handled by the autocompleter). I thought that I could find a way to trigger an action later in the process on the other field >> (passed in updateAreas) but gave up at this stage because anyway I would still need to fill the field... There is maybe another >> way, but I did not find it in the limited time I assigned to this. That's why I decided to use this hack. >> >> In other words, there is no means in Prototype Ajax.autocompleter to fill a second field with a value of your choice grabbed >> during >> the server call. The afterUpdateElement callback (called setSelection in our case) has only "two parameters, the input field >> specified for autocompletion, and the selected item (the <li> item selected)". There are no places for the >> description-field-name. >> So we have to put a hack in the callback to handle the change in the other field. It's the same in jQuery Autocomplete where >> afterUpdateElement is named select, but there maybe something called change could be used (I doubt). Anyway the same problem >> arises: where is the field we want to change and the value to put in it? If I missed something I would be happy to learn... > > Yes, one way or another that method will need access to the information. It's just code, so there's always a way... > > It may be possible to put the information in a separately available structure to avoid changing the Ajax.autocompleter code. > > -David Also there is an issue with how the code behaves for now. If you have 2 records with exactly the same name it can't retrieve the related Id. This is I guess the reason why this have never been tried before. This is due to these lines if('UL'!= wrapperElement.firstDescendant().tagName || (wrapperElement.firstDescendant().childElements().length != 1)) { //alert(transport.responseText); response is error or more than one entries are found return; } In such case we could retrieve the 1st one, with of course a message to alert the user (you can't have the cake and eat it) Jacques |
Re: svn commit: r993508 - /ofbiz/trunk/framework/images/
|
Administrator
|
In reply to this post by Jacques Le Roux
From: "Jacques Le Roux" <[hidden email]>
> From: "David E Jones" <[hidden email]> >> On Sep 8, 2010, at 12:10 PM, Jacques Le Roux wrote: >> >>> I 1st tried to use it where it can be used (in the Java context, since it can't be used in the Ajax/DOM context as it's not >>> there >>> anymore, and that's what I mean by "useless in the autocomplete context") and tried to play with it in >>> ModelFormField.renderLookupField where the autoCompleterTarget is used to build the updateAreas (which is used after by >>> createAjaxParamsFromUpdateAreas to create the ajaxUrl(s) where all things are). >>> >>> But the problem here is that it (Prototype Ajax.autocompleter) all depends on the action on the field (2d arg of >>> ModelForm.UpdateArea). We don't have any actions from the user on the other field (only letter typed in the lookup field are >>> handled by the autocompleter). I thought that I could find a way to trigger an action later in the process on the other field >>> (passed in updateAreas) but gave up at this stage because anyway I would still need to fill the field... There is maybe another >>> way, but I did not find it in the limited time I assigned to this. That's why I decided to use this hack. >>> >>> In other words, there is no means in Prototype Ajax.autocompleter to fill a second field with a value of your choice grabbed >>> during >>> the server call. The afterUpdateElement callback (called setSelection in our case) has only "two parameters, the input field >>> specified for autocompletion, and the selected item (the <li> item selected)". There are no places for the >>> description-field-name. >>> So we have to put a hack in the callback to handle the change in the other field. It's the same in jQuery Autocomplete where >>> afterUpdateElement is named select, but there maybe something called change could be used (I doubt). Anyway the same problem >>> arises: where is the field we want to change and the value to put in it? If I missed something I would be happy to learn... >> >> Yes, one way or another that method will need access to the information. It's just code, so there's always a way... >> >> It may be possible to put the information in a separately available structure to avoid changing the Ajax.autocompleter code. >> >> -David > > Also there is an issue with how the code behaves for now. If you have 2 records with exactly the same name it can't retrieve the > related Id. This is I guess the reason why this have never been tried before. > This is due to these lines > if('UL'!= wrapperElement.firstDescendant().tagName || (wrapperElement.firstDescendant().childElements().length != 1)) { > //alert(transport.responseText); response is error or more than one entries are found > return; > } > > In such case we could retrieve the 1st one, with of course a message to alert the user (you can't have the cake and eat it) And in this message suggest them to use rather the lookup button, because then there will be any ambiguities Jacques > Jacques |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |