Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
techman83 opened this issue May 21, 2016 · 5 comments
Open

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

techman83 opened this issue May 21, 2016 · 5 comments

Comments

@techman83
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Member Author

@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
Copy link
Collaborator

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
Copy link
Collaborator

janbrohl commented May 26, 2016

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 1e6adb3

@janbrohl
Copy link
Collaborator

janbrohl commented May 31, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants