agocorona / MFlow

(Haskell) Web application server with stateful, type safe user interactions and widget combinators
http://mflowdemo.herokuapp.com
Other
100 stars 12 forks source link

Some issues with the tutorial example #32

Closed danse closed 10 years ago

danse commented 10 years ago

Hi there, and congratulations for the amazing work in this framework! I was trying the example on the FP complete article, and i noticed two weird behaviours.

I am using Chrome on Mac

I know that these could be issues in the example, and not in MFlow itself, but in my humble opinion that example is so relevant that it should be here in the repo somewhere as doc. This way you could improve it with time. It is really a good example, it is amazing to just write one Haskell file and get an application running, very different from the experience with other frameworks!

Cheers!

agocorona commented 10 years ago

Hi Danse.

Thanks a lot for your feedback.

Something strange happens. The first problem appears to be related with the second. I´m looking at it. Pehaps it is a bug itroduced in the new releases.

I will also improve the tutorial, that is a bit abandoned. There are more things to add.

2014-05-09 23:08 GMT+02:00 danse notifications@github.com:

Hi there, and congratulations for the amazing work in this framework! I was trying the example on the FP complete articlehttps://www.fpcomplete.com/user/agocorona/MFlow-tutoria, and i noticed two weird behaviours.

  • If i navigate up until the page with the header A mix of applicative and monadic operators can be used to create multiple pageflows within a page, and then i click back to the beginning, the browser back button does not work as expected. I will remain stuck in the first page, even though the location changes
  • if i copy the location ( http://localhost/noscript/()/()/false/()/next/1false/1()/2()/2()/3()/3()/4()/4()on my machine) and paste it in another tab, i find myself one page behind, on checkboxes

I am using Chrome on Mac

I know that these could be issues in the example, and not in MFlow itself, but in my humble opinion that example is so relevant that it should be here in the repo somewhere as doc. This way you could improve it with time. It is really a good example, it is amazing to just write one Haskell file and get an application running, very different from the experience with other frameworks!

Cheers!

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/issues/32 .

Alberto.

agocorona commented 10 years ago

Hi Danse again.

The problem can be solved adding wform to the last page in:

page $ pageFlow "5" ( do
   h3 << "A mix of applicative and monadic operators can be used to create multiple pageflows within a page" 
    ++> b << "here two pageflows in a form are composed with an alternative operator"
    ++>  wlink "hi" << p << "click here"

   wform(pageFlow "colors" (do
             r <- colors <++ br
             p << (show r ++ "selected")  ++> br ++> noWidget)
       <|>
         pageFlow "input" (do
             r <- getString Nothing  <++ br
             p << (show r ++ "selected")  ++> br ++> noWidget)
    <** submitButton "OK" ))

 <|> br ++> wlink () << b << "back to the beginning"

Thanks to you I discovered the cause:

The reason is because in the last versions of MFlow, that handle better the REST paths in presence of alternative options, the link management in <|> and the form management demand that the form tag must be explicit when links and form elements are mixed like in this case.

I did not enforced that by means of types because that would complicate the errors reported by MFlow. I will update the fpcomplete example since the change is backwards compatible. I will also will document this.

danse commented 10 years ago

thanks to you!

agocorona commented 10 years ago

Danse:

Thanks for your appreciation of MFlow.

Really I´m in doubt if it is possible to automatically add a form tag to every monadic statement with form elements with backward compatibility.

I will think and make some tests before doing the second.

In case you read this, What must be improved in MFlow? documentation? examples? ....

2014-05-13 17:37 GMT+02:00, danse notifications@github.com:

Closed #32.


Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/issues/32#event-120617529

Alberto.

agocorona commented 10 years ago

Danse:

Thanks for your appreciation of MFlow.

Really I´m in doubt if it is possible to automatically add a form tag to every monadic statement with form elements with backward compatibility.

I will think and make some tests before doing it.

In case you read this, What must be improved in MFlow? documentation? examples? ....

2014-05-13 17:37 GMT+02:00, danse notifications@github.com:

Closed #32.


Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/issues/32#event-120617529

Alberto.

danse commented 10 years ago

Hi, i did not have time to deepen MFlow as i wished. From my point of view there is one important point which should be present in modern web frameworks: templates should be easily editable from the designers. As far as i could see, MFlow encourages using the "what you see is what you get" editor, but i think that producing some template files somewhere and leaving people free to edit them with their favourite editor is the best way to go for this problem.

Also, more and more the generation of rendered markup on the server side is declining. Several modern frameworks like python Eve or node Sails focus on easily providing the client side with a coherent API blueprint, eventually customisable. Sails also provides a socket.io endpoint for free corresponding to every REST endpoint. This is very powerful and useful and yet allows the front end developers and designers to customise a lot, or allow an architecture where a mobile application could easily be plugged to the same API set, aside with a web app. Another possibility for developers nowadays, is just to install CouchDB and use its REST HTTP API. In one shot, API and persistence.

This is missing in the Haskell scenario now. Snap does not look as powerful and quick as other solutions. These solutions are also somehow a subset of what MFlow provides, because they are agnostic about the business logic.

I am not an expert so it is hard for me to say how much flow enforcement would be needed at an API level. Some basic steps are clear (authenticate before anything else), other ones are harder to determine. Also think that, with reactive programming and socket.io, it will become harder to organise logic in terms of atomic HTTP requests. There will be a continuous flow of messages between server and clients.

Wrapping up, it is very hard to me to have a clear picture of the future of web frameworks. What i think is that:

I hope that this could be somehow useful