Feature Suggestion -- override default code

mwweb commented

2018-05-09 22:00:25 +00:00

(Migrated from github.com)

This is a feature suggestion. I know that this can be done with custom code, as I have already done it (it was a pain getting all the custom code in place for 20+ fields).

Currently, if a field has the store method set as JSON, then it generates code based on that in the site model. The code is similar to:

{
// [Interpretation 1723] Decode style
$data->style = json_decode($data->style, true);
}

In a lot of cases that might be fine. However, if someone does a bit more of an advanced configuration of that field, such as the field looking up the values from another table, then storing the ID's of the data in json, then it doesn't work. The output would be the IDs rather than the actual data wanted.

My thought is to add another option when creating/editing the field, under the Scripts tab that would show if store method = JSON, for Custom Decode. If custom decode = yes. then it would show a textarea for custom php.

On compile, this custom decode would replace $data->style = json_decode($data->style, true);

An example would be if I added $this->setFeatureFromJson($data,'style',$feature_types); then after compile we would have:

{
// [Interpretation 1723] Decode style
$this->setFeatureFromJson($data,'style',$feature_types);
}

This is a feature suggestion. I know that this can be done with custom code, as I have already done it (it was a pain getting all the custom code in place for 20+ fields). Currently, if a field has the store method set as JSON, then it generates code based on that in the site model. The code is similar to: ```if ({component}Helper::checkJson($data->style)) { // [Interpretation 1723] Decode style $data->style = json_decode($data->style, true); } ``` In a lot of cases that might be fine. However, if someone does a bit more of an advanced configuration of that field, such as the field looking up the values from another table, then storing the ID's of the data in json, then it doesn't work. The output would be the IDs rather than the actual data wanted. My thought is to add another option when creating/editing the field, under the Scripts tab that would show if store method = JSON, for _Custom Decode_. If custom decode = yes. then it would show a textarea for custom php. On compile, this custom decode would replace $data->style = json_decode($data->style, true); An example would be if I added `$this->setFeatureFromJson($data,'style',$feature_types);` then after compile we would have: ```if ({component}Helper::checkJson($data->style)) { // [Interpretation 1723] Decode style $this->setFeatureFromJson($data,'style',$feature_types); } ```

Llewellyn commented

2018-05-10 22:41:12 +00:00

I can see this being a nice feature, but to implement will be not that easy. But it can be done... I will add this to the feature request and see when we get around to do that.

You do know that we have improved the area in the last update right... I mean jsonToString Method has improved dramatically. Take a look...

Just another question, are you saying that you are adding values to the field with javascript, or some custom PHP? because as far as I know dealing with the field they way we do works for all the standard Joomla fields.

But yes it seems like a nice idea... so lets see.

I can see this being a nice feature, but to implement will be not that easy. But it can be done... I will add this to the feature request and see when we get around to do that. You do know that we have improved the area in the last update right... I mean jsonToString Method has improved dramatically. Take a look... Just another question, are you saying that you are adding values to the field with javascript, or some custom PHP? because as far as I know dealing with the field they way we do works for all the standard Joomla fields. But yes it seems like a nice idea... so lets see.

Llewellyn commented

2018-05-11 04:31:43 +00:00

I have another question here, a field gets displayed in two places in the back-end. The list view, if so selected and the edit view.

This custom script you are suggesting, what area will it target?

I have another question here, a field gets displayed in two places in the back-end. The list view, if so selected and the edit view. This custom script you are suggesting, what area will it target?

mwweb commented

2018-05-11 04:52:23 +00:00

(Migrated from github.com)

This is actually the site model

mwweb commented

2018-05-11 04:56:46 +00:00

(Migrated from github.com)

In the admin view i have custom fields pulling the values cron another table. The values selected for that custom field are saved in the db as Json.

In the model, jcb creates code such as stated above. When adding the field to a site view, it gets decoded then displayed.

In the admin view i have custom fields pulling the values cron another table. The values selected for that custom field are saved in the db as Json. In the model, jcb creates code such as stated above. When adding the field to a site view, it gets decoded then displayed.

Llewellyn commented

2018-05-11 05:10:29 +00:00

Okay in that case, I hope you realize the complexity of the dynamicGet leaves us with so many outcomes that is seems impossible to cover them all. Yet we have done so crazy implementations already.

I mean lets face it, the one field comes up in many places, and JCB adapts the field as it relates to the related model, this already is very hard to do. To now add a custom code area to each field for each possible place the field could be used is going to be very hard...

Since it could be used in a list view, a single view, and the the admin-areas so that is four target areas each with different implementation in relation to the call structure.

My main concern is not how to do this, but it is hard to understand how JCB works already, and adding even more complexity on top of it is not ideal.

Please allow me to ponder this some more, maybe their is away to keep it simple. I am all for making JCB even more powerful, so I still want to explore this idea more. Do you have more perspective/ideas having read my response... please let me know.

Okay in that case, I hope you realize the complexity of the dynamicGet leaves us with so many outcomes that is seems impossible to cover them all. Yet we have done so crazy implementations already. I mean lets face it, the one field comes up in many places, and JCB adapts the field as it relates to the related model, this already is very hard to do. To now add a custom code area to each field for each possible place the field could be used is going to be very hard... Since it could be used in a list view, a single view, and the the admin-areas so that is four target areas each with different implementation in relation to the call structure. My main concern is not how to do this, but it is hard to understand how JCB works already, and adding even more complexity on top of it is not ideal. Please allow me to ponder this some more, maybe their is away to keep it simple. I am all for making JCB even more powerful, so I still want to explore this idea more. Do you have more perspective/ideas having read my response... please let me know.

mwweb commented

2018-05-11 07:29:22 +00:00

(Migrated from github.com)

Not knowing a whole lot about the compiler, I'm not even sure where to start. Initially I was just thinking along the lines of a condition in the processing, if override==1 then process custom, else default. But with so many other areas, that does make it more complex.

Llewellyn commented

2018-05-16 23:52:17 +00:00

There are plans to improve the site views area, so we will get back to this feature at that point. For now you can only with custom scripting in the dynamicGet area achieve this.

There are plans to improve the site views area, so we will get back to this feature **at that point**. For now you can only with custom scripting in the dynamicGet area achieve this.

mwweb commented

2018-08-25 22:56:05 +00:00

(Migrated from github.com)

I've been trying to think on this, as at least for myself I find this very important. Every time a new version of JCB is released I look forward to the changes/additions, but I also cringe, knowing that I'm going to have to spend a whole day resetting my custom code on fields.

In a field, if store=1 (Store Method = 1), then new options show on the scripts tab. The first option is a yes/no for override JSON code. If yes, then there is an option for Frontend/backend/All, and a text are to enter the code that would be used instead of the JCB generated code.

For example, if JCB would normally create:

$data->style = json_decode($data->style, true);

but I wanted:

$this->setFeatureFromJson($data,'style',$feature_types);

I could enter that code in the text area, and it would be used instead of the JCB code. So, if I set the option to frontend, then anywhere in the model that that code would normally be generated, would be replaced with the custom code that I entered.

I've been trying to think on this, as at least for myself I find this very important. Every time a new version of JCB is released I look forward to the changes/additions, but I also cringe, knowing that I'm going to have to spend a whole day resetting my custom code on fields. In a field, if store=1 (Store Method = 1), then new options show on the scripts tab. The first option is a yes/no for override JSON code. If yes, then there is an option for Frontend/backend/All, and a text are to enter the code that would be used instead of the JCB generated code. For example, if JCB would normally create: `$data->style = json_decode($data->style, true);` but I wanted: `$this->setFeatureFromJson($data,'style',$feature_types);` I could enter that code in the text area, and it would be used instead of the JCB code. So, if I set the option to frontend, then anywhere in the model that that code would normally be generated, would be replaced with the custom code that I entered.

Llewellyn commented

2018-08-26 23:36:50 +00:00

I hear you.. I personally do not use much custom code (that changes JCB generated code) and so I do not always realize the effect it is having on those who do use the custom when we make changes to JCB.

Yet your idea has been in my mind since I can see how that will really improve this struggle.

We can add the option to add custom a storage option, retrieval and modeling of each field. That basically takes that field out of the normal flow of how JCB does things. So where you now in the field can select various Storage Methods, we add more options, including a custom option. We also add Get Methods, and Model Methods so you can per field tweak these behaviors. Yet to add this will be a huge undertaking, for which I do not have time at the moment. But I want to... really it will be very exiting!

But with relation to the issue you face in your last post, watch this little video and let me know if it helps.

I hear you.. I personally do not use much custom code (that changes JCB generated code) and so I do not always realize the effect it is having on those who do use the custom when we make changes to JCB. Yet your idea has been in my mind since I can see how that will really improve this struggle. We can add the option to add custom a storage option, retrieval and modeling of each field. That basically takes that field out of the normal flow of how JCB does things. So where you now in the field can select various Storage Methods, we add more options, including a custom option. We also add Get Methods, and Model Methods so you can per field tweak these behaviors. Yet to add this will be a huge undertaking, for which I do not have time at the moment. But I want to... really it will be very exiting! But with relation to the issue you face in your last post, watch this [little video](https://youtu.be/QGMURJI_Mds) and let me know if it helps.

Llewellyn commented

2020-11-26 22:21:25 +00:00

Okay the new advance storage option allows for this feature to work very easy... if you need help to understand this watch this video, and let me know if you have any questions. I am moving this to DONE.

Okay the new advance storage option allows for this feature to work very easy... if you need help to understand this [watch this video](https://www.youtube.com/watch?v=JjAdCDQ8ht8&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=89), and let me know if you have any questions. I am moving this to DONE.

Feature Suggestion -- override default code #281