Form field types that have JS logic ( User form field type, Calendar form field type, etc) breaks when used with The Repeatable form field type
Replication steps
Example XML code which causes this issue
<field name="list_users"
type="Repeatable"
icon="list"
description="PLG_TINY_FIELD_TEMPLATE_FIELD_ELEMENTS_DESC"
label="PLG_TINY_FIELD_TEMPLATE_FIELD_ELEMENTS_LABEL"
default="{'user':['']}">
<fields name="params">
<fieldset hidden="true" name="list_users_modal" repeat="true">
<field name="user_id" type="user"
label="JGLOBAL_FIELD_MODIFIED_BY_LABEL"
filter="unset" />
</fieldset>
</fields>
</field>
Expected: a repeatable field for users that would display a modal field list of selected users, which upon "adding" a user would display a modal select box of users.
Result observed: the modal select box of users does not display as a modal but replaces the existing view with a user list and no method to return to the component view after selecting a user.
example observed url administrator/index.php?option=com_users&view=users&layout=modal&tmpl=component&field=jform_params_user_id
Note: originally opened as an issue in the Framework moved issue to the appropriate repo
Category | ⇒ | Libraries |
Labels |
Added:
?
|
Labels |
Added:
?
|
After just a quick test, seem adding anchor css "modal" on the link generated from user field open modal box, just dont understand why actual anchor (modal concated to id) not work.
Maybe method "assign" of squeezebox js not working ?
SqueezeBox.assign($('a.modal_jform_params_user_id').get(), { parse: 'rel' });
Moreover, choosing user on modal box dont work, js error occur
TypeError: document.getElementById(...) is null
-> var old_id = document.getElementById("jform_params_user_id_id").value;
@Devportobello answer is simple: ID changed
if you want you could try make another dirty hack similar as it already done for Media field or try optimize the user field script ... I would recommend a second variant
@photodude Can you try #5655 wit repeatable field?
@dgt41 nope, it will not work because function linked to the field ID
function jSelectUser_" . $id . "(id, title)
better way would be make one generic method for that field, instead of new method for each field instance ... like now ... + this method should work independent from the field ID and NAME, as it changed by repeatable script
something like:
Joomla.FieldSelectUser = function(field, userid, title){
// some complicated code for change the value :)
}
problem: how to get the field element for this method
I am afraid that field also could be broken in the repeatable field, or you already tried?
@Fedik Actually I haven’t, but I guess since the field ID is passed to the function https://github.com/dgt41/joomla-cms/blob/_field_media/media/media/js/mediafield.js#L22 will work. This is not hard coded as user field, but maybe some more js is needed to initiate the process?
problem can be that initializeMedia
will not be called at all
as initializeMedia(path, empty, previewWidth, previewHeight, source, fieldId);
you call in jQuery.ready
but on this time the media field do not exists ... when use repeatable field
for existing Media field I made dirty hack in repeatable.js
but it is wrong way to fix all such problem
I mean that initializeMedia
will not see the mediafield inside repeatable field
I mean that
initializeMedia
will not see the mediafield inside repeatable field
But that’s the responsibility of the repeatable field to initiate further scripts depending on field type inserted. I agree with you here that all this could be done in more sensible way with your proposal #6357. I hope PLT will make a good decision there
But that’s the responsibility of the repeatable field to initiate further scripts depending on field type inserted.
I do not agree on this point, as we could have 1000 fields, and how the repeatable field will know about all of them
also the repeatable field alredy have some events that in theory could help a little bit
@dgt41 @Fedik, That's an interesting solution discussion. Should all fields be compatible with repeatable form fields or should the repeatable form field type be compatible with all form field types including custom fields?
I would argue that the ideal situation/solution is for the repeatable form field type be compatible with all form field types (except itself) in an field agnostic method; where the repeatable field type wouldn't need to know about what field type is entered as repeatable, just that the field needs to be repeated.
I will also argue that even the ideal situation/solution will likely require all fields needing something in their methods to insure they are compatible with repeatable form fields. (chicken or the egg dilemma. Bootstrapping concepts suggests the solution is both)
I look forward to seeing what solutions to this, and other issues with repeatable form fields, come about.
idealy the repeatable field and the fields inside should not know about each other, but still continue to work, this can be achieved when we will have some common way for scripts initialization, and can watch not only when DOM ready, but also when DOM changed,
Then:
something like this already suggested there #6357
that even the ideal situation/solution will likely require all fields needing something in their methods
also true
"In testing I have also found that the Calendar form field type also breaks when used with Repeatable form field type
example xml that fails
<field name="allevents"
type="repeatable"
icon="list"
description="COM_MYCOMPONENT_FORM_DESC_USER_EVENTS"
label="COM_MYCOMPONENT_FORM_LBL_USER_EVENTS"
default="{'mytextvalue':[''],'event_date':['00-00-0000']}">
<fields name="params">
<fieldset name="list_templates_modal" repeat="true">
<field name="mytextvalue"
type="text"
default="Some text"
label="Enter some text"
description=""
size="10" />
<field name="event_date"
type="calendar"
label="Select a date"
default=""
description=""
format="%d-%m-%Y" />
</fieldset>
</fields>
</field>
Text field works but the calendar does nothing.
@photodude I tell you more, all fields that have some JS logic is broken inside repeatable field
Title |
|
@photodude @Fedik Actually I guess is better to form a working group for this matter instead of just start an implementation that might not be the best fit for the project. What do you think?
@photodude actually "the fields that have JS logic are broken when used inside the repeatable field", not vise versa
@dgt41 not sure, not sure ... maybe there already one, or couple
Title |
|
@dgt41 this could work, but it is a wrong way
need something in general, so the fields could work not only inside repeatable, but also example when someone decide load the form using ajax
and I already seen repeatCounter
properties somewhere in JForm
or JField
but as I understand no one remember for what is it
@dgt41 about Modal fields,
in theory we could init these fields on "first access" instead of "dom ready",
for this could use event delegation, some fake code:
$(document).ready(function(){
$(document).on("click", ".here-user-field-button-class-name", function(){
$input = $(this).prev('input') // find input for get a current id
someMethodForShowPopup($input.property("id")) // show popup and call Joomla.FieldUserSetValue onPopupClose
});
});
Joomla.FieldUserSetValue = function(fieldid, userid, title){
// some complicated code for change the field value :)
}
<input />
<button class="here-user-field-button-class-name">Select User</button>
of course, still not perfect, but...
And I think also would be cool if we have same API for such fields, currently each field (user, media, article modals) use own scripts ... but not sure that it is possible in b/c way
@Fedik we can break B/C with the introduction of layouts. Actually we will not, but we can keep the old code as is (mootools modals, scripts etc) and for the newer version that loads on layout and bootstrap we get another set of code! If you look at #5871, #5655 you will see that mootools code was retained as it was but the new layouts don’t have to follow this pattern. And that will not break anything AS LONG as ALL the form fields follow the same layout (mootools or bootstrap). In the edge case that both new and old layouts are mixed I guess repeatable will have a very hard time to work decently
Any word on progress for fixing this issue?
I've done a little more testing of repeatable field groups, and found another issue. The new showon attribute does not work with repeatable field groups (seems since the fields get renamed the showon's creation of the field rel attribute loses the reference to the parent field since the parent gets a new name each time the field gets repeated). I believe this to be part of this larger issue with the repeatable field type and any JavaScript logic included in the fields to be repeated.
The problem is that sub-fields in repeatable field type have wrong ID passed into context. That's why scripts assigned to those fields breaks. For example create form like this:
cities
city
and region
with type text
Now when you render this form in html you will see that region field ID is jform_region-1
but JFormFieldText var_dump will return ID jform_region
. So when you use script based field like JFormCalendar
ID used in calendar setup will be different from ID generated by field. But this is not them end of problems. When you add new field none of setup scripts will be run on those new fields so they will have none of its original functionality.
There is one solution (At least I see only one):
maximum
repeatable field attribute as mandatory or set default value to something lower (like 30 for performance and bandwidth saving)This should fix JS issues cause all fields will be rendered by framework. Not a script. This has of course downsides. Those fields will be rendered on page render so it can affect performance (that's why I proposed to reduce default maximum
value) and use more bandwidth but this is nothing compared to what happens now.
If only I had time I could test this but for at least 3 weeks I will be to busy. If no one will try this I'll create next month a patch.
Anything new towards fixing this problem?
I'll try to create a patch for this with my solution. Give a me 14 days.
@artur-stepien Do you have any good news?
Today I've discovered about a new issue.
It happens when you have a repeatable field in your component's back-end config form and some other fields (like a text one).
Even if these fields (repeatable and the other) are in different tabs, when you press ENTER on the type text the repeatable box will open-up.
@photodude @artur-stepien @reenan please try #7829 together with #5871, #5655 Repeatable is ok for most fields. There are still some fields that their script has to be rewritten, like calendar
Shucks I just hit the issue with the calendar in a repeatable field :(
I'm pretty busy right now but I will try on the weekend to create a testing upgrade of this with proposed way to handle that kind of problem. I think having website heavier 20-40% is better then having UI issues.
@artur-stepien I look forward to seeing a proposed fix.
I have some time tomorrow i'll try.
Category | Libraries | ⇒ | Fields Libraries |
Guys, Any updates for The User type field ?
How to use User type field in the for the repeatable field type
I am closing this as it has been found to be unfixable and Joomla 3.6 will offer a new feature that will allow a repeatable field using a different methos
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-10 18:56:01 |
Closed_By | ⇒ | brianteeman |
Hi @brianteeman
Joomla 3.8 is now released, do you have knowing of another method ? I still encounter the issue
OK @photodude , thank you for the info !
Anyway PR#17205 will correct this problem : #17205
Possibly related to the issue connected to #6530 Field type "media" inside "Repeatable" field does not show preview