I think it would be useful if the menu item path was a dedicated form element registered with hook_element_info().
This would allow to implement any autocomplete, validation, and even the placeholder replacement, as a feature of this form element, not caring about the rest of the form.

The element would behave mostly like a textfield, but it would have a setting $element['#mlid'], that will be used for the placeholder and autocomplete stuff.

Comments

donquixote’s picture

donquixote CreditAttribution: donquixote commented

One challenge: For new items, the mlid can only be set once the element itself has been created.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Just a note: I tried this myself locally, but not really happy with it yet.

At some point we need to run a process function, and this will turn it into a textfield with added validation etc.

But, we can not simply just say $element['#type'] = 'textfield', but rather add an inner element which then is the text field.
$element['textfield'] = array('#type' => 'textfield', '#default_value' => $element['#default_value'], ..)

This sounds to me like too much nesting (esp. if we squeeze yet another step in between, as below).

I also thought about putting in between another element type, that would be called 'linkfield'. So the menu item path field would be turned into a linkfield, this would be turned into a textfield.
Btw, this is a missing feature in Drupal core+contrib, having a dedicated form element for url paths! Even the 'link' module form element only works in combination with field api, not as standalone.

I can commit my stuff to a feature branch, if you want.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Btw, the first use case I was thinking about would be
#1689436: Allow to edit the menu item path directly from placeholder page.

This is also easier for development, because dpm() will not generate dozens of messages :)

dsdeiz’s picture

dsdeiz CreditAttribution: dsdeiz commented

I can commit my stuff to a feature branch, if you want.

Would definitely love that. Thanks!

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Pushed to 7.x-1.x-hook_element_info. No promises. Good luck with it :)

dsdeiz’s picture

dsdeiz CreditAttribution: dsdeiz commented

Hi, sorry, didn't have time to tackle this much. Anyway, I'm a little confused. menu_editor_item_path would simply be holding menu_editor_link_path? I'm guessing it would contain the menu_editor_link_path element and a property for mlid while menu_editor_link_path would contain the textfield and include validation? If this is the case, I'm not sure why there need to exist two elements though. Perhaps they can be combined instead.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Hi,
I have no strong opinion about this. In the end we might decide that this issue is not useful at all :)

The idea with menu_editor_link_path was to have a form element dedicated for links, with all the validation etc.
In theory, this could be reused in other places where a user can specify a link. E.g. to specify the site frontpage, etc.
However, this would only make sense if the element was provided by Drupal core, or by the "link" module. Unfortunately, the "link" module form element only works within field API.

So, as long as this is all within menu_editor, the additional level probably does not add much benefit.

Also I am not sure if the "custom form element type" is really a useful solution, or if it is better to just create a textfield, and add process and validation callbacks - so the reusable thing would be not the form element type, but the process callback.