Skip to content

Bylabel exact#1459

Merged
snoyberg merged 14 commits intoyesodweb:masterfrom
pythonissam:bylabel-exact
Dec 27, 2017
Merged

Bylabel exact#1459
snoyberg merged 14 commits intoyesodweb:masterfrom
pythonissam:bylabel-exact

Conversation

@pythonissam
Copy link
Copy Markdown
Contributor

@pythonissam pythonissam commented Dec 2, 2017

Before submitting your PR, check that you've:

After submitting your PR:

  • Update the Changelog.md file with a link to your PR
  • Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

@pythonissam
Copy link
Copy Markdown
Contributor Author

Issue: #1454

I have no confidence if my English is right. Please correct any sentences you feel unconfortable.
Thank you.

@pythonissam
Copy link
Copy Markdown
Contributor Author

Well, fileByLabel also uses T.isInfixOf. Should I create the exact version for this, too?

@snoyberg
Copy link
Copy Markdown
Member

snoyberg commented Dec 3, 2017 via email

nameFromLabel :: T.Text -> RequestBuilder site T.Text
nameFromLabel label = do
--
-- @since 1.5.9
Copy link
Copy Markdown
Member

@MaxGabriel MaxGabriel Dec 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need to give @since annotations for non-exported functions

Edit: unless this is meant to be exported?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. I understand the rule. I'll do so:)


-- |
-- @since 1.5.9
byLabelWithMatch :: (T.Text -> T.Text -> Bool) -- ^ The matching method which is used to find labels (i.e. exact, contains)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this meant to be exported? It seems really useful

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, neither.

-- > byLabel "Nickname" "Snoyberger"
--
-- Therefore, this function is deprecated. Please consider using 'byLabelExact',
-- which performs the exact match over the given word.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should use a GHC DEPRECATED pragma, and recommend byLabelWithMatch Data.Text.contains for the old behavior and byLabelExact for the new behavior

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

recommend byLabelWithMatch Data.Text.contains for the old behavior and byLabelExact for the new behavior

Actually, byLabelWithMatch is the abstraction of the matching methods and byLabel performs the old behavior (contain) as before, unless users will be forced to rewrite their tests to use byLabelContain or whatever. And yes, byLabelExact is for the new behavior.

So,

byLabel -> deprecated
byLabelExact -> recommanded

Is this okay?

I think we should use a GHC DEPRECATED pragma

NiceXD. I even didn't know that. I'll modify the code.

-- > </form>
--
-- Note that this function finds the labels in which contain the given word.
-- It might choice labels unexpectedly or just fail in the circumstances like below:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this more explicit about how the function would fail? Something like the following:

Warning: This function looks for any label that contains a subset of the provided text. If multiple labels contain that subset, this function will throw an error, as in the example below:

Site note since it sounds like you're working on your English skills:

"labels in which contain" should be "labels which contain"

"It might choice labels" should be "It might choose labels"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this more explicit about how the function would fail?

Sure.

And thank you for your advice about my English. It helps me a lot.

@pythonissam
Copy link
Copy Markdown
Contributor Author

@snoyberg Should I create another PR?

@snoyberg
Copy link
Copy Markdown
Member

snoyberg commented Dec 4, 2017

I don't think a new PR is necessary, I'd say just update this one.

@pythonissam
Copy link
Copy Markdown
Contributor Author

@MaxGabriel Following your advices, I updated haddocks. What do you think?

-- > <label>Please submit an image <input type="file" name="f1"> </label>
-- > </form>
--
-- Warning: There exists the same issue of 'byLabel'. Please use 'fileByLabelExact' instead.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would sound better to say "This function has the same issue as 'byLabel'"

@MaxGabriel
Copy link
Copy Markdown
Member

I made one small comment. Otherwise LGTM!

@pythonissam
Copy link
Copy Markdown
Contributor Author

@MaxGabriel Noted with thanks!

@pythonissam
Copy link
Copy Markdown
Contributor Author

@snoyberg @MaxGabriel I guess I've done. Would you review changes?

@MaxGabriel
Copy link
Copy Markdown
Member

@pythonissam what’s the other bug in byLabel?

@pythonissam
Copy link
Copy Markdown
Contributor Author

@MaxGabriel Please consider the following situation

<html>
  <form>
    <label>foo2<input type=text name="bar2"></label>
    <label>foo <input type=text name="bar" ></label>
  </form>
</html>

Then byLabel "foo" "baz" sets baz into bar2, not bar.

The cause is around here:

-- In genericNameFromLabel

case mfor of
  for:[] -> ...

  [] ->
    case filter (/= "") $ mlabel >>= (child >=> C.element "input" >=> attribute "name") of
      [] -> failure $ "No label contained: " <> label
      name:_ -> return name

  _ -> ...

Using isInfixOf, mlabel will be ["foo2","foo"]. The above form doesn't contain any for attributes, so mfor will be an empty list.

Finally, filter (/= "") $ mlabel >>= (child >=> C.element "input" >=> attribute "name") becomes ["bar2", "bar"] and its head is taken.

@pythonissam
Copy link
Copy Markdown
Contributor Author

Same here, the fundamental cause is that we decided to use isInfixOf. So I feel like there's nothing we can do without changing their behaviors.

@pythonissam
Copy link
Copy Markdown
Contributor Author

@MaxGabriel @snoyberg

Hi. What's the status of this? CI looks like it failed.
Is there anything I can do with this?

Copy link
Copy Markdown
Member

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me, I just had a minor comment on the deprecation notices. Thanks!

type HasCallStack = (() :: Constraint)
#endif

{-# DEPRECATED byLabel "This function seems to have multiple bugs. Use byLabelExact instead" #-}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about including a link to this PR in the deprecation notices?

Copy link
Copy Markdown
Contributor Author

@pythonissam pythonissam Dec 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds good

@pythonissam
Copy link
Copy Markdown
Contributor Author

@snoyberg Is this okay?

@snoyberg snoyberg merged commit 3df8260 into yesodweb:master Dec 27, 2017
@snoyberg
Copy link
Copy Markdown
Member

Looks great, thanks!

@MaxGabriel
Copy link
Copy Markdown
Member

Thanks @pyhtonissam!

@pythonissam
Copy link
Copy Markdown
Contributor Author

@snoyberg @MaxGabriel Yay! Thank you, too!

snoyberg added a commit that referenced this pull request Dec 30, 2017
Fix Haddock syntax error and test failures introduced by #1459
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants