I have a situation where I have to construct compiled splices and feed data into them which depends on the URL variable. I struggle to solve the problem.
So there is simple file name list that needs to be rendered in a table. Simple.
Files belong to a group or category so you can list all files or related to a particular category. I pull data using this function:
getFilesList :: Maybe ByteString -> AppHandler [Document]
getFilesList cat = do
let selection = maybe [] (\c -> ["category" =: T.decodeUtf8 c]) cat
r <- eitherWithDB $ rest =<< find (select selection "files") {project = ["blob" =: 0]}
return $ either (const []) id r
If it gets Nothing it pulls the whole list if it gets Just category it pulls files that belongs to that category. Easy so far.
I call the above function from within a handler so that I can feed an argument into it.
listFiles :: AppHandler [Document]
listFiles = do
cat <- getParam "cat"
let r = maybe Nothing (\c -> if c == "all" then Nothing else Just c) cat
render "files/list-files"
getFilesList r
If I get "all" or Nothing on the URL - I get the full list. Anything other then that - I get a category filtered list.
The URL root looks like this
("/files/:cat", method GET listFiles)
But now I have a problem because the "method" function will only accept Handler App App () signature. My handler returns data to be fed into the splices.
I construct my splices like so:
listFilesS :: Splices (Splice (Handler App App))
listFilesS = "files" ## files
where
files = manyWithSplices runChildren file $ lift listFiles -- Feed data here
file = do
"file-name" ## (pureSplice . textSplice $ at "name")
"file-oid" ## (pureSplice . textSplice $ id)
"file-date" ## (pureSplice . textSplice $ dateFromDoc)
"file-size" ## (pureSplice . textSplice $ fsize)
"file-type" ## (pureSplice . textSplice $ at "type")
"file-auth" ## (pureSplice . textSplice $ const "admin")
"file-link" ## (pureSplice . textSplice $ flink)
"file-category" ## (pureSplice . textSplice $ at "category")
where id = T.pack . show . valueAt "_id"
fsize = T.pack . show . round . (flip (/) 1024) . (at "size")
flink = T.append "/files/" . id
I cannot find a way around it. Probably just missing something stupid.
Any ideas what I am doing wrong?
In any case, my handler function looks incorrect since I render the template first and then pull the data. If I fix the handler then I cant feed the data based on the URL parameter.
Confused.
First of all, if listFiles is just returning [Document], then you don't want to call render "files/list-files". So the first order of business is to eliminate that line entirely. You might wonder why. That brings us to the second point. Your route should look like this:
("/files/:cat", method GET $ render "files/list-files")
Your route is the result of rendering a template. That's pretty much always the case with Heist routes. Sometimes you might want to explicitly call render. Other times you might just use the routes automatically given to you by heistServe.
I can't really comment on listFilesS without seeing more of the code for the Document API, but it looks reasonable. Assuming it works properly, you just have to bind that splice for your application with something like this:
addConfig heist $ mempty { hcCompiledSplices = listFilesS }
Then just use the files tag in your "files/list-files" template.
Related
My Yesod-Application should get it's approot via an Envoirement-Variable. This seems describe exactly this situation. But: When doing so, only links generated by Yesod will consider the approot, but the Route-definitions in the Quasiquoter parseRoutes will stay absolute:
mkYesod "App" [parseRoutes|
/ HomeR GET
|]
So setting APPROOT to "domain.com/path" will not work, since there's no route for "/path" but only for "/".
Is there a way to make the routes relative to the approot?
Update:
I tried to modify cleanPath accordingly too, but Routes to the Home-Route are still wrong…
instance Yesod Browser where
approot = ApprootMaster myApproot
cleanPath site s = do
if corrected == s
then Right $ dropprefix (Data.List.map dropDash s)
else Left $ dropprefix corrected
where
corrected = Data.List.filter (not . Data.Text.null) s
dropDash t
| Data.Text.all (== '-') t = Data.Text.drop 1 t
| otherwise = t
r = Data.Text.drop 1 $ myApproot site
l = Data.Text.length r
dropprefix l
| Data.List.take 1 l == [r] = Data.List.drop 1 l
| otherwise = l
If I set approot to "/foo" it works, except for "#{HomeR}" leading to "/foo/" which redirects to "/foo/foo"…
It's not completely clear what problem you're running into. I think what you're saying is, if you simply set APPROOT, then:
The URLs generated by Yesod will include the /path prefix
But incoming requests with the /path prefix will not be parsed correctly
The usual use case for this kind of prefix is that you have a reverse proxy in front of your app, such as Apache or Nginx, which is delegating only part of the domain to your app. In this case: APPROOT works fine.
I'm not sure what other use case you're trying to address, but in general you can just drop a part of the request path by overriding the cleanPath method. Or you could use a WAI middleware to modify the request itself if you wanted.
I have a simple snaplet, which has its own routing and pretty much independent of the whole application behavior. However, as for most of the application, I want to hide the new simple snaplet under the restricted area, where only logged in users can enter.
For the root snaplet the problem solved by using simple function restricted which accepts a handler and checks if the user logged in, proceeding further with the given handler or redirecting to the login screen.
Here is the whole configuration:
appInit :: SnapletInit App App
appInit = makeSnaplet "myapp" "My Example Application" Nothing $ do
fs <- nestSnaplet "foo" foo fooInit
ss <- nestSnaplet "sess" sess $
initCookieSessionManager "site_key.txt" "sess" (Just 3600)
as <- nestSnaplet "auth" auth $
initJsonFileAuthManager defAuthSettings sess "users.json"
addRoutes [("content", restricted $ render "content"),
("login", login)]
return $ App ss as fs
restricted :: Handler App App () -> Handler App App ()
restricted = requireUser auth (redirect "/login")
fooInit :: SnapletInit b Foo
fooInit = makeSnaplet "foo" "A nested snaplet" Nothing $ do
addRoutes [("info", writeText "Only registered users can have acess to it")]
return Foo
If I enter http://mywebsite/foo/info, I will be able to see the content of the subsnaplet without logging it. It seems to me, that I cannot protect all of the handlers implemented inside of my new Foo without changing that snaplet and modifying its routing. Or am I wrong?
P.S.: There is an option to use weapSite and check the request URL, but since it implies verification based on URL, not on the recourse, (handler in this case) it doesn't seem right to me.
The answer here is to use the wrapSite function. It takes an argument (Handler b v () -> Handler b v ()), which is exactly the type signature of your restricted function.
For each dir.. , it is a Route which takes in a Request and returns a Response created by the Server. I am wondering if the Request and the Response included in each line of the code. Thanks in advance!
simpleHTTP serverConf $ do
decodeBody (defaultBodyPolicy "/tmp/" 4096 4096 4096)
msum [ do
nullDir
seeOther "graph" (toResponse "Redirecting to /graph"),
dir "grid" gridResponse,
dir "graph" graphResponse,
dir "image" graphImageResponse,
dir "timetable-image" $ look "courses" >>= \x -> look "session" >>= timetableImageResponse x,
dir "graph-fb" $ seeOther redirectUrlGraphEmail $ toResponse "",
dir "post-fb" $ seeOther redirectUrlGraphPost $ toResponse "",
dir "test" $ look "code" >>= getEmail,
dir "test-post" $ look "code" >>= postToFacebook,
dir "post" postResponse,
dir "draw" drawResponse,
dir "about" $ aboutResponse aboutContents,
dir "privacy" $ privacyResponse privacyContents,
dir "static" $ serveDirectory DisableBrowsing [] staticDir,
dir "course" $ look "name" >>= retrieveCourse,
dir "all-courses" $ liftIO allCourses,
dir "graphs" $ liftIO queryGraphs,
dir "course-info" $ look "dept" >>= courseInfo,
dir "depts" $ liftIO deptList,
dir "timesearch" searchResponse,
dir "calendar" $ lookCookieValue "selected-lectures" >>= calendarResponse,
dir "get-json-data" $ look "graphName" >>= \graphName -> liftIO $ getGraphJSON graphName,
dir "loading" $ look "size" >>= loadingResponse,
dir "save-json" $ look "jsonData" >>= \jsonStr -> look "nameData" >>= \nameStr -> liftIO $ saveGraphJSON jsonStr nameStr,
notFoundResponse
]
Each line is a handler. Think of a handler as a function which takes a request and returns a response.
graphReponse is a handler which handles the request in a certain way.
dir modifies the handler so that it doesn't get called unless the request url begins a certain way.
There is nothing special about having the word Response in the name of the handlers. graphResponse is just the name of a function - you can use any names for your handler functions.
What you have is a list of handlers, e.g.:
[ handler1,
handler2,
...,
notFoundResponse
]
When a request comes in a check is made to see if the handler1 will handle the request. If not, handler2 is checked and so on. If no handler accepts the request the notFoundHandler is called which will probably generated a 404 page.
That's why the dir ... part is important - it prevents a handler from responding unless the url begins a certain way.
I'm trying to make the chat example from the Yesod book working in the scaffolding site.
I think I've corrected almost all I had to correct, but all of that is completely new to me (it's my first "real" Haskell project) and I'm not very confident in all my modifications; moreover, I'm really stuck at the point 7. Could you comment all the following points if necessary, and helping me for the 7. (in bold some questions/remarks)?
Copy/paste the Chat.hs and Chat/Data.hs in the root of my site,
add import Chat as Import and import Chat.Data as Import to Import.NoFoundation,
add import of IO, Bool, return, Maybe(Nothing), ($) in Data.hs, since the extension NoImplicitPrelude is on Seems very clumsy... Do we have to import all the standard operators on each new file?
in Fundation.hs, add getChat in the App record (after appHttpManager and appLogger)
in Fundation.hs, add YesodChat instance for App: I had to modify the getUserName on the Just uid case (in the original example of Chat, it was just Just uid -> return uid):
Just uid -> do
muser <- runDB $ get uid
case muser of
Nothing -> error "uid not in the DB"
Just user -> return $ userIdent user
This seems very long and nested... Can we do better?
In Fundation.hs, add chatWidget ChatR after the line pc <- widgetToPageContent $ do in the defaultLayout definition.
Now, I have the following warning :
Application.hs:60:36: Warning:
Fields of ‘App’ not initialised: getChat
In the expression: App {..}
I think I have to write something like getChat <- newChan >>=Chat after the appLogger <- newStdoutLoggerSet defaultBufSize >>= makeYesodLogger and appStatic <- ... in the makeFundation definition, but the type doesn't match. I'm a totally lost here, I don't really understand how this function makeFundation works.
You actually got almost the entire way there. I think you just need to change the line to:
getChat <- fmap Chat newChan
Alternatively, if you're not familiar with he fmap function yet, you can use do notation and get:
chan <- newChan
let getChat = Chat chan
I have an acid-state backend that complements my snap website. It is running in its own process and my snap web server requires an IP address to connect to it. For debugging and deployment purposes I would like to be able to pass in the IP address as a command line argument when running my compiled snap application. This IP address would be accessible inside the SnapletInit monad where the acid state handler gets called.
How can I extend the command line parameter system in Snap to account for this?
Ideally, I'd like something like.
./app -ip 192.168.0.2 -p 8080 -e prod +RTS -I0 -A4M -qg1
Then apply it like this.
app :: SnapletInit App App
app = makeSnaplet "app" "Snapplication" Nothing $ do
ip <- getConfig "ip"
d <- nestSnaplet "acid" acid $ acidInitRemote ip
return $ App d
I would recommend changing the Acid State snaplet to read it's IP from a config instead of the command line. The configs in Snap are set up so that it'll load whatever you pass as the -e argument on the command line. For example, starting with -e prod will load snaplet/acidstate/prod.conf and starting with no -e or -e devel will load snaplet/acidstate/devel.conf. This helps keep all your environmental settings together instead of allowing any possible combination of command line flags.
Here's an example from one of my snaplets:
initStripe :: SnapletInit b StripeState
initStripe = makeSnaplet "stripe" "Stripe credit card payment" Nothing $ do
config <- getSnapletUserConfig
(stripeState, errors) <- runWriterT $ do
secretKey <- logErr "Must specify Strip secret key" $ C.lookup config "secret_key"
publicKey <- logErr "Must specify Strip public key" $ C.lookup config "public_key"
clientId <- logErr "Must specify Strip client ID" $ C.lookup config "client_id"
version <- Just . maybe V20110915d OtherVersion <$> liftIO (C.lookup config "version")
let caFilePath = Just "" -- This is unused by Stripe but vestigial in the Haskell library.
return $ StripeState <$> (StripeConfig <$> (SecretKey <$> secretKey) <*> caFilePath <*> version) <*> (PublicKey <$> publicKey) <*> clientId
return $ fromMaybe (error $ intercalate "\n" errors) stripeState
Check out snap-server's Config module. Specifically, extendedCommandLineConfig.
You could use getEnv, lookupEnv or getArgs from System.Environment
Personally, I'd go with the ENV variables approach.