-
Notifications
You must be signed in to change notification settings - Fork 374
Wish List
See the TODO list for tasks that will be implemented. Below is a list of Yesod features that would be nice, but that we can continue to live without. Volunteers are welcome:
-
Solution for integration testing using webkit (phantomjs)
-
Create a wai-handler-direct-fastcgi which uses the direct-fastcgi package instead of the C library. Discussion: https://github.com/snoyberg/wai-handler-fastcgi/commit/ca64674de3934ae8dd9a612487596db0cd049781
-
http-conduit: add multipart form rendering. That’s possibly even a good project for a separate package.
-
screen casts, maybe webinars/virtual meetups.
-
Have client session cookie code not only optional for whole site, but optional per subsite.
-
Proxy subsite. Could be useful for cross-domain Ajax.
-
Complete the WebFramework Benchmarks.
-
integrate Yesod's forms with reform or otherwise improve forms
-
file uploading plugin configurable for different storage methods and providers (like Ruby's carrierwave + fog)
-
reusable wiki sub-site. there are now a few Yesod wiki applications.
-
A Yesod installer script
-
use the numerals package for i18n numbers
-
type-safe parameters- an extension to type-safe urls. so /foo/2?bar is directed to
getFoo :: Int -> String -> RepHtml getFoo id bar = do ...
-
Better deployment. Keter is a good tool, but it could use some improvements across the board, and some feature enhancements too.
-
Admin subsite, providing access to modifying database entries, viewing logs, etc. There are already a few attempts at this kind of thing.
-
Easier client-side deployment. I've been using Fay, and I'm happy with it, but the process could certainly be smoother.
-
OData support in complement to RESTful Content.
There is now per-request caching based on a Typeable
type-tagged key map. This type of keys could be used for typesafe storage in a modular way in more places, without polluting everything with type variables, for example:
- Generalize sessions, instead of a Map Text ByteString, make something akin to
(Typeable key, Serializable a) => Map key a
, the currentlookupSession
andsetSession
session map could then just be stored under one key. This would make it easier to make anaddMessage
that builds a list of messages to be displayed, and also for subsites or widgets to store their session things under their own key. - Flexible general-purpose caching: a bit more complex than per-request cache because of the longer lifetime: use the API for making caches (preferred storage location: foundation type?) with a longer lifetime, for caching things like RSS feeds, updates from remote sites, that only need to be regenerated once in a while. API functions for automatically expiring cache items after a fixed amount of time, or explicitly expiring.
There are a lot of potential tasks here, including plenty of relatively green field coding opportunities (implement a new backend), or even API redesign.
- uuid primary key for Postgres
- projections, or sub-selects, where you only want a portion of your data fields returned. This was discussed on web-devel. The only reasonable implementation given was to stick either a default value or an undefined in the fields you don’t want. I think Groundhog figured out a strategy.
- Datomic?
- By default add gc-monitoring-wai or StatsWeb for monitoring
- Faster deployment with binary diffs, perhaps using bsdiff of courgette.
- A documented technique for zero-downtime (amazon load balancer?)
- An application that integrates with the Yesod development environment to automatically collect compile errors. If someone else has already offered a solution to a similar compile error it will try to match it and offer the solution.
- yesod console- load a ghci session with simple access to your Persistent models, printed out in a convenient (tabular?) format. Maybe we need to wait for improvements to ghci cabal integration.
- a simple pass-through html template (easy)
- a version of the hamlet template package that allows arbitrary haskell code in the templates. (might be easy using haskell-src-extra)
- Make some reusable subsite or route, that takes a directory of images, generates a combined sprite image at compile time and a widget to insert them, something like
^{sprite SpriteR my_image_png}