You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Entry & Feed constructors set the provided $id param directly to $id properties. On get(), $this-id is checked that it's not an empty string and returned.
In the FeedFactory, the $id param is checked in validateRequiredFeedElements() to ensure its not an empty string.
PR #21 implemented URI/IRI validation for id:elements provides RFC 3986 & 3987 compliance/validation for the $id param (Atom id:element).
It would be better to utilize League/Uri::createFromString() when supplying the $id constructor param in factories to help ensure a model object always contains a valid & compliant $id property.
The text was updated successfully, but these errors were encountered:
Note to self:
Implement Uri::createFromString() in the Model directly?
Would this be possible without causing the constructor to do work rather than provide params?
Would this restrict the ability for outside libraries using Atom\Models* to utilize their own RFC 3987 RFC 3986 validation? Or enforce the concept upon them that Atom\Models* are always valid objects upon creation?
Currently, Entry & Feed constructors set the provided
$id
param directly to$id
properties. On get(), $this-id is checked that it's not an empty string and returned.In the
FeedFactory
, the$id
param is checked invalidateRequiredFeedElements()
to ensure its not an empty string.PR #21
implemented URI/IRI validation for id:elements
provides RFC 3986 & 3987 compliance/validation for the $id param (Atom id:element).It would be better to utilize League/Uri::createFromString() when supplying the
$id
constructor param in factories to help ensure a model object always contains a valid & compliant$id
property.The text was updated successfully, but these errors were encountered: