CODEWITHSUNDEEP
haskellyesod
Travis Athougies
Travis Athougies

Reputation: 420

Properly using Persistent in a Yesod subsite?

I'm currently trying to develop a reusable Yesod subsite to deal with user to user messaging. Ideally, the user should be able to download this package from Hackage, provide some hooks in their application, and have a modern, feature-ful messaging system on their Yesod master site.

However, I can't find any examples of a subsite that references the master site's entities. In this case, I'd like to build Persistent models for Messages that might reference a User from the master site.

None of the Yesod subsite tutorials I've found so far deal with using Persistent in a subsite. The yesod-comments package is the closest thing I've found to what I'd like to build, but I'm a bit confused by the approach it takes.

Firstly, it seems to use strings to identify users, rather than the user's id directly, which seems inefficient.

Additionally, it seems to require a strange structure of callbacks (the persistStorage structure) in order to support comment storage, but this seems strange to me. It seems to me that, in Haskell, all the information necessary for figuring out which function to invoke should be done at the class and instance level, but in this case, I'm relying on passing around a bunch of callbacks in order for my code to work properly.

So here's a question to the Yesod community: what's the best way to develop these sorts of generic subsites in Yesod?

I'd really love to use Yesod in my projects, because I love Haskell and all the things that type-safety and static compilation brings (not to mention the speed and scalability benefits), but I can't help but feel pulled towards the dynamic frameworks, like Django and Rails, where not only is there an ecosystem to build and distribute reusable components, but also all the in-library infrastructure to build those components.

Upvotes: 3

Views: 253

Answers (1)

Michael Snoyman
Michael Snoyman

Reputation: 31315

Have a look at how yesod-auth is implemented. Essentially, there's the YesodAuth typeclass that defines the various database operations that need to be provided, but doesn't actually implement them. The user of your subsite can then implement them, and at the same time has the flexibility to modify the database schema however he/she needs.

If in your case schema modification isn't strictly necessary, you can turn down the flexibility and simply require the user to use your data types in the database. If you want to go even further, you can just make the persistent calls yourself in your subsite, likely with something like:

lift $ get404 userId

If you're running into concrete issues with doing something like that, please provide the code and error messages so the problem is clearer.

Upvotes: 5

Related Questions