Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Result model: Enhance storing keyword name #4884

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
pekkaklarck opened this issue Oct 5, 2023 · 2 comments
Closed

Result model: Enhance storing keyword name #4884

pekkaklarck opened this issue Oct 5, 2023 · 2 comments
Assignees
@pekkaklarck
Labels
alpha 1 backwards incompatible deprecation enhancement priority: medium
Milestone
v7.0

Comments

@pekkaklarck
Copy link
Member

pekkaklarck commented Oct 5, 2023 •
edited
Loading

Currently the Keyword object in the result model has these attributes for specifying its name:

  • kwname that contains the actual keyword name like Log. This attribute doesn't follow Python naming conventions. In output.xml the attribute is saved as name.
  • libname that contains the library or resource file name like BuiltIn. Doesn't follow naming conventions either and because it can contain also a resource file name the attribute is badly named in general. In output.xml the attribute is saved as library.
  • name that contains the full name like BuitlIn.Log. This attribute is a read-only property that gets its value from the aforementioned attributes. This is inconsistent with the execution side Keyword object that has name as a normal settable attribute. This information isn't stored to output.xml because it can be constructed based on the above two attributes.
  • sourcename that contains the original source name when using embedded arguments (Improve embedded keyword logging in output.xml #3750). Doesn't fully follow naming conventions.

As explained above, all these attributes have some issues. We are currently cleaning up the result model and the above issues need to be resolved as part of that. One motivation for this cleanup is making sure that the model doesn't contain anything stupid before we add JSON support to it (#4847). Another reason is to make it more consistent with output.xml. After thinking about alternatives, we have decided to do the following:

  • Old kwname is renamed to name This is consistent with the execution side Keyword and also matches the attribute name in output.xml.
  • Old libname is renamed to owner. It will be stored as owner also in output.xml.
  • New full_name is introduced to replace the old name.
  • sourcename is renamed to source_name in the model and in output.xml.
  • kwname, libname and sourcename will be preserved as propertys. They are considered deprecated, but accessing them won't cause a deprecation warning yet in this release.
@pekkaklarck pekkaklarck added this to the v7.0 milestone Oct 5, 2023
This was referenced Oct 5, 2023
Closed
Closed
@pekkaklarck
Copy link
Member Author

Backwards incompatible changes caused by this issue:

  • Keyword.name returns only the keyword name like Log, not the full name like BuiltIn.Log.
  • library attribute in output.xml is changed to owner.
  • sourcename attribute in output.xml is changed to source_name.

Additionally kwname, libname and sourcename attributes are deprecated, but accessing them doesn't cause deprecation warnings yet.

@pekkaklarck pekkaklarck self-assigned this Oct 5, 2023
@pekkaklarck
Copy link
Member Author

The mess with keyword names is even worse than explained in the original description. The executable keywords, called "handlers" internally, have longname that contains the full name i.e. owner.name. Now that we use full_name with result model keywords, it is a good idea to rename longname to full_name. These handlers aren't par of any public API so this change shouldn't cause additional backwards compatibility concerns.

These handlers as well as KeywordDoc objects used by Libdoc also have shortdoc. For overall API consistency I'll rename that to short_doc as well. I don't think it's a good idea to change Libdoc spec files, though.

@pekkaklarck pekkaklarck mentioned this issue Oct 5, 2023
Closed
pekkaklarck added a commit that referenced this issue Oct 5, 2023
@pekkaklarck
Handlers: longname, 'shortdoc' -> full_name, short_doc
a27bff2 
Internally used keyword handler objects as well as objects used by
Libdoc had `longname` and `shortdoc` attributes that don't follow our
naming conventions. With keyword result objects we just introduced
`full_name` for the same purpose as `longname` (#4884), and this
commit renames `longname` to `full_name` also with handlers. At the
same time `shortdoc` is renamed to `short_doc`.
@pekkaklarck pekkaklarck mentioned this issue Nov 8, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pekkaklarck pekkaklarck

Labels
alpha 1 backwards incompatible deprecation enhancement priority: medium
Projects
None yet
Milestone
v7.0
Development

No branches or pull requests
1 participant
@pekkaklarck