Hi Ricardo, I agree with your point of view on the interface implementation approaches. Indeed, the approaches are not supposed to be mutually exclusive. As you said the first approach is easier and I have started working closer to this approach.
I have already created a small module implementing basic HTML templates in Scheme. Also, I have made an extension to the Cuirass Web API. It responds on the "/status" request and generates a page with a minimalistic HTML table displaying the list of specifications stored in the database. My login on Savannah is "TSholokhova". I am looking forward to making my first commit. I would be glad to receive comments on my code to be sure that I am moving in the right direction. You have mentioned that many users would prefer an interface working without javascript running. Am I right that we would like to have a non-interactive (js-free) interface working and also add some functionality (e. g. search tools for tables) via javascript? Also, I have a couple of questions regarding the frontend part. What frontend framework we would prefer? If I get it right, Hydra uses Bootstrap. For the frontend implementation, we need to include some static css&js files in the interface and serve them somehow. Is it a good idea to serve the static files by Cuirass web server in Scheme? Best regards, Tatiana 2018-05-18 23:35 GMT+03:00 Ricardo Wurmus <rek...@elephly.net>: > > Hi Tatiana, > > > I have started thinking about the type of web interface we want to have > for > > Cuirass in this project. As far as I see, there are two options: > > > > - a web application served by Cuirass web server; > > - a standalone static site which sends queries to the Cuirass web API > > (this is similar to Danny's application); > > > > I suppose that the first option has more benefits since it allows to > choose > > the exact type of information required to be extracted from the database > by > > a specific part of the web interface. What do think regarding these > options? > > You are free to extend the Cuirass web API to suit your application’s > needs. Having a standalone site is a valid way of providing a web > interface, but it doesn’t have to be the only way of accessing the > information. > > Even if you go for the first route, the HTML you serve could talk to the > API. These two options don’t have to be mutually exclusive. > > FWIW, I expect the first approach to be easier because you can use > Scheme for the most part; the pages it serves could be progressively > enhanced with JavaScript, if the client supports it. I’m sure there are > many users who would prefer a system that would work fine even without > running JavaScript in the browser. > > > How will we organize the development process? More precisely, where > > should I place the implemented code in order to provide access to it > > for our team? In my experience, I have used to create the separate > > branch in the git repository. I would like to know which way of doing > > this you would prefer. > > I forgot how we did this for past GSoC, but my preference is to do this > in a separate branch of the Cuirass git repository. Do you have an > account on Savannah yet? Once you do we could give you permissions to > push your work to a separate branch on the repository. > > (You are free to host the code elsewhere as long as we have read > access via git.) > > -- > Ricardo > > >
