feature/#450 added doc for get_entities_by_config_id #443
Conversation
toan-quach
requested review from
FabienLelaquais,
jrobinAV and
trgiangdo
and removed request for
FabienLelaquais
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
| @@ -45,7 +45,10 @@ passing the data node id as parameter: | |||
| # data_node == data_node_retrieved | |||
| ``` | |||
|
|
|||
| The data nodes that are part of a **scenario**, **pipeline** or **task** can be directly accessed as attributes: | |||
| # Get data nodes by config_id | |||
There was a problem hiding this comment.
To be consistent with the other changes, you should remove the underscore.
| # Get data nodes by config_id | ||
|
|
||
| The data nodes that are part of a **scenario**, **pipeline** or **task** can be directly accessed as attributes by | ||
| using its config_id: |
There was a problem hiding this comment.
"using its config_id" -> "using their configuration identifier:"
There was a problem hiding this comment.
I am not sure about replacing config_id with "configuration identifier" is good for the understanding.
On the one hand, it s better English, I agree with that, but on the other hand, config_id is the name of the attribute. So it s easier to understand.
I would personally go for the name of the attribute name (with the appropriate styling like between ` or _ ) for a better understanding.
There was a problem hiding this comment.
I agree with JR here, config_id to me is straight-forward that's (to my understanding) being used in multiple places within the doc :D
| @@ -70,6 +73,24 @@ The data nodes that are part of a **scenario**, **pipeline** or **task** can be | |||
| task.sales_history | |||
| ``` | |||
|
|
|||
| Data nodes can be retrieved by their config_id by calling `taipy.get_entities_by_config_id()^` with their config_id. | |||
There was a problem hiding this comment.
"by their config_id" -> "using their configuration identifier"
| @@ -65,20 +65,39 @@ pipeline == pipeline_retrieved | |||
|
|
|||
| Here the two variables `pipeline` and `pipeline_retrieved` are equal. | |||
|
|
|||
| # Get pipeline by config id | |||
| # Get pipelines by config id | |||
|
|
|||
| A pipeline can also be retrieved from a scenario by accessing the pipeline's config_id of the scenario. | |||
There was a problem hiding this comment.
"config_id" -> "configuration identifier"
There was a problem hiding this comment.
as said above, I still think config_id is better as it's clear and straight to the point :D but if you think otherwise, I'm open to changing it to configuration identifier :D
|
|
||
| # Get tasks by config id | ||
|
|
||
| A task can be retrieved from a scenario or a pipeline, by accessing the task config_id attribute. |
There was a problem hiding this comment.
The provided example does not reflect that doc line.
"accessing the task config_id attribute" means task["config_id"]
There was a problem hiding this comment.
Not really.
"accessing the task config_id attribute" means task.config_id. That's what the code example shows:
scenario.predicting
pipeline.predicting
Here, predicting is the value of the attribute config_id.
Maybe we can add a sentence to make it explicit.
…se-parent-as-property-key feature/Avaiga#443 added warning about reserved keywords
No description provided.