d98054c103
addition to the existing 'pyang' checker. Added modal overlay displays showing the yang check results every place the yin/yang symbol is shown (red or green) to indicate the presencee and result of yang checks. Added a Yang Validation: line in the document meta-information section on the document's page in the datatracker. Added the result of the xym extaction to the yang check results, to make extration failures visible. Added the version of the used xym, pyang, and yanglint commands to the check results. Added an action to move successfully extracted and validated modules to the module library directories immediately on submission. Added the xym and pyang repositories as svn:external components, rather than listing them in requirements.txt, as there has been delays of many months between essential features in the repositories, and an actual release. We may get occasional buildbot failures if broken code is pulled in from the repository, but better that than the functionality failure of severely outdated componets. Added a new management command to re-run yang validation for active drafts for which yang modules were found at submission time, in order to pick up imported models which may have arrived in the model libraries after the draft's submission. Run daily from bin/daily. Added a table to hold version information for external commands. The yang checker output should include the version information of the used checkers, but seems unnecessary to run each command with its --version switch every time we check a module... Added a new management command to collect version information for external commands on demand. To be run daily from bin/daily. Added tests to verify that xym, pyang and yanglint information is available on the submission confirmation page, and updated the yang module contained in the test document to validate under both pyang and yanglint. Updated admin.py and resource.py files as needed. - Legacy-Id: 13630 |
||
|---|---|---|
| bin | ||
| bootstrap | ||
| buildbot/masters/datatracker | ||
| data | ||
| docker | ||
| env | ||
| etc | ||
| form_utils | ||
| hooks | ||
| ietf | ||
| media/photo | ||
| notes | ||
| patch | ||
| redesign | ||
| static | ||
| test | ||
| vzic | ||
| .editorconfig | ||
| .eslintrc.js | ||
| .gitignore | ||
| .pylintrc | ||
| changelog | ||
| changelog.py | ||
| control | ||
| debug.py | ||
| hold-for-merge | ||
| INSTALL | ||
| LICENSE | ||
| LICENSE.django | ||
| PLAN | ||
| README-CDN.rst | ||
| README.datatracker | ||
| ready-for-merge | ||
| release-coverage.json.gz | ||
| requirements.txt | ||
| tzparse.py | ||
The "new" datatracker uses Twitter Bootstrap for the UI. Get familiar with http://getbootstrap.com/getting-started/ and use those UI elements instead of cooking up your own. We have some site-wide customization applied to the bootstrap version we keep in bootstrap/ (from which the minified dist version is built); it modifies some stuff under less/ We also apply some additional custiomizations in static/css/ietf.css; we should eventually move that under bootstrap/less/ if possible. (ietf.css was what Lars used initially for customization with an unmodified bootstrap.) Some ground rules: * Think hard before tweaking the bootstrap CSS, it will make it harder to upgrade to future releases. * No <style> tags in the HTML! Put CSS into the "morecss" block of a template instead. * CSS that is used by multiple templates goes into static/css/ietf.css. * Javascript that is only used on one template goes into the "js" block of that template. * Javascript that is used by multiple templates goes into static/js/ietf.js. * Every template includes jquery, so write jquery code and not plain Javascript. It's shorter and often faster. * No CSS, HTML styling or Javascript in the python code! * Templates that use jquery or bootstrap plugins include the css file in the "pagehead" block, and the Javascript in the "js" block.