Not planned Might Be Duplicate -- We Need ID Attribute

frm

Well-known member
While this might be a somewhat duplicate of @CMTV 's thread about custom fields, there was one small suggestion in it that may be overlooked because I feel it's suggesting a unique id attribute per custom field, which is not necessary.

Reference to what else should be implemented below, but I don't see why id can't be implemented much much sooner as it was as simple as editing the template custom_fields_macros to have the id code at the end:

Code:
        <xf:textbox name="{$namePrefix}[{$definition.field_id}]" value="{$set.{$definition.field_id}}"
            type="{$type}"
            maxlength="{{ $definition.max_length ? $definition.max_length : '' }}"
            pattern="{$pattern}"
            title="{$title}"
            min="{$min}"
            max="{$max}"
            step="{$step}"
            required="{{ $definition.isRequired($editMode) ? 'required' : '' }}"
            class="field_{$definition.field_id}"
            id="{$definition.field_id}" />

Without adding an id to the textbox code, an entirely new custom field might need to be created to make a Google Places API autocomplete custom field.

203800

And from that, you can also grab the GPS coordinates for another custom field that can be regex'ed (if necessary for).

203802

There's a lot that can be done with JS/CSS with the id attribute and I'm wondering why such a simple edit (that took me hours to figure out, but probably hours less trying to make a custom custom field type for this purpose).

Original quote that I found while trying to determine why I couldn't achieve it by name:
An option to add CSS/ID's to the whole custom field not only on it's value part

We don't necessarily need 'advanced custom fields' (as to why I don't feel this is duplicate) as we, in my opinion, don't need to set a unique id for each custom tag as it can use the name as seen from the code change above. But, we do need id's on our custom fields for easier template modifications to make our custom fields, custom looking (or more).

 
Upvote 0
This suggestion has been closed. Votes are no longer accepted.
For the sheer majority of cases, and I believe this is especially true for the Google Maps API, an ID attribute isn't actually necessary.

Indeed a lot of setup for JavaScript libraries will recommend something along the lines of:
JavaScript:
document.getElementById('some_id')
But you can replace that with an alternative:
JavaScript:
document.getElementsByClassName('field_your_field_id')[0]
Each field has a unique class name so you can just use that for JavaScript initialisation. If you needed to target the entire row, the row itself has a data attribute:
JavaScript:
document.querySelectorAll('[data-field="your_field_id"]')[0];
We tend to steer away from using the ID attribute unless absolutely necessary because you are supposed to only have one element per unique ID per page. Using IDs can therefore be problematic, especially when pages have so many dynamic elements. An actual realistic example is you can probably get the same custom thread field on the page twice when editing the first post of a thread, and clicking the "Edit thread" overlay (I think).

As such, this is really a "Not planned" or duplicate. So, yeah, if you absolutely must use an ID (unlikely), then you will have to add the attribute yourself. Otherwise, just adjust the JavaScript to not require an ID.
 
Otherwise, just adjust the JavaScript to not require an ID.
I understand that it won't be implemented, but to save people the trouble, an id must be used with Google API.

I ran through the missing one above (querySelectorAll) as that was one that I didn't try and then verified how 1 other add-on was accomplishing location method above, using an id.

I won't name the developer, but one of the tops here. Another add-on by another developer with an unmaintained addon has an id in that particular field too.

So unless there's a workaround, the id attribute must be added. To be unique, I'm throwing in some random numbers or something where it likely won't match anything (as opposed to using just its name).
 
The code examples I've seen for the Google Maps API do not require an ID.

You may want to post in the development discussions forum if you're having difficulty getting the code to work.
 
The code examples I've seen for the Google Maps API do not require an ID.

You may want to post in the development discussions forum if you're having difficulty getting the code to work.
Maybe not Google Maps, but Places API does; and, all examples by Google lead me to believe that's true.


Though, I'll ask a developer (if he responds) why he chose to use an id over any other method.

Thank you :)
 
Maybe not Google Maps, but Places API does; and, all examples by Google lead me to believe that's true.


Though, I'll ask a developer (if he responds) why he chose to use an id over any other method.

Thank you :)
Without speaking for Chris, I think you might have misunderstood what he was trying to convey.

In this bit of the code from that page:
JavaScript:
function initAutocomplete() {
  // Create the autocomplete object, restricting the search predictions to
  // geographical location types.
  autocomplete = new google.maps.places.Autocomplete(
      document.getElementById('autocomplete'), {types: ['geocode']});

  // Avoid paying for data that you don't need by restricting the set of
  // place fields that are returned to just the address components.
  autocomplete.setFields(['address_component']);

  // When the user selects an address from the drop-down, populate the
  // address fields in the form.
  autocomplete.addListener('place_changed', fillInAddress);
}
You can freely replace document.getElementById('autocomplete') with document.getElementsByClassName('field_your_field_id')[0] and it will still work.

The return value of getElementById is identical to getElementsByClassName('field_your_field_id')[0] - it still fetches a DOM object. That's all the Autocomplete class cares about.

The example documentation is just that, examples. Sometimes, it's okay to modify some parts of the code in order to get the desired effects :D
 
If by "all examples" you mean the usage of document.getElementById() then, again, you just need to replace that with calls to getElementsByClassNames() or querySelectorAll().

XF also makes use of jQuery so you should be able to replace the calls with something along the lines of:
JavaScript:
$('.field_your_field_id')[0]
 
@DragonByte Tech
Maybe I'm missing something here, but every variant I try, nothing works (top is with ID, which works, else is with the getElementsByClassName which I've read that "input" may need to be removed. (Each tried separately, of course)

Code:
// ID
var input = document.getElementById("opd_address1");
// ClassName
var input document.getElementsByClassName('input field_opd_address')[0];
var input document.getElementsByClassName('field_opd_address')[0];

Appreciate it! :)
 
@DragonByte Tech
Maybe I'm missing something here, but every variant I try, nothing works (top is with ID, which works, else is with the getElementsByClassName which I've read that "input" may need to be removed. (Each tried separately, of course)

Code:
// ID
var input = document.getElementById("opd_address1");
// ClassName
var input document.getElementsByClassName('input field_opd_address')[0];
var input document.getElementsByClassName('field_opd_address')[0];

Appreciate it! :)
Is it a typo in your example or did you forget the = sign in var input = document.getElementsByClassName? 🤔
 
Back
Top Bottom