sfu-natlang / lensingwikipedia

Lensing Wikipedia is an interface to visually browse through human history as represented in Wikipedia. This the source code that runs the website:
http://lensingwikipedia.cs.sfu.ca
Other
11 stars 4 forks source link

Remove frontend/ #170

Closed avacariu closed 9 years ago

avacariu commented 9 years ago

Since the site is already running at http://lensingwikipedia.cs.sfu.ca:8080/ and the .js files are identical between the two versions, are we ready to get rid of frontend/ and move the Flask version to port 80?

This would simplify the question of "where do I put my .js files?"

theq629 commented 9 years ago

It looks like some top level documentation still refers to frontend/.

avacariu commented 9 years ago

I removed it from the README. Is there anything else I missed?

theq629 commented 9 years ago

That's all I see for frontend/, but also if domains/wikipediahistory/ is also going away, then README should clarify where the domain code is now and references should be removed from website.md.

theq629 commented 9 years ago

Also, I don't see any mention of how to do the basic configuration, as was in the old frontend readme. It looks there might also be unused or duplicate configuration settings, for example there is a backend URL setting in both config.py and frontendsettings.js.

theq629 commented 9 years ago

Also, domains/README.md should probably clarify what goes in domains/ now, especially since the contents for the two domains differs.

theq629 commented 9 years ago

Also, after going through web/README.md:

avacariu commented 9 years ago

I haven't really touched much of domains/ because I honestly have no clue what goes in there now. All I've done is remove the frontend related stuff, but I'm not sure about the backend. I'd prefer if we just had a Makefile in backend/ that built either of the two domains based on a flag.

I added some more configuration details to the web/README.md and got rid of frontendsettings.js.

In terms of your other points:

run.py doesn't seem to be executable for me

chmod u+x run.py

I don't commit file mode information to git because I've got all my files on an NTFS partition and they're all executable.

I can't tell what the database parts are for

They're for user accounts and anything else we want to put in the database. User accounts are currently disabled because I'm still finishing up the admin interface.

I can't tell if all parts of the readme are required or not (especially the database part and the debugging flag on the server command)

It depends what you want to do. None of them are really required. The website.md file covers all the actual setup instructions.

The debugging flag enables debugging output from Flask (and the app itself if the logging module is used).

I can't tell how I would go about making a local change to any of the wikipediahistory_config_defaults.js settings

That depends on what kind of configuration changes you want to do. You can either stick the changes in a local_config.py file (as described in the updated README), or within the conditional blocks of the index.html template (or any template for that matter). How was this done before?

theq629 commented 9 years ago

---- Andrei Vacariu wrote ----

I haven't really touched much of domains/ because I honestly have no clue what goes in there now. All I've done is remove the frontend related stuff, but I'm not sure about the backend. I'd prefer if we just had a Makefile in backend/ that built either of the two domains based on a flag.

The two main things that I find potentially confusing here are why the wikipediahistory domain only has backend stuff, while avherald has both backend and frontend stuff; and how the code in domains/ relates to other parts (especially how to use it with a frontend). Although I just noticed that the avherald files are also in web, so maybe we just need to remove the old files and maybe rename domains/ to domain-backends/.

I added some more configuration details to the web/README.md and got rid of frontendsettings.js.

In terms of your other points:

run.py doesn't seem to be executable for me

chmod u+x run.py

I don't commit file mode information to git because I've got all my files on an NTFS partition and they're all executable.

I can't tell what the database parts are for

They're for user accounts and anything else we want to put in the database. User accounts are currently disabled because I'm still finishing up the admin interface.

I can't tell if all parts of the readme are required or not (especially the database part and the debugging flag on the server command)

That all sounds good, I'd just like to have it documented somewhere.

It depends what you want to do. None of them are really required. The website.md file covers all the actual setup instructions

Currently the top level readme directs to the documentation in each directory (while website.md is for our personal installation), so the web readme should contain compete instructions. Alternatively if website.md seems good enough as the main instructions, the readmes could be changed to refer to it.

The debugging flag enables debugging output from Flask (and the app itself if the logging module is used).

I can't tell how I would go about making a local change to any of the wikipediahistory_config_defaults.js settings

That depends on what kind of configuration changes you want to do. You can either stick the changes in a local_config.py file (as described in the updated README), or within the conditional blocks of the index.html template (or any template for that matter). How was this done before?

Before the local config makefile could add new javascript files (frontendsettings.js by default) that could alter all the config settings. I'm not seeing yet how I would change most of the config (everything from wikipediahistory_config_defaults.js) in the new system.

For the python config I'd suggest having documentation strongly encourage using local_config.py for everything (including backend url) since otherwise we tend to accidentally commit personal settings.

I also notice there are some other notes from frontend/README (eg explanation of FrontendConfig, explanation of verbose log settings, design notes) that I don't see in the new files. All of that should be kept or deleted in a separate commit so we know what happened to it.

Other then the missing parts of frontend/README none of this necessarily matters for the current merge, just as long as we have complete documention before long.

avacariu commented 9 years ago

I'd still like to fix all of the issues before merging. I'm working on improving the documentation regarding configuration to make it more clear and provide more configuration options.

I'll take a look at the old frontend/README to see what I can move into the new README or maybe I can put design notes into a separate file.

anoopsarkar commented 9 years ago

Is this pull request ready to merge now?

avacariu commented 9 years ago

I think so. I fixed all the issues @theq629 mentioned.