[BUG?] Q&A: unable to save the AllCategories (SD) dynamicGet #494

Closed
opened 2019-11-24 09:18:21 +00:00 by jcodewalker · 2 comments
jcodewalker commented 2019-11-24 09:18:21 +00:00 (Migrated from github.com)

Steps to reproduce the issue

Open AllCategories (SD) dynamicGet from Q&A component
Try to save it without any change

Expected result

Element saved

Actual result

It requires the "state key" field to be set

System information (as much as possible)

  • OS Name & Version:
  • MySql Version:
  • Apache Version:
  • PHP Version:
  • Joomla Version:
  • JCB Version: 2.10.5
  • Browser:

Additional comments

My question is: if I'm not able to save your example component without any change, how it has been made? And, more important, how can I replicate it?

### Steps to reproduce the issue Open AllCategories (SD) dynamicGet from Q&A component Try to save it without any change ### Expected result Element saved ### Actual result It requires the "state key" field to be set ### System information (as much as possible) - OS Name & Version: - MySql Version: - Apache Version: - PHP Version: - Joomla Version: - JCB Version: 2.10.5 - Browser: ### Additional comments My question is: if I'm not able to save your example component without any change, how it has been made? And, more important, how can I replicate it?

Okay so at some point in the history of Joomla the sub-form field type did not support required fields. It was during this time that that dynamicGet was made. Since then things have been improved, and now sub-forms do support required fields.
image
As you can see I also now get the same error as you do.

When we look at the code in the compiler where that state is being used it does not require you to add the state_key since it defaults to the $this->levels that are dynamicly set in each model.

That is why it worked in the past even with the value empty. Now we have two options, one you just add $this->levels to be able to save the dynamicGet, and being able to use the access levels filter. But really since it is not used you can add anything as it will be dumped. The other option is that I with the next release remove the state_key from being required, this you can also do by opening /admin/models/forms/dynamic_get.xml and change the value of the state_key field that is required to false like this:

<field
	type="text"
	name="state_key"
	label="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_LABEL"
	size="40"
	maxlength="150"
	description="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_DESCRIPTION"
	class="text_area"
	readonly="false"
	disabled="false"
	required="false" <------- change this value
	filter="STRING"
	message="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_MESSAGE"
	hint="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_HINT"
/>

Then you can leave the field blank, but know that with other of the filter options leaving that field blank will also cause unforeseen errors. Like if you look at the Function Var filter option on line 2055 you will see that the state_key is required.

Being able to change the field required based on the filter selection is not that easy at all... so what shall we do, just always force you to add a value making sure that you looked at the compiler and understood the code. I mean if you just took the name state_key and search over the compiler code base you will find it only used seven times, and reading the code around it would quickly reveal to you the implementation. Which is what I hope would happen as I think this will empower you to take JCB beyond the basics.

But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet?

Okay so at some point in the history of Joomla the sub-form field type did not support required fields. It was during this time that that dynamicGet was made. Since then things have been improved, and now sub-forms do support required fields. ![image](https://user-images.githubusercontent.com/5607939/69493066-ce84d200-0eb2-11ea-9028-45f54bf58d5b.png) As you can see I also now get the same error as you do. When we look at the [code in the compiler](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2026) where that state is being used it does not require you to add the `state_key` since it defaults to the `$this->levels` that are dynamicly set in each model. That is why it worked in the past even with the value empty. Now we have two options, one you just add `$this->levels` to be able to save the dynamicGet, and being able to use the access levels filter. But really since it is not used you can add anything as it will be dumped. The other option is that I with the next release remove the `state_key` from being required, this you can also do by opening [/admin/models/forms/dynamic_get.xml](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/models/forms/dynamic_get.xml#L1012) and change the value of the state_key field that is required to false like this: ```xml <field type="text" name="state_key" label="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_LABEL" size="40" maxlength="150" description="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_DESCRIPTION" class="text_area" readonly="false" disabled="false" required="false" <------- change this value filter="STRING" message="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_MESSAGE" hint="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_HINT" /> ``` Then you can leave the field blank, but know that with other of the filter options leaving that field blank will also cause unforeseen errors. Like if you look at the [Function Var filter option on line 2055](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2055) you will see that the state_key is required. Being able to change the field required based on the filter selection is not that easy at all... so what shall we do, just always force you to add a value making sure that you looked at the compiler and understood the code. I mean if you just took the name `state_key` and search over the compiler code base you will find it only used seven times, and reading the code around it would quickly reveal to you the implementation. Which is what I hope would happen as I think this will empower you to take JCB beyond the basics. But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet?
jcodewalker commented 2019-11-24 11:11:51 +00:00 (Migrated from github.com)

But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet?

First of all thanks for your quick reply.

Now I understand, thanks.

As you already used a lot of Note field to explain things inline (which are really very useful), maybe a Note field to explain it would be enough.
I know that Joomla changes very often and when you have to manage different requirements with the same interface a bit of inline info helps a lot. I mean, even just a “Have a look to the compiler file to check what it is required” message with a link to the compiler file would be very useful. You made JCB and for you it’s “natural” to look into that, but for a user who has a deadline to complete the script it’s not so natural, if you know what I mean. Sometimes, at the of the day, I don’t know my name...

Thanks for your explain!

Have a nice sunday!

Il giorno 24/nov/2019, alle ore 11:27, eweyn notifications@github.com ha scritto:

Okay so at some point in the history of Joomla the sub-form field type did not support required fields. It was during this time that that dynamicGet was made. Since then things have been improved, and now sub-forms do support required fields.
https://user-images.githubusercontent.com/5607939/69493066-ce84d200-0eb2-11ea-9028-45f54bf58d5b.png
As you can see I also now get the same error as you do.

When we look at the code in the compiler https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2026 where that state is being used it does not require you to add the state_key since it defaults to the $this->levels that are dynamicly set in each model.

That is why it worked in the past even with the value empty. Now we have two options, one you just add $this->levels to be able to save the dynamicGet, and being able to use the access levels filter. But really since it is not used you can add anything as it will be dumped. The other option is that I with the next release remove the state_key from being required, this you can also do by opening /admin/models/forms/dynamic_get.xml https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/models/forms/dynamic_get.xml#L1012 and change the value of the state_key field that is required to false like this:

<field
type="text"
name="state_key"
label="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_LABEL"
size="40"
maxlength="150"
description="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_DESCRIPTION"
class="text_area"
readonly="false"
disabled="false"
required="false" <------- change this value
filter="STRING"
message="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_MESSAGE"
hint="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_HINT"
/>
Then you can leave the field blank, but know that with other of the filter options leaving that field blank will also cause unforeseen errors. Like if you look at the Function Var filter option on line 2055 https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2055 you will see that the state_key is required.

Being able to change the field required based on the filter selection is not that easy at all... so what shall we do, just always force you to add a value making sure that you looked at the compiler and understood the code. I mean if you just took the name state_key and search over the compiler code base you will find it only used seven times, and reading the code around it would quickly reveal to you the implementation. Which is what I hope would happen as I think this will empower you to take JCB beyond the basics.

But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/vdm-io/Joomla-Component-Builder/issues/494?email_source=notifications&email_token=ALWXFTZOTBUGA3BI5WYSAKDQVJJIBA5CNFSM4JQ6FV6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAIDAQ#issuecomment-557875586, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALWXFTZHE7F6HW26FZ5I6SLQVJJIBANCNFSM4JQ6FV6A.

> But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet? > First of all thanks for your quick reply. Now I understand, thanks. As you already used a lot of Note field to explain things inline (which are really very useful), maybe a Note field to explain it would be enough. I know that Joomla changes very often and when you have to manage different requirements with the same interface a bit of inline info helps a lot. I mean, even just a “Have a look to the compiler file to check what it is required” message with a link to the compiler file would be very useful. You made JCB and for you it’s “natural” to look into that, but for a user who has a deadline to complete the script it’s not so natural, if you know what I mean. Sometimes, at the of the day, I don’t know my name... Thanks for your explain! Have a nice sunday! > Il giorno 24/nov/2019, alle ore 11:27, [[ewe]]yn <notifications@github.com> ha scritto: > > Okay so at some point in the history of Joomla the sub-form field type did not support required fields. It was during this time that that dynamicGet was made. Since then things have been improved, and now sub-forms do support required fields. > <https://user-images.githubusercontent.com/5607939/69493066-ce84d200-0eb2-11ea-9028-45f54bf58d5b.png> > As you can see I also now get the same error as you do. > > When we look at the code in the compiler <https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2026> where that state is being used it does not require you to add the state_key since it defaults to the $this->levels that are dynamicly set in each model. > > That is why it worked in the past even with the value empty. Now we have two options, one you just add $this->levels to be able to save the dynamicGet, and being able to use the access levels filter. But really since it is not used you can add anything as it will be dumped. The other option is that I with the next release remove the state_key from being required, this you can also do by opening /admin/models/forms/dynamic_get.xml <https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/models/forms/dynamic_get.xml#L1012> and change the value of the state_key field that is required to false like this: > > <field > type="text" > name="state_key" > label="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_LABEL" > size="40" > maxlength="150" > description="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_DESCRIPTION" > class="text_area" > readonly="false" > disabled="false" > required="false" <------- change this value > filter="STRING" > message="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_MESSAGE" > hint="COM_COMPONENTBUILDER_DYNAMIC_GET_STATE_KEY_HINT" > /> > Then you can leave the field blank, but know that with other of the filter options leaving that field blank will also cause unforeseen errors. Like if you look at the Function Var filter option on line 2055 <https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/e_Interpretation.php#L2055> you will see that the state_key is required. > > Being able to change the field required based on the filter selection is not that easy at all... so what shall we do, just always force you to add a value making sure that you looked at the compiler and understood the code. I mean if you just took the name state_key and search over the compiler code base you will find it only used seven times, and reading the code around it would quickly reveal to you the implementation. Which is what I hope would happen as I think this will empower you to take JCB beyond the basics. > > But how all this happened, welcome to Joomla! What do you think should I make the field not required or just update the dynamicGet? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/vdm-io/Joomla-Component-Builder/issues/494?email_source=notifications&email_token=ALWXFTZOTBUGA3BI5WYSAKDQVJJIBA5CNFSM4JQ6FV6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAIDAQ#issuecomment-557875586>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALWXFTZHE7F6HW26FZ5I6SLQVJJIBANCNFSM4JQ6FV6A>. >
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: joomla/Component-Builder#494
No description provided.