Introduce SelectFields — alternative
#138
Conversation
|
The use case for this PR is ready for review, specifically the |
BurnzZ
force-pushed
the
feat-select-fields-2
branch
from
68d2cc2 to
d09bf66
Compare
| @attrs.define | ||
| class SelectFields: | ||
| """This is used as a dependency in :class:`~.ItemPage` to control which | ||
| fields to populate its returned item class. |
There was a problem hiding this comment.
I wonder if we should rename it, and maybe even move (though not sure), because it's not necessarily about web-poet fields used to populate the item class. It's about the item attributes user wants to get in the output. Page object may not use fields at all.
There was a problem hiding this comment.
Brainstorm: SelectAttributes, SelectAttrs, SelectKeys, AttributeFilter, AttrFilter, KeyFilter, ItemFilter, FilterAttributes, FilterAttrs, FilterKeys, FilterItem.
There was a problem hiding this comment.
I'm inclined to have the word "item" in there for clarity. ItemFilter could mean that the page object supports different types of items and a filter is needed to choose the right one. Somehow, we may want to also include the word "attributes" for better clarity.
How about ItemAttributes?
|
|
||
| * ``SelectFields({"name": True})`` — select one field | ||
| * ``SelectFields({"name": False})`` — unselect one field | ||
| * ``SelectFields({"*": True})`` — select all fields |
There was a problem hiding this comment.
Let's add a note about disabled fields: are they selected this way or not? E.g. "select all fields, including disabled"
There was a problem hiding this comment.
Speaking of disabled fields, are we good to go with this terminology? or continue considering renaming it as well as previously explored in #120 (comment).
|
|
||
| """ | ||
|
|
||
| #: Fields that the page object would use to populate the |
There was a problem hiding this comment.
It's more about attributes of the item which user wants to get.
| """ | ||
|
|
||
| #: Fields that the page object would use to populate the | ||
| #: :meth:`~.Returns.item_cls` it returns. It's a mapping of field names to |
BurnzZ
force-pushed
the
feat-fields-disabled
branch
from
bedf6c5 to
e76d42e
Compare
BurnzZ
force-pushed
the
feat-select-fields-2
branch
from
4e210cd to
0096c8e
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## feat-fields-disabled #138 +/- ##
========================================================
+ Coverage 98.83% 98.88% +0.04%
========================================================
Files 28 28
Lines 1199 1252 +53
========================================================
+ Hits 1185 1238 +53
Misses 14 14
|
| @@ -2,14 +2,17 @@ | |||
| ``web_poet.fields`` is a module with helpers for putting extraction logic | |||
| into separate Page Object methods / properties. | |||
| """ | |||
| from __future__ import annotations | |||
There was a problem hiding this comment.
Added to get around the cyclic imports so we could have this annotation: page: web_poet.ItemPage
Build on top of #120.
This is related to #115 which implements approach 3.
This is an alternative to #118 wherein:
SelectFieldsis now an optional dependency toItemPage.However, this requires the dependencies ofEDIT: solved in fb7b7bdItemPageandWebPageto be keyword-only.item_from_select_fields()utility function has been created to fully handle Scenario A, B, and C.TODO
skip_nonitem_fieldsafterskip_nonitem_fields=Truedoesn't work when the page object is an attrs class #141 is addressedOut of scope for this PR:
on_unknown_fieldinSelectFields