search

KSP-CKAN / metadata-webtool

A web frontend for writing and modifying .netkans
https://ksp-ckan.github.io/metadata-webtool/
Other
2 stars 4 forks source link

Design Idea: Static Hosting + Dynamic Client Side Only #6

Open techman83 opened 8 years ago

techman83 commented 8 years ago

Feel free to close, as I've yet to have a look at any of the code. However I'm quite fond of static sites and letting the client do all the heavy lifting. Much less maintenance + hosting is pretty much sticking it in an S3 bucket.

We've got webhooks already, any of the content based off the repos could be updated on demand. Even the site itself could be updated via webhooks (merge to master, triggers deployment).

janbrohl commented 8 years ago

My goal would be to put the form on ksp-ckan.org - no idea what tools are available there if any.

For the current state, static hosting with hardcoded.js being updated on changes to CKAN.schema in CKAN or CKAN-meta looks great.

But currently the only ways to validate .netkan files is to create a pull request on NetKAN (too late then) or to run netkan.exe (propably there is some way to run this in browser but I would rather not).

I want to be sure the output of the form is as valid as checkable so either it needs access to machine running netkan.exe (like being hosted on it) or some way to validate netkan files in the browser has to be created (like making a json-schema for it)

techman83 commented 8 years ago

@janbrohl - we can create a subdomain and point it an S3 bucket like our status page. Depending on what you require, CKAN.schema can be pulled live and you could query the GitHub API for information about CKAN-meta.

Without submitting a full Jenkins job, the majority of what we can test via the output of NetKAN could be captured during the webform. A lot of the issues come from not having commas, having too many commas, wrong schema version etc.

I think we should start simple, getting something submitted with the right schema and valid JSON makes the process way easier for those validating pull requests.

If it passes our metadata check that's going to be really much much better than what we have now. That check is run without running NetKAN.

You could also have the schema version update automatically based on what options are selected.

janbrohl commented 8 years ago

Github-API querying would be simple but that way I cannot get all used info as i am checking for mod name duplicates, too.

Maybe a simple way would be to split https://github.com/KSP-CKAN/metadata-webtool/blob/master/static/hardcoded.js so that each part can be updated seperately via webhook or the buildbot directly when the data changes.

As there is not JSON-Schema for netkan yet there is currently no use in selecting different schemas yet.

janbrohl commented 8 years ago

Project now available on https://ksp-ckan.github.io/metadata-webtool/ which is mapped to branch "gh-pages" and must be updated manually or via some not-yet-written script

Currently based on 1e6adb328a21542530a2660ca86f191fbce7dc12

janbrohl commented 8 years ago

@techman83 some place for a server backend would be needed for creating actual pull requests like @plague006 would like to have (see also #22 for current solution).

Actually having live schema is not as much needed as having an up-to-date CKAN-meta to extract info from.

I personally would like to add a functionality like https://janbrohl.pythonanywhere.com/ckan/ too.

@plague006 also wanted to have a way for users to submit issues without registering which would profit from that, too.