September 2012 - web-devel

Uniform substitution for URLs, templates, messages and other expressions in Shakespearean templates
by Sebastian Fischer 26 Sep '12

26 Sep '12

Hello, when writing my comparison of Hamlet with Heist and HXT (https://gist.github.com/3757918) I noticed that Hamlet and HXT have similar approaches to variable substitution but Hamlet's uses different syntax for substituting URLs, templates, and other expressions. I'd like to understand why. In HXT Haskell expressions can be substituted using the notation <% ... %>. The rendering of substituted expression is type based and specified separately for attribute- and element-positions via type classes `EmbedAsAttribute` and `EmbedAsChild`. In Hamlet Haskell expressions can be substituted using the notation #{...}. The rendering of substituted expressions is type based and specified via the type class `ToMarkup` from the blaze-html package. URLs are substituted using the notation @{...}, other templates using ^{...} and messages for i18n using _{...}. What are the reasons for providing four different syntaxes for variable subsitution if the substitution is type based? For example, different escaping mechanisms (URL escaping for routes, HTML escaping for strings) could already be accomplished with a single syntactical construct based on different type-class instances to generate markup. Best, Sebastian

3 7

Re: [web-devel] [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5
by Alberto G. Corona 24 Sep '12

24 Sep '12

Hi, This is an difficult problem in which the design principles of MFlow can help to creare a solution amazingly easily. http://haskell-web.blogspot.com.es/2012/09/a.html Alberto 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com> > However if in a tab out of sync the user press refresh, the tab will > refresh to the current state. > I took care not to try to synchronize back as a consequence of a page that > is in a forward state in one tab, as a consequence of navigating back in > other tab. However I may have not considered all the edge extreme cases. > > There is a back detection primitive "goingBack<http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…>" > that allow the programmer to control the back behaviour in some special > cases. > > For example if i want to step over a menu and present a default page, But > if when the user go back i want to present the menu, I can detect this > condition and present this menu, that did not appeared in a normal > navigation: > > This code sets and get a default option in the menu, so the menu is not > shown again in the navigation, except in the case that the user press the > back button. Otherwise, the menu would be never accessible. > > However this is very specialized. normally the back button detection is > not necessary. In a persistent flow even this default entry option would be > completely automatic, since the process would restar at the last page > visited. No setting is necessary. > > > menu= do > mop <- getGoStraighTo > back <- goingBack <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…> > case (mop,back) of > (Just goop,False) -> goop > _ -> do > r <- ask <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…> option1 <|> option2 > case r of > op1 -> setGoStraighTo (Just goop1) >> goop1 > op2 -> setGoStraighTo (Just goop2) >> goop2 > > > > > > 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com> > >> Hi Jake, >> right, it depends on the identification of the session: >> >> iAll the tabs share the same state because they share the same cookies. >> so if in one tab the use continue the interaction then the other tabs are >> out of sync. If the user goes to these other tabs and press any widget, the >> application will synchronize back to this page. >> >> >> This happens also if the user is logged in different computers. >> >> Alberto. >> >> 2012/9/18 Jake McArthur <jake.mcarthur(a)gmail.com> >> >>> Actually, I meant users that spawn multiple tabs from a single root >>> session. You mentioned that you have some special support for the back >>> button. What happens if I open a couple new tabs in which I may or may >>> not go forward and backward. Do they all share the same state? >>> Different states (how?)? Partially shared states? >>> >>> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona <agocorona(a)gmail.com> >>> wrote: >>> > Oh, I´m stupid. You mean web pages with multiple tabs.... >>> > >>> > I have not tested it. but each tab can be handled easily by a >>> different >>> > server process.. or it can be handled in a single server process, like >>> in a >>> > menu. For example, this code present different options, and the process >>> > renders different things depending on the response. >>> > >>> > The last option is a link to a different process, while the others( >>> wlinks) >>> > are links that return back to the same process. >>> > The operator <|> is the applicative operator. a breakline is >>> prepended to >>> > each link: >>> > >>> > data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read, >>> > Show) >>> > >>> > mainf= do >>> > r <- ask $ wlink Ints (bold << "increase an Int") >>> > <|> br ++> wlink Strings (bold << "increase a String") >>> > <|> br ++> wlink Actions (bold << "Example of a string >>> > widget with an action") >>> > <|> br ++> wlink Ajax (bold << "Simple AJAX example") >>> > <|> br ++> wlink Opt (bold << "select options") >>> > <++ (br +++ linkShop) -- this is an ordinary XHtml link >>> > >>> > case r of >>> > Ints -> clickn 0 >>> > Strings -> clicks "1" >>> > Actions -> actions 1 >>> > Ajax -> ajaxsample >>> > Opt -> options >>> > mainf >>> > where >>> > linkShop= toHtml $ hotlink "shop" << "shopping" >>> > >>> > . >>> > Alberto >>> > >>> > 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com>: >>> > >>> >> Hi Jake >>> >> >>> >> I don´t know what you mean with multiple tabs. The user management is >>> >> simple, anonymous clients are identified with a cookie. if the user >>> >> is logged (MFlow has widgets for logging-validation) the user is the >>> >> identifier. >>> >> >>> >> The state of a process is associated to the client identifier and to >>> >> the path invoked in the url requested. >>> >> >>> >> I don´t know if this answer your question.... >>> >> >>> >> Alberto >>> >> >>> >> 2012/9/18 Jake McArthur <jake.mcarthur(a)gmail.com>: >>> >>> This sounds really cool. >>> >>> >>> >>> How do you handle users having multiple tabs? >>> >>> >>> >>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona < >>> agocorona(a)gmail.com> >>> >>> wrote: >>> >>>> Hi haskellers and specially the web developers. >>> >>>> >>> >>>> http://hackage.haskell.org/package/MFlow-0.1.5.3 >>> >>>> >>> >>>> MFlow is a is a Web framework with some unique, and I mean unique, >>> >>>> characteristics that I find exciting: >>> >>>> >>> >>>> - It is a Web application server that start and restart on-demand >>> >>>> stateful web server processes (not request.-response) >>> >>>> This means that all the page navigation can be coded in a single >>> >>>> procedure. This increases readability of the programmer code. I woul >>> >>>> call it >>> >>>> a anti-node.js. Buit usual request-response (stateless) server >>> >>>> processes are also allowed >>> >>>> >>> >>>> - When the process is invoqued as result of an URL request, the Web >>> >>>> app server not only restart the process but also recover its >>> execution >>> >>>> state. The enclosing Workflow monad provides the thread state >>> >>>> persistence. There are state timeouts and process timeouts defined >>> by >>> >>>> the programmer. Processes with no persistent state (transient) are >>> >>>> possible. >>> >>>> >>> >>>> -The user interface is made of widgets. They are formlets with >>> added >>> >>>> formatting, attributes, validations, modifiers and callbacks, that >>> >>>> are composable, so the pieces are reusable and return type safe >>> >>>> responses to the calling process. Even the links are part of widgets >>> >>>> and return back type safe inputs at compile time to the calling >>> server >>> >>>> process. Tho glue these components, ordinary applicative combinators >>> >>>> and other extra combinators are used. >>> >>>> >>> >>>> - The widgets and the communication don´t make assumptions about the >>> >>>> architecture, so it can be adapted to non-web environments. This >>> >>>> versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and >>> >>>> Haskell Server Pages. >>> >>>> >>> >>>> -The widget rendering can be converted to ByteStrings automatically >>> >>>> with special combinators. A mix of widgets with different formats >>> can >>> >>>> be combined in the same source file. For example Text.Html and HSP >>> >>>> (Haskell server pages) >>> >>>> >>> >>>> -These widgets can be cached, to avoid widget rendering on every >>> >>>> interaction. >>> >>>> >>> >>>> -To handle the back button, and because the processes are stateful, >>> >>>> they can run backwards until the response match. This is transparent >>> >>>> for the programmer, thanks to the embedded FlowM monad. >>> >>>> >>> >>>> -All the code is in pure Haskell. No deployment, special scripts, >>> >>>> formats etc are necessary. >>> >>>> >>> >>>> -Besides automatic state persistence, TCache provides transactions >>> and >>> >>>> user data persistence, that can be configured for SQL databases. >>> >>>> Default persistence in files permit very rapid prototyping. Just >>> code >>> >>>> and run it with runghc. >>> >>>> >>> >>>> -Has AJAX support >>> >>>> >>> >>>> All of this sounds very complicated, but really it is simple!. Most >>> of >>> >>>> these things are transparent. The resulting code is quite readable >>> and >>> >>>> has very little plumbing! >>> >>>> >>> >>>> There is a non trivial example that some of these functionalities >>> >>>> embedded here that you can run: >>> >>>> >>> >>>> >>> >>>> >>> http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo… >>> >>>> >>> >>>> Take a look and tell me your opinion. I hope that you find it as >>> >>>> exciting as me. >>> >>>> >>> >>>> I´m looking for people to collaborate in the development of MFlow. >>> >>>> >>> >>>> Although still it is experimental, it is being used in at least one >>> >>>> future commercial project. So I have te commitment to continue its >>> >>>> development. There are many examples in the documentation and in the >>> >>>> package. >>> >>>> >>> >>>> Alberto >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Haskell mailing list >>> >>>> Haskell(a)haskell.org >>> >>>> http://www.haskell.org/mailman/listinfo/haskell >>> > >>> > >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > Haskell-Cafe(a)haskell.org >>> > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >>> >> >> > -- Alberto.

1 0

Data.Word8 (word8 library)
by Kazu Yamamoto 24 Sep '12

24 Sep '12

Hello, ByteString is an array of Word8 but it seems to me that people tend to use the Char interface with Data.ByteString.Char8 instead of Word8 interface with Data.ByteString. Since the functions defined in Data.ByteString.Char8 converts Word8 to Char and Char to Word8, it has unnecessary overhead. Yes, the overhead is ignorable in many cases, but I would like to remove it for high performance server. Why do people use Data.ByteString.Char8? I guess that there are two reasons: - There are no standard utility functions for Word8 such as "isUpper" - Numeric literal (e.g 72 for 'H') is not readable To fix these problems, I implemented the Data.Word8 module and uploaded the word8 library to Hackage: http://hackage.haskell.org/packages/archive/word8/0.0.0/doc/html/Data-Word8… If Michael and Bas like this, I would like to modify warp and case-insensitive to use the word8 library. What do people think this? My concern is that character names start with "_". Some people would dislike this convention. But I have not a better idea at this moment. Suggestions are welcome. --Kazu

6 21

ANNOUNCE: MFlow-0.1.5
by Alberto G. Corona 18 Sep '12

18 Sep '12

Hi haskellers and specially the web developers. http://hackage.haskell.org/package/MFlow-0.1.5.3 MFlow is a is a Web framework with some unique, and I mean unique, characteristics that I find exciting: - It is a Web application server that start and restart on-demand stateful web server processes (not request.-response) This means that all the page navigation can be coded in a single procedure. This increases readability of the programmer code. I woul call it a anti-node.js. Buit usual request-response (stateless) server processes are also allowed - When the process is invoqued as result of an URL request, the Web app server not only restart the process but also recover its execution state. The enclosing Workflow monad provides the thread state persistence. There are state timeouts and process timeouts defined by the programmer. Processes with no persistent state (transient) are possible. -The user interface is made of widgets. They are formlets with added formatting, attributes, validations, modifiers and callbacks, that are composable, so the pieces are reusable and return type safe responses to the calling process. Even the links are part of widgets and return back type safe inputs at compile time to the calling server process. Tho glue these components, ordinary applicative combinators and other extra combinators are used. - The widgets and the communication don´t make assumptions about the architecture, so it can be adapted to non-web environments. This versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and Haskell Server Pages. -The widget rendering can be converted to ByteStrings automatically with special combinators. A mix of widgets with different formats can be combined in the same source file. For example Text.Html and HSP (Haskell server pages) -These widgets can be cached, to avoid widget rendering on every interaction. -To handle the back button, and because the processes are stateful, they can run backwards until the response match. This is transparent for the programmer, thanks to the embedded FlowM monad. -All the code is in pure Haskell. No deployment, special scripts, formats etc are necessary. -Besides automatic state persistence, TCache provides transactions and user data persistence, that can be configured for SQL databases. Default persistence in files permit very rapid prototyping. Just code and run it with runghc. -Has AJAX support All of this sounds very complicated, but really it is simple!. Most of these things are transparent. The resulting code is quite readable and has very little plumbing! There is a non trivial example that some of these functionalities embedded here that you can run: http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo… Take a look and tell me your opinion. I hope that you find it as exciting as me. I´m looking for people to collaborate in the development of MFlow. Although still it is experimental, it is being used in at least one future commercial project. So I have te commitment to continue its development. There are many examples in the documentation and in the package. Alberto

1 0

Re: [web-devel] [database-devel] [ANNOUNCE] esqueleto, a type-safe EDSL for SQL queries
by Felipe Almeida Lessa 12 Sep '12

12 Sep '12

[cross-posting to web-devel] On Wed, Sep 12, 2012 at 6:28 AM, Leon Smith <leon.p.smith(a)gmail.com> wrote: > I am curious to know why persistent is a dependency, given that it sounds > like esqueleto focuses on generating raw SQL. > > Is it to get a more consistent interface across multiple database backends? > To handle schemas or migrations? Something else I'm missing entirely? TL;DR: Mainly the schema. Esqueleto could stop using persistent if we wanted but I don't know how many people would like to see this working and it is by no means trivial. Its main use of persistent is actually on the frontend, on the EDSL that you use. Using persistent we get a type-safe representation of the schema for free: entities and their fields. So when you say where_ (p ^. BlogPostTitle ==. val title) that BlogPostTitle is a constructor representing a field of entity BlogPost, which was created by persistent. The fact that p is a BlogPost is type-checked. The fact that title is, e.g., Text is type-checked. If I didn't use persistent, I'd have to ask the user to write this boilerplate code himself. If I didn't use persistent but the user did, it would be probably just a matter of implementing a lot of type class instances with trivial definitions. If neither I not my user used persistent, you'd probably have to implement a lot more (especially for the next point). It's also very convenient to use persistent on the backend. It already has everything you need to serialize and deserialize fields and entities, and a few bits more (such as escaping). This is also about schema, and we could also drop persistent if we gave the user the responsibility of writing a lot of boilerplate. We decided to use persistent as esqueleto's backend also because that's what we use on our company. We don't know of any other alternative that brings what persistent has for us: semi-intelligent migrations, not so much boilerplate due to TH, good support to MySQL via Bryan O'Sullivan's libraries (this bit is persistent-mysql and we developed the library in-house), type-safety on everything it provides (and now much more due to esqueleto), and non-slowness (I've never seen a benchmark between database APIs, but we know that persistent---and esqueleto---has been written with performance in mind). Even if there was an alternative, it would be very wasteful to change all of our codebase *unless* it brought something nice to the table that persistent does not have. Having said all that, it *may* be possible to abstract persistent out of esqueleto and avoid boilerplate for persistent's users by using the ConstraintKinds extension. All constraints that you see on the EDSL's interface could come from type families inside Esqueleto's type class. In order for this abstraction to be useful, we'd also need to abstract persistent away from the SQL backend, which may require a type class with a lot more internal methods but which persistent users will never need to see. This may be a nice idea should there be anyone wanting to use esqueleto without persistent. But, like I said above, you'd still need to define some boilerplate about your entities. I see two kinds of users that may like such approach: - Users that use completely raw interfaces (such as directly using {mysql,postgresql}-simple libraries). They will need to define a lot boilerplate by themselves, including the SQL backend type class. I'd say that these users should instead define a persistent schema, which will also need some boilerplate but a lot less, and you get persistent for free in the process. - Users of HaskellDB that need to issue a couple of raw queries here and there. It would be technically very interesting to use both approaches at the same time. Given that HaskellDB already has constructors for entities and fields, it would be just a matter of somehow teaching esqueleto how to use it (which may be easy but I never thought about it). However, I wonder how many exist on this category. So, while possible to stop using persistent, I'll probably not do anything in this direction unless I see that there is some interest in doing so (and not only for the sake of abstracting things). However, I'd accept a pull request for this in a heartbeat *if* it didn't add any boilerplate for persistent users. I could also accept something that incurs boilerplate overhead for persistent users, but it would not be in a heartbeat =). Cheers! -- Felipe.

1 0

Integrating chuchu and webdriver
by Gabriel Prioli 11 Sep '12

11 Sep '12

Hello! I want to show a simple example I made that integrates chuchu (a Behaviour-Driven Development package) and webdriver (a browser automation package). It is a demonstration of how you can use these two libraries together. Follow the link below to find an article describing the demonstration. * http://gabrielprioli.wordpress.com/2012/09/11/using-a-business-readable-lan… * Any feedback will be appreciated!

1 0

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 10 Sep '12

10 Sep '12

On Mon, Sep 10, 2012 at 1:09 PM, Arthur Clemens <arthurclemens(a)gmail.com>wrote: > > Actually, I bet I know what the problem is: the export list in > Foundation.hs doesn't include the AdminR datatype. Try adding: > > AdminR (..) > > > Yes, now it works. > That's quite a gotcha. > > Arthur > I agree it's a gotcha, but I'm not sure there's anything we can do to avoid the issue. I suppose we could get rid of the export list in Foundation.hs, but that's not really a good practice in general. Best bet is likely to keep wiki documentation up to date. Which based on the Github newsfeeds, it seems you've been doing a very good job of, thank you. :) Michael

1 0

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 10 Sep '12

10 Sep '12

On Sun, Sep 9, 2012 at 5:48 PM, Arthur Clemens <arthurclemens(a)gmail.com>wrote: > You'll need the AdminR constructor: AdminR AdminRootR. > > > It doesn't work in the scaffolded site, whereas it works as expected in a > single file site like > https://github.com/yesodweb/yesod/wiki/Hierarchical-routes-and-breadcrumbs > > I created a new scaffolded site, used add-handler to create > Handler/Admin.hs, and changed the route in config/routes to > > /admin AdminR: > / AdminRootR GET > > yesod devel results in Application.hs:27:1: Not in scope: data > constructor `AdminRootR' > > changing that to > > /admin AdminRootR GET > > runs without errors. > > > Just to confirm: does your `cabal` file state Yesod version 1.0 or 1.1? > If you use > -ddump-splices when compiling, GHC will spit out the generated > code/data types, which should give a good idea of what's going on > under the surface. > > > I can't, it results in > > Import.hs:10:2: lexical error at character 'i' > > Using ghc -cpp -ddump-splices main.hs > > results in Model.hs:13:1: Parse error: naked expression at top level > > Arthur > > Sorry, I should have clarified: you can do something like: cabal configure --ghc-option=-ddump-splices Then `cabal build` will pass in that option. You get the "naked expression" error because TemplateHaskell isn't enabled. Michael

1 1

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 09 Sep '12

09 Sep '12

On Sun, Sep 9, 2012 at 2:15 PM, Arthur Clemens <arthurclemens(a)gmail.com> wrote: > /admin AdminR: > /product/#ProductId AdminProductR GET POST > ... > > > So if I have: > > /admin AdminR: > / AdminRootR GET > /categories AdminCategoriesR GET > > and the handlers are specified as: > > getAdminRootR :: Handler RepHtml > getAdminRootR = do > .. > > getAdminCategoriesR :: Handler RepHtml > getAdminCategoriesR = do > .. > > what more is needed to create links? > Currently I use <a href=@{AdminRootR}> but that results in > > Handler/Admin.hs:14:22: > Not in scope: data constructor `AdminRootR' > > Arthur You'll need the AdminR constructor: AdminR AdminRootR. If you use -ddump-splices when compiling, GHC will spit out the generated code/data types, which should give a good idea of what's going on under the surface. Michael

1 0

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 09 Sep '12

09 Sep '12

On Sun, Sep 9, 2012 at 1:36 PM, Arthur Clemens <arthurclemens(a)gmail.com> wrote: > It would be nice if there was the possibility to give an entire site section > permissions. What I have now very easily creates bugs, exactly what you > don't want in restricted site parts: > > data Permission = Admin | Public > > permissionsRequiredFor :: Route App -> Bool -> [Permission] > permissionsRequiredFor AdminR False = [Admin] > permissionsRequiredFor AdminCategoriesR False = [Admin] > permissionsRequiredFor AdminAddCategoryR False = [Admin] > permissionsRequiredFor (AdminEditCategoryR _) False = [Admin] > permissionsRequiredFor (AdminCategoryR _) False = [Admin] > permissionsRequiredFor AdminEmailsR False = [Admin] > permissionsRequiredFor AdminProductsR False = [Admin] > permissionsRequiredFor (AdminProductR _) False = [Admin] > permissionsRequiredFor AdminAddProductR False = [Admin] > permissionsRequiredFor (AdminEditProductR _) False = [Admin] > permissionsRequiredFor _ _ = [] > > -- > Arthur Starting with Yesod 1.1, hierarchical routes are now available. So you can do something like: /admin AdminR: /product/#ProductId AdminProductR GET POST ... And then permissionsRequiredFor AdminR{} False = [Admin] Michael

1 0