Hello Admin

Congrats on the new voting feature.

I don't know where this request falls but I would love to see a recoding of the Ajax naming convention. Currently the builder seems to simply add a sequence number to the word "select" when generating these references. This seems simple but it creates large discrepancies between component versions.

xmlphpChanging a single Ajax reference has the potential to ripple through the entire component, changing all the references. Therefore there is no such thing as a local update to a given view in an Ajax context; all changes have global scope.

I have found that tracking down an Ajax issue and resolving it only offers new challenges when moving to a new version of the same component. New effort must be mounted to find the new reference and apply the cure each time.

I would love to see the field name and maybe the "layout" used in generating these references. This way changes to a layout will be local to that layout and its end-point, about 3 files or so.

xmlAlso, I could be wrong but I see no need to have a separate "created_by" routine for each view which instances the Author wizard. Only if the user called different values [username/name/email] will variations or separate routines be necessary. This applies to all other references which have duplicate routines. If a developer creates identical references, chances are they require the same data and the same routine can be used to service that need.

In the final analysis I don't know what is easy to change in the builder so I will leave it to your judgement. All I am saying is that there exist a need to prevent an Ajax modification on a single layout from changing the entire component.

Warm regards
vlemos

Hello Admin

I am not sure if what I said was clear enough or if others are experiencing the same type of challenges. However, I have found that preserving and migrating the fork folder from one component version to the next is not as seamless as it can be because of the way Ajax references are generated in the builder.

When new Ajax changes are made, the new component version has new form-xml references which point to totally different routines; the old links are broken in the process. One way to upgrade the component is to rebuild the references manually one at a time or try to migrate the XMLs as well and add the new references all by hand. This also carries maintenance implications...

Can anything be done to prevent a single change from affecting the entire component in an Ajax context? Is this something you can address at this time?

Any feedback would be appreciated.

Warm regards
vlemos

I understand what you mean.

the 'render' property is named 'select1', 'select2', 'filter1', 'filter2'...
That correct, and if you add an ajax call, it can change the names of those calls, making the 'filter1' becoming 'filter2'.
Very good hint.
You are correct and I never thought about this because I almost never for those ajax calls.

I can put an ajax instance name in the properties, it would solve the problem.
I also want to rewrite all this ajax part using XML field, so it will change the structure, but this will come in the version 3. At that moment you will need to rewrite your forks once again. It can come soon because I am gonna work on rewritting some fields, including ajax.

Hold on.

Done, you can now specify an alias for the ajax call, just under the ajax checkbox.
Both filters, and fields.

Thanks Admin

Is it possible to preload this field with the data-table field name? Populating each and every one of these fields will make the builder more labor intensive and prone to mistakes [mainly omissions].

However, if the Ajax instance is automatically populated with the field-name when Ajax loading is selected and only if the instance-name is empty; this would help to reduce the effort required to Ajaxify a cook form.

Please consider auto-loading the Ajax instance.

Warm regards
vlemos

Prefixes like select_ and filter_ or slt_ and flt_ may be necessary to ensure that selections and filters with the same name do not collide.