Roundtrip development

marcodings commented

2019-07-24 11:21:13 +00:00

(Migrated from github.com)

feature request

My typical workflow is to start with JCP and do significant customisations using an IDE (php storm).
For exmple (but not limited to ) the getForm method in the model

It is a PITA to manually copy back changes into the GUI in all the different places. And for true roud trip development i would like to see this automated.

JCB has the /***[INSERTED$$$$]***//*34*/ (and others) which will automagically loads changes back into the specified custom codes upon compilation and outputs the afterwards. This feature request could be based on the same/similar mechanism to update those code snippets like getForm.
I would suggest an explicit action to reload/sync up the gui. This should be relatively straight forward if no placholders are used in the snippits. Should place holders be used the will be expanded upon compilation and thereafter are not updated when the placeholder gets "updated". This is an aspect that would require attention. On could consider "tagging" placeholders so they could be "imploded" when reading back?

feature request My typical workflow is to start with JCP and do significant customisations using an IDE (php storm). For exmple (but not limited to ) the getForm method in the model ![image](https://user-images.githubusercontent.com/3484222/61789213-65158980-ae14-11e9-823c-cdc0fc6f2617.png) It is a PITA to manually copy back changes into the GUI in all the different places. And for true roud trip development i would like to see this automated. JCB has the `/***[INSERTED$$$$]***//*34*/` (and others) which will automagically loads changes back into the `specified` custom codes upon compilation and outputs the afterwards. This feature request could be based on the same/similar mechanism to update those code snippets like getForm. I would suggest an explicit action to reload/sync up the gui. This should be relatively straight forward if no `placholders` are used in the snippits. Should place holders be used the will be expanded upon compilation and thereafter are not updated when the placeholder gets "updated". This is an aspect that would require attention. On could consider "tagging" placeholders so they could be "imploded" when reading back?

Llewellyn commented

2019-07-24 20:19:30 +00:00

I think we can add this, it does seem very close to the original request that caused custom-code to be added in the first place.

There are some very serious issues here, like the one mentioned, when there is custom code placheloder in the getForm php block. There is also the next evolution of JCB where we are having placeholders all over, local to a component and global to all components.

So to solve this, we simply have the restriction that if any of the above is found in the code block, just like in custom-code at this time, we do not do round-trip, so those code blocks can only be updated in the GUI of JCB.

So lets say we add a new placeholder that looks like this

/***[JCBGUI.TABLE.FIELD.ID$$$$]***/
	// the code from the getForm field in the admin_view for example
	if($id)
	{
		// Disable fields for display.
		$form->setFieldAttribute('the_field', 'disabled', 'true');
	}
/***[/JCBGUI.TABLE.FIELD.ID$$$$]***/

Then to update we add this <> between the ID and the $$$$'s

/***[JCBGUI.TABLE.FIELD.ID<>$$$$]***/
	// the code from the getForm field in the admin_view for example
	if($id)
	{
		// Disable fields for display.
		$form->setFieldAttribute('the_field', 'disabled', 'true');
		// Disable fields for display.
		$form->setFieldAttribute('the_field', 'readonly', 'true');
		// Disable fields while saving.
		$form->setFieldAttribute('the_field', 'filter', 'unset');
	}
/***[/JCBGUI.TABLE.FIELD.ID<>$$$$]***/

This does nor require code positioning as we know where and when it must always be added back, but it cannot take customcode placeholders or the new placeholders, just code!

I think I can get this to work very easy.

I think we can add this, it does seem very close to the original request that caused custom-code to be added in the first place. There are some very serious issues here, like the one mentioned, when there is custom code placheloder in the getForm php block. There is also the next evolution of JCB where we are having placeholders all over, local to a component and global to all components. So to solve this, we simply have the restriction that if any of the above is found in the code block, just like in custom-code at this time, we do not do round-trip, so those code blocks can only be updated in the GUI of JCB. So lets say we add a new placeholder that looks like this ```php /***[JCBGUI.TABLE.FIELD.ID$$$$]***/ // the code from the getForm field in the admin_view for example if($id) { // Disable fields for display. $form->setFieldAttribute('the_field', 'disabled', 'true'); } /***[/JCBGUI.TABLE.FIELD.ID$$$$]***/ ``` Then to update we add this `<>` between the ID and the $$$$'s ```php /***[JCBGUI.TABLE.FIELD.ID<>$$$$]***/ // the code from the getForm field in the admin_view for example if($id) { // Disable fields for display. $form->setFieldAttribute('the_field', 'disabled', 'true'); // Disable fields for display. $form->setFieldAttribute('the_field', 'readonly', 'true'); // Disable fields while saving. $form->setFieldAttribute('the_field', 'filter', 'unset'); } /***[/JCBGUI.TABLE.FIELD.ID<>$$$$]***/ ``` This does nor require code positioning as we know where and when it must always be added back, but it cannot take customcode placeholders or the new placeholders, just code! I think I can get this to work very easy.

Llewellyn commented

2019-07-24 20:26:19 +00:00

I may still change the placeholder implementation.. but the idea can work.

marcodings commented

2019-07-25 05:58:08 +00:00

(Migrated from github.com)

That seems great !

Llewellyn commented

2019-07-25 13:42:32 +00:00

I started out, and found this will take more then I initially thought, since we now will need the table field and id every time we add any code from the GUI... this is not how JCB worked... but I am almost finished with a few new functions and conventions that will add that layer... This idea is going to really be a great step forward for JCB!

I started out, and found this will take more then I initially thought, since we now will need the `table` `field` and `id` every time we add any code from the GUI... this is not how JCB worked... but I am almost finished with a few new functions and conventions that will add that layer... This idea is going to really be a great step forward for JCB!

👍 1

Llewellyn commented

2019-07-27 21:07:16 +00:00

Okay so this feature is nearly done.

I will have to make tutorial of how it works, but before I do... here is some guidelines:

To add the placeholder for GUI code is the same switch for the custom code:
This will add the GUI placeholders only where there is no custom code placeholders in the code.
The placeholders will look like this:

/***[JCBGUI.admin_view.php_before_save.14.$$$$]***/
		// if system name is empty create from name_single
		if (empty($data['system_name']) || !ComponentbuilderHelper::checkString($data['system_name']))
		{
			$data['system_name'] = $data['name_single'];
		}
/***[/JCBGUI$$$$]***/

To update the area you only need replace the first dot . with <> in in the top placeholder like this:

/***[JCBGUI<>admin_view.php_before_save.14.$$$$]***/
		// if system name is empty create a system name from the name_single
		if (empty($data['system_name']) || !ComponentbuilderHelper::checkString($data['system_name']))
		{
			$data['system_name'] = $data['name_single'];
		}
/***[/JCBGUI$$$$]***/

Note that the last placeholder does not need to change like with the custom-code placeholders. I know this is confusing... but hey its better I would rather change the latter 👍 (not that I did)

So it will be that simple, I will push the changes up for testing later tonight 🎆

Okay so this feature is nearly done. I will have to make tutorial of how it works, but before I do... here is some guidelines: - To add the placeholder for GUI code is the same switch for the custom code: ![image](https://user-images.githubusercontent.com/5607939/61999469-dd54a700-b0c1-11e9-87dc-bb2c323ba7e3.png) - This will add the GUI placeholders only where there is no custom code placeholders in the code. - The placeholders will look like this: ``` /***[JCBGUI.admin_view.php_before_save.14.$$$$]***/ // if system name is empty create from name_single if (empty($data['system_name']) || !ComponentbuilderHelper::checkString($data['system_name'])) { $data['system_name'] = $data['name_single']; } /***[/JCBGUI$$$$]***/ ``` - To update the area you only need replace the first dot `.` with `<>` in in the top placeholder like this: ``` /***[JCBGUI<>admin_view.php_before_save.14.$$$$]***/ // if system name is empty create a system name from the name_single if (empty($data['system_name']) || !ComponentbuilderHelper::checkString($data['system_name'])) { $data['system_name'] = $data['name_single']; } /***[/JCBGUI$$$$]***/ ``` > Note that the last placeholder does not need to change like with the custom-code placeholders. I know this is confusing... but hey its better I would rather change the latter :+1: (not that I did) So it will be that simple, I will push the changes up for testing later tonight :fireworks:

marcodings commented

2019-07-28 09:42:26 +00:00

(Migrated from github.com)

Thanks.. awaiting commits/push

Llewellyn commented

2019-07-28 21:55:39 +00:00

Okay it is out... let me know. There is a few areas that we can't target, like all custom code added in subforms like the dashboard area and other. But the rest should work as long as it does not have customcode placeholders, these two can not work together for now.

Llewellyn commented

2019-07-28 22:17:51 +00:00

Okay so since so many lines changed, the file to look at is the a_Get.php since it is all that changed to add this functionality.

You will see a few new functions:

setCustomScriptBuilder on line 3707
setGuiCodePlaceholder on line 6776
canAddGuiCodePlaceholder on line 6848
guiCodeSearch on line 6870

These form the foundation of the new feature, if you wanted to understand how is done, and give suggestion to improve 👍

Okay so since so many lines changed, the file to look at is the [a_Get.php](https://github.com/vdm-io/Joomla-Component-Builder/commit/4581b310de699713ac81131794ffc313cfc6c0ac#diff-8949b2e81d0b137d4016fac7f403109e) since it is all that changed to add this functionality. You will see a few new functions: - setCustomScriptBuilder [on line 3707](https://github.com/vdm-io/Joomla-Component-Builder/blob/4581b310de699713ac81131794ffc313cfc6c0ac/admin/helpers/compiler/a_Get.php#L3707) - setGuiCodePlaceholder [on line 6776](https://github.com/vdm-io/Joomla-Component-Builder/blob/4581b310de699713ac81131794ffc313cfc6c0ac/admin/helpers/compiler/a_Get.php#L6776) - canAddGuiCodePlaceholder [on line 6848](https://github.com/vdm-io/Joomla-Component-Builder/blob/4581b310de699713ac81131794ffc313cfc6c0ac/admin/helpers/compiler/a_Get.php#L6848) - guiCodeSearch [on line 6870](https://github.com/vdm-io/Joomla-Component-Builder/blob/4581b310de699713ac81131794ffc313cfc6c0ac/admin/helpers/compiler/a_Get.php#L6870) These form the foundation of the new feature, if you wanted to understand how is done, and give suggestion to improve :+1:

Roundtrip development #451