API improvements

[gregwebs]

Only had a chance to look at the README so far.

I think the API should avoid the use of the 'do' prefix. Instead of 'doGet' just 'get' or 'visit' or 'page' Instead of doPost, 'post' or 'postTo'

Instead of byLabel can it just be 'label' ? Actually, I think the ideal would be to adopt an API similar to: https://github.com/ozataman/shpider And instead of differentiating with byName, byLabel, and byId, id can require a '#', and we can assume name and fall back to label.

[nubis]

Good idea, I'll move more to a shpider naming convention, and use page for requests. (or whatever shpider uses for making requests). There are also some 'under the hood' changes so if you have any reccommendations on that, now's probably the best time :)

Thanks!

----nubis :)

On Thu, Jan 12, 2012 at 9:56 PM, Greg Weber reply@reply.github.com wrote:

Only had a chance to look at the README so far.

I think the API should avoid the use of the 'do' prefix. Instead of 'doGet' just 'get' or 'visit' or 'page' Instead of doPost, 'post' or 'postTo'

Instead of byLabel can it just be 'label' ? Actually, I think the ideal would be to adopt an API similar to: https://github.com/ozataman/shpider And instead of differentiating with byName, byLabel, and byId, id can require a '#', and we can assume name and fall back to label.

---

Reply to this email directly or view it on GitHub: https://github.com/nubis/TestWaiPersistent/issues/1

[gregwebs]

CSS Selectors

Text.XML.HXT.TransversingCSS is awesome!

@snoyberg is interested in that functionality for use on type of xml-conduit

There is an existing Haskell library that uses quasi css selectors https://github.com/Twinside/Webrexp/wiki/Webrexp-csscompat

Testing API

I already commented on some aspects. How about runDB instead of testDB ?

Testing internals

I wish there were some other approach than overriding describe/it It doesn't seem like it is possible with the current hspec API. Is there a way we can change it?

The traditional way would be to stick our monad in every it:

describe "My App" $ do it "does it" yesod $ do

Do you think it is a good idea to declare our monad once:

describe ("My App", yesod) $ do it "does it" $ do

The advantage of this style is the potential composability rather than forcing a monolith. For example we could expose different aspects of this stack

describe ("My App", [wai, persistent]) $ do it "does wai & persistent" $ do

Or is there another way? I can look at the implementation details of the choice we make.

[nubis]

On Wed, Jan 18, 2012 at 9:02 AM, Greg Weber reply@reply.github.com wrote:

CSS Selectors

Text.XML.HXT.TransversingCSS is awesome!

@snoyberg is interested in that functionality for use on type of xml-conduit

There is an existing Haskell library that uses quasi css selectors https://github.com/Twinside/Webrexp/wiki/Webrexp-csscompat

Testing API

I already commented on some aspects. How about runDB instead of testDB ?

Testing internals

I wish there were some other approach than overriding describe/it It doesn't seem like it is possible with the current hspec API. Is there a way we can change it?

The traditional way would be to stick our monad in every it:

 describe "My App" $ do     it "does it" yesod $ do

Do you think it is a good idea to declare our monad once:

 describe ("My App", yesod) $ do     it "does it" $ do

The advantage of this style is the potential composability rather than forcing a monolith. For example we could expose different aspects of this stack

 describe ("My App", [wai, persistent]) $ do     it "does wai & persistent" $ do

Or is there another way? I can look at the implementation details of the choice we make.

Well, I don't know of any case in which either monad would be useful on it's own, unless we broaden the scope of the problem being solved. My main incentive writing this was to have a brain-dead solution for testing stuff the compiler does not help with. That made me take some 'liberty' in the architecture. But now that you mention it, there is a case for testing functions dealing with your "business logic", livining in your models without making requests. There may also be a point for people testing yesod sites that don't use models. I'll take a look at it, I guess it's possible to define the monads to use and have pre-applied 'describe' versions that use either or both of them for convenience.

I came across Webregexp's hackage entry, from their entry I got the impression that it was more focused on scrapping, the API was not clear enough and it had strange dependencies like transformers+mtl and HaXml+HXT. The rest is lisp syndrome, I thought writing my own in 'pure' HXT would be more straightforward. I'm willing to be called on it, since I'm always the first one to challenge writing a new library instead of fixing an existing one. Do you think we should use Webregexp's? Do you know the author or anyone with any particular interest in it?

Btw, all my work on this is now going to my 'yesod' branch, since I'm integrating what I have with the yesod scaffolder to make it more turn key.

cheers ----nubis :)

[gregwebs]

Thanks a lot for adding to the Yesod scaffold. I think that is actually the last remaining 1.0 goal that was never tackled.

I do not have more than passing familiarity with Webregexp. It was focused on being an executable for scraping, but they did create some library interface after I requested it. I mention the library mostly in case you were unaware of it and because you might be able to borrow a little bit of the css expression code. It would be nice if there were a common library for parsing CSS selector expressions that could be shared, but just eventually releasing your HXT CSS selector module as a library would be a good.