Feature request: Extending custom fields to allow getinput override

AlexDings commented

2018-09-17 23:13:42 +00:00

(Migrated from github.com)

Expected result

As custom fields are used within JCB to allow for field-type changes, I would like to be able to overwrite the getInput() function of a custom field, the same way it is currently possible to do this for the getOptions() function.

This would allow people to have more control over the field's appearance and behavior.
An example would be to easily add extra data parameters to the field.
Referencing this: Joomla documentation: Creating a custom form field type

Actual result

New feature: getInput() overwrite ability within custom fields in JCB..

Additional comments

Follow up from this forum post:
Custom field types

### Expected result As custom fields are used within JCB to allow for field-type changes, I would like to be able to overwrite the getInput() function of a custom field, the same way it is currently possible to do this for the getOptions() function. This would allow people to have more control over the field's appearance and behavior. An example would be to easily add extra data parameters to the field. Referencing this: [Joomla documentation: Creating a custom form field type](https://www.google.com/url?q=https%3A%2F%2Fdocs.joomla.org%2FCreating_a_custom_form_field_type&sa=D&sntz=1&usg=AFQjCNFjuhEgDxBIe95Aps-vrmz-m1DxFw) ### Actual result New feature: getInput() overwrite ability within custom fields in JCB.. ### Additional comments Follow up from this forum post: [Custom field types](https://groups.google.com/a/vdm.io/forum/?utm_medium=email&utm_source=footer#!topic/jcb/nS24TX0CUik)

Llewellyn commented

2018-09-24 16:29:25 +00:00

Okay I think I have it ready for testing... it came out little different then I planned originally, but I think you will like how it works.

Here is a quick tutorial on how to use this feature. @AlexDings please test this on your side and let me know if it works as expected.

Okay I think I have it ready for testing... it came out little different then I planned originally, but I think you will like how it works. Here is a [quick tutorial](https://youtu.be/Mu9H0zgH9Lw) on how to use this feature. @AlexDings please test this on your side and let me know if it works as expected.

❤️ 1

AlexDings commented

2018-09-25 20:55:25 +00:00

(Migrated from github.com)

Thanks for the quick work.
I am quite busy with work right now but will make sure to get you all my feedback by the end of this week

Thanks for the quick work. I am quite busy with work right now but will make sure to get you all my feedback by the end of this week

Llewellyn commented

2018-09-26 00:40:28 +00:00

Lets just say I also needed this feature 👍

Lets just say I also needed this feature :+1:

👍 1

AlexDings commented

2018-09-26 18:57:29 +00:00

(Migrated from github.com)

The feature is looking good, and I could work with it.
However, right now the type_phpa-z values are treated as default values and are overwritten when creating the field which uses this fieldtype.

Would it be possible to make it so that the php for this fieldtype is set, and (1) this can't be changed on the field creation and (2) it gets the value from the fieldtype on field generation.
This would work better for me since I will have 10 fields using this unique list-getinput method. Having this in the fieldtype and not the field would allow me to update it on one place and have it have effect on all the fields using this fieldtype.
The switch for this could possibly be in selecting adjustable or not.

I realize this is out of scope for the original request, which worked with the fact that fieldtypes weren't really expandable.

The feature is looking good, and I could work with it. However, right now the type_phpa-z values are treated as default values and are overwritten when creating the field which uses this fieldtype. Would it be possible to make it so that the php for this fieldtype is set, and (1) this can't be changed on the field creation and (2) it gets the value from the fieldtype on field generation. This would work better for me since I will have 10 fields using this unique list-getinput method. Having this in the fieldtype and not the field would allow me to update it on one place and have it have effect on all the fields using this fieldtype. The switch for this could possibly be in selecting adjustable or not. I realize this is out of scope for the original request, which worked with the fact that fieldtypes weren't really expandable.

Llewellyn commented

2018-09-26 21:12:59 +00:00

I am not sure I understand, but for what its worth... ones you create the new custom-custom field-type just code what you want, I mean all you want it to do in to the type_php_a and b and c and so on... then when creating the field, just don't edit it, let the default be the actual. Or am I missing something?

You don't have to edit those fields, you can with placeholders make it dynamic like the original custom field.

I am not sure I understand, but for what its worth... ones you create the new custom-custom field-type just code what you want, I mean all you want it to do in to the type_php_a and b and c and so on... then when creating the field, just don't edit it, let the default be the actual. Or am I missing something? You don't have to edit those fields, you can with placeholders make it dynamic like the original custom field.

Llewellyn commented

2018-09-26 21:14:42 +00:00

If I still don't get your question, best give some pictures :) since to me this option should also work for what you are looking for.

Llewellyn commented

2018-09-26 21:45:44 +00:00

I think the one thing we can do to make this easy, is to allow more then one line per line, so we do not need to do line for line... that is little slow... let me see if this will be easy to change.

👍 1

Llewellyn commented

2018-09-26 22:10:18 +00:00

Okay that was not that hard... now you can in one line add the whole code function. Should make it easier.

🎉 1

AlexDings commented

2018-09-28 00:01:26 +00:00

(Migrated from github.com)

The multi-line addition is great!

I am not sure how to illustrate with images, but I think you were almost following.

@Llewellynvdm: "ones you create the new custom-custom field-type just code what you want" ... "then when creating the field, just don't edit it, let the default be the actual."

Let's imagine I did this. My desired behavior now is that when I update the "custom-custom field-type code" this also gets updated in all created fields using this "custom-custom field-type".

This would allow me to update this code in one place only, and not across all fields that use this "custom-custom field-type".

The multi-line addition is great! I am not sure how to illustrate with images, but I think you were almost following. > @Llewellynvdm: "ones you create the new custom-custom field-type just code what you want" ... "then when creating the field, just don't edit it, let the default be the actual." Let's imagine I did this. My desired behavior now is that when I update the "custom-custom field-type code" this also gets **updated** in all created fields using this "custom-custom field-type". This would allow me to update this code in one place only, and not across all fields that use this "custom-custom field-type".

Llewellyn commented

2018-09-28 13:01:00 +00:00

Hmm there is an easy way to do this with custom code place holders.

So lets say you have a new custom-custom field type and it has a type_php_a and a type_php_b field then in those fields, add placeholder of your customcode. This way you have one place to control the code. That is the power of the customcode placeholder idea...

I am doing this with a note... but you can do it in any field or (custom-custom fieldtype):

Here I am doing it with a custom field:

So you still build your custom-custom fieldtype.. then as code in the fieldtype, you add a customcode placeholder like this:

Then you just need to update the code in the custom code area... and it will automatically update in every field, you build with that new custom-custom fieldtype.

Crazy right... well it works 👍

Hmm there is an easy way to do this with custom code place holders. So lets say you have a new custom-custom field type and it has a type_php_a and a type_php_b field then in those fields, add placeholder of your customcode. This way you have one place to control the code. That is the **power of the customcode** placeholder idea... **I am doing this with a note... but you can do it in any field or (custom-custom fieldtype):** ![image](https://user-images.githubusercontent.com/5607939/46209501-4f3b5300-c32e-11e8-89d3-c8a448de77ca.png) ![image](https://user-images.githubusercontent.com/5607939/46209513-5a8e7e80-c32e-11e8-9636-47a286f098ac.png) ![image](https://user-images.githubusercontent.com/5607939/46209526-64b07d00-c32e-11e8-8406-7e668e79e954.png) ![image](https://user-images.githubusercontent.com/5607939/46209566-78f47a00-c32e-11e8-97be-680fede19baa.png) **Here I am doing it with a custom field:** ![image](https://user-images.githubusercontent.com/5607939/46209671-beb14280-c32e-11e8-82c1-2a8be35be35f.png) So you still build your **custom-custom fieldtype**.. then as code in the fieldtype, you add a customcode placeholder like this: ![image](https://user-images.githubusercontent.com/5607939/46209820-30898c00-c32f-11e8-9f83-533af01b8fe2.png) Then you just need to update the code in the custom code area... and it will automatically update in every field, you build with that new custom-custom fieldtype. Crazy right... well it works :+1:

😆 1

Llewellyn commented

2018-09-28 13:31:15 +00:00

I just found that I had to update the search for where customcode placeholders are used, due to the new base64 storage of the php in the fields. I made that change so we can use ' and " in the code... so with the next push to staging this will also be fixed.

I just found that I had to update the search for where customcode placeholders are used, due to the new base64 storage of the php in the fields. I made that change so we can use `'` and `"` in the code... so with the next push to staging this will also be fixed.

❤️ 1

AlexDings commented

2018-09-29 11:02:15 +00:00

(Migrated from github.com)

For some reason the value of phpa doesn't get stored in the custom field.

custom-custom fieldtype:

I can see this default in the field, but it disappears on save. The value of php_1 does get stored.

The code inside "[CUSTOMCODE=basicFieldGetInput]" is just the default getinput function.

For some reason the value of phpa doesn't get stored in the custom field. custom-custom fieldtype: ![image](https://user-images.githubusercontent.com/12542207/46244991-65591a00-c3e7-11e8-8570-19fba8f720d6.png) I can see this default in the field, but it disappears on save. The value of php_1 does get stored. ![image](https://user-images.githubusercontent.com/12542207/46245004-a18c7a80-c3e7-11e8-9e4a-bc0111253d3d.png) The code inside "[CUSTOMCODE=basicFieldGetInput]" is just the default getinput function.

Llewellyn commented

2018-09-29 14:43:12 +00:00

Let me check... that worked the last time... wonder what happened. Will get back to you.

AlexDings commented

2018-09-29 18:38:21 +00:00

(Migrated from github.com)

Thank you.
I will continue for now to program the functionality I need and will later on pour it into this field

Thank you. I will continue for now to program the functionality I need and will later on pour it into this field

AlexDings commented

2018-09-29 19:39:26 +00:00

(Migrated from github.com)

Access to field-parameters
When creating multiple fields of type "custom-custom fieldtype", these all create the same file under com_component>models>fields>customfieldtypename.php. This file is population with the values of the ###VALUE### placeholders of 1 of the fields, making all fields the same.

If this is desired behavior, people can't use component builder's ###VALUE### placeholders.
I haven't found these variables in the field's object, where the field's "id" and "name" are found either. Is there any other way to access them?

I would suggest using the field's name to create these php files, so many custom fields of the same custom-custom fieldtype may exist, which also allows people to use the ###VALUE### placeholders.

**Access to field-parameters** When creating multiple fields of type "custom-custom fieldtype", these all create the same file under com_component>models>fields>customfieldtypename.php. This file is population with the values of the ###VALUE### placeholders of 1 of the fields, making all fields the same. If this is desired behavior, people can't use component builder's ###VALUE### placeholders. I haven't found these variables in the field's object, where the field's "id" and "name" are found either. Is there any other way to access them? I would suggest using the field's name to create these php files, so many custom fields of the same custom-custom fieldtype may exist, which also allows people to use the ###VALUE### placeholders.

Llewellyn commented

2018-09-29 21:45:10 +00:00

Please watch this https://youtu.be/_1Xi6FlWuG0, and help me see where I am doing things different and how this has effected the expected result, so I can redo the previous tutorial.

👍 1

AlexDings commented

2018-09-30 21:20:35 +00:00

(Migrated from github.com)

I have played around with it today and found that custom fields in subforms don't get compiled.
This seems to be the biggest issue I am having. And when a field is both in a subform, and outside a subform in 1 admin view things get even weirder.

The result of this is a php file that get's created for the field, but doesn't get filled.


/*----------------------------------------------------------------------------------|  www.vdm.io  |----/
				Component
/-------------------------------------------------------------------------------------------------------/

	@version		1.0.89
	@build			30th September, 2018
	@created		4th February, 2018
	@package		component
	@subpackage		singletest.php
	@author			Dings <http://din.gs>	
	@copyright		Copyright (C) All Rights Reserved
	@license		Proprietary
  ____  _____  _____  __  __  __      __       ___  _____  __  __  ____  _____  _  _  ____  _  _  ____ 
 (_  _)(  _  )(  _  )(  \/  )(  )    /__\     / __)(  _  )(  \/  )(  _ \(  _  )( \( )( ___)( \( )(_  _)
.-_)(   )(_)(  )(_)(  )    (  )(__  /(__)\   ( (__  )(_)(  )    (  )___/ )(_)(  )  (  )__)  )  (   )(  
\____) (_____)(_____)(_/\/\_)(____)(__)(__)   \___)(_____)(_/\/\_)(__)  (_____)(_)\_)(____)(_)\_) (__) 

/------------------------------------------------------------------------------------------------------*/

// No direct access to this file
defined('_JEXEC') or die('Restricted access');

// import the ###JFORM_extends### field type
jimport('joomla.form.helper');
JFormHelper::loadFieldClass('###JFORM_extends###');

/**
 * Singletest Form Field class for the Everycharacter component
 */
class JFormFieldSingletest extends JFormField###JFORM_EXTENDS###
{
	/**
	 * The singletest field type.
	 *
	 * @var		string
	 */
	public $type = 'singletest';###JFORM_TYPE_PHP###
}

I have played around with it today and found that custom fields in subforms don't get compiled. This seems to be the biggest issue I am having. And when a field is both in a subform, and outside a subform in 1 admin view things get even weirder. The result of this is a php file that get's created for the field, but doesn't get filled. ```<?php /*----------------------------------------------------------------------------------| www.vdm.io |----/ Component /-------------------------------------------------------------------------------------------------------/ @version 1.0.89 @build 30th September, 2018 @created 4th February, 2018 @package component @subpackage singletest.php @author Dings <http://din.gs> @copyright Copyright (C) All Rights Reserved @license Proprietary ____ _____ _____ __ __ __ __ ___ _____ __ __ ____ _____ _ _ ____ _ _ ____ (_ _)( _ )( _ )( \/ )( ) /__\ / __)( _ )( \/ )( _ \( _ )( \( )( ___)( \( )(_ _) .-_)( )(_)( )(_)( ) ( )(__ /(__)\ ( (__ )(_)( ) ( )___/ )(_)( ) ( )__) ) ( )( \____) (_____)(_____)(_/\/\_)(____)(__)(__) \___)(_____)(_/\/\_)(__) (_____)(_)\_)(____)(_)\_) (__) /------------------------------------------------------------------------------------------------------*/ // No direct access to this file defined('_JEXEC') or die('Restricted access'); // import the ###JFORM_extends### field type jimport('joomla.form.helper'); JFormHelper::loadFieldClass('###JFORM_extends###'); /** * Singletest Form Field class for the Everycharacter component */ class JFormFieldSingletest extends JFormField###JFORM_EXTENDS### { /** * The singletest field type. * * @var string */ public $type = 'singletest';###JFORM_TYPE_PHP### } ```

AlexDings commented

2018-09-30 21:32:48 +00:00

(Migrated from github.com)

About the tutorial, I believe the first one was clear enough. You are extremely good at explaining

Llewellyn commented

2018-09-30 23:00:37 +00:00

ahaaa I have not tested that... I will take a look, not sure why it would do that... but it is possible.

Llewellyn commented

2018-10-01 02:32:35 +00:00

Okay tryout the last update, on my side it is working as expected. Adding the custom-custom field (subject) to a subform and as a normal field in the same view:

<!-- Options Field. Type: Subform. (joomla) -->
<field
	type="subform"
	name="options"
	label="COM_DEMO_LOOK_OPTIONS_LABEL"
	layout="joomla.form.field.subform.repeatable-table"
	multiple="true"
	buttons="add,remove,move"
	icon="list"
	max="50">
	<form hidden="true" name="list_options_modal" repeat="true">
		<!-- Subject Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject"
			label="COM_DEMO_LOOK_SUBJECT_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
	</form>
</field>
<!-- Subject Field. Type: Subjects. (custom) -->
<field
	type="subjects"
	name="subject"
	label="COM_DEMO_LOOK_SUBJECT_LABEL"
	multiple="false"
/>

Then adding the same field multiple times to a subform and multiple times as a normal field to the same view.

This will cause the field name to change of course (to avoid data lose in the database), lets say the field name is subject and you add it more then once to a view, it will become subject_one & subject_two... Then if you add the same field to a subform in the same view, it will just again be subject in the subform, but if you also add it multiple times in the subform it will also become incremental with in the subfrom like this:

<!-- Options_one Field. Type: Subform. (joomla) -->
<field
	type="subform"
	name="options_one"
	label="COM_DEMO_LOOK_OPTIONS_ONE_LABEL"
	layout="joomla.form.field.subform.repeatable-table"
	multiple="true"
	buttons="add,remove,move"
	icon="list"
	max="50">
	<form hidden="true" name="list_options_one_modal" repeat="true">
		<!-- Subject_one Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_one"
			label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
		<!-- Subject_two Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_two"
			label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
		<!-- Subject_three Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_three"
			label="COM_DEMO_LOOK_SUBJECT_THREE_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
	</form>
</field>
<!-- Subject_one Field. Type: Subjects. (custom) -->
<field
	type="subjects"
	name="subject_one"
	label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL"
	multiple="false"
/>
<!-- Options_two Field. Type: Subform. (joomla) -->
<field
	type="subform"
	name="options_two"
	label="COM_DEMO_LOOK_OPTIONS_TWO_LABEL"
	layout="joomla.form.field.subform.repeatable-table"
	multiple="true"
	buttons="add,remove,move"
	icon="list"
	max="50">
	<form hidden="true" name="list_options_two_modal" repeat="true">
		<!-- Subject_one Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_one"
			label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
		<!-- Subject_two Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_two"
			label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
		<!-- Subject_three Field. Type: Subjects. (custom) -->
		<field
			type="subjects"
			name="subject_three"
			label="COM_DEMO_LOOK_SUBJECT_THREE_LABEL"
			multiple="false"
			required="false"
			button="false"
		/>
	</form>
</field>
<!-- Subject_two Field. Type: Subjects. (custom) -->
<field
	type="subjects"
	name="subject_two"
	label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL"
	multiple="false"
/>

As you can see in all these ways the type remains the same as subjects, and in my test it created the new custom-custom field type called subjects and it update it correctly as expected.

So let me know how it turned out on your side 👍

Okay tryout the last update, on my side it is working as expected. Adding the custom-custom field (subject) to a subform and as a normal field in the same view: ```xml  <field type="subform" name="options" label="COM_DEMO_LOOK_OPTIONS_LABEL" layout="joomla.form.field.subform.repeatable-table" multiple="true" buttons="add,remove,move" icon="list" max="50"> <form hidden="true" name="list_options_modal" repeat="true">  <field type="subjects" name="subject" label="COM_DEMO_LOOK_SUBJECT_LABEL" multiple="false" required="false" button="false" /> </form> </field>  <field type="subjects" name="subject" label="COM_DEMO_LOOK_SUBJECT_LABEL" multiple="false" /> ``` Then adding the same field multiple times to a subform and multiple times as a normal field to the same view. This will cause the field name to change of course (to avoid data lose in the database), lets say the field name is `subject` and you add it more then once to a view, it will become `subject_one` & `subject_two`... Then if you add the same field to a subform in the same view, it will just again be `subject` in the subform, but if you also add it multiple times in the subform it will also become incremental with in the subfrom like this: ```xml  <field type="subform" name="options_one" label="COM_DEMO_LOOK_OPTIONS_ONE_LABEL" layout="joomla.form.field.subform.repeatable-table" multiple="true" buttons="add,remove,move" icon="list" max="50"> <form hidden="true" name="list_options_one_modal" repeat="true">  <field type="subjects" name="subject_one" label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL" multiple="false" required="false" button="false" />  <field type="subjects" name="subject_two" label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL" multiple="false" required="false" button="false" />  <field type="subjects" name="subject_three" label="COM_DEMO_LOOK_SUBJECT_THREE_LABEL" multiple="false" required="false" button="false" /> </form> </field>  <field type="subjects" name="subject_one" label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL" multiple="false" />  <field type="subform" name="options_two" label="COM_DEMO_LOOK_OPTIONS_TWO_LABEL" layout="joomla.form.field.subform.repeatable-table" multiple="true" buttons="add,remove,move" icon="list" max="50"> <form hidden="true" name="list_options_two_modal" repeat="true">  <field type="subjects" name="subject_one" label="COM_DEMO_LOOK_SUBJECT_ONE_LABEL" multiple="false" required="false" button="false" />  <field type="subjects" name="subject_two" label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL" multiple="false" required="false" button="false" />  <field type="subjects" name="subject_three" label="COM_DEMO_LOOK_SUBJECT_THREE_LABEL" multiple="false" required="false" button="false" /> </form> </field>  <field type="subjects" name="subject_two" label="COM_DEMO_LOOK_SUBJECT_TWO_LABEL" multiple="false" /> ``` As you can see in all these ways the type remains the same as `subjects`, and in my test it created the new custom-custom field type called `subjects` and it update it correctly as expected. So let me know how it turned out on your side :+1:

❤️ 1 🎉 1

AlexDings commented

2018-10-01 22:11:31 +00:00

(Migrated from github.com)

Great! This final update fixed it for me and I believe it is all working as is expected.
Amazing work!

I will continue to build with it and let you know if I find issues with it.

Great! This final update fixed it for me and I believe it is all working as is expected. Amazing work! I will continue to build with it and let you know if I find issues with it.

🎉 1

ro-ot commented

2018-10-05 10:42:09 +00:00

(Migrated from github.com)

This is a stunning new feature, I have also tested it and it works amazing. Great work @Llewellynvdm :octocat:

Feature request: Extending custom fields to allow getinput override #341

Expected result

Actual result

Additional comments