adiwg / mdeditor Goto Github PK
View Code? Open in Web Editor NEWWeb application for writing metadata, an ADIwg project
Home Page: https://www.mdeditor.org
License: GNU General Public License v3.0
Web application for writing metadata, an ADIwg project
Home Page: https://www.mdeditor.org
License: GNU General Public License v3.0
Add to CONTRIBUTING.md or create STYLEGUIDE.md and refer to that in the documentation section. Mainly we need to specify the rules concerning documenting components, services, helpers, etc. using modules.
*Record = mdJson, contact, or dictionary
We use YUIDoc for the API documentation. We need a better theme and structure for documenting the API than the default one. Here's a starting point: https://github.com/offirgolan/yuidoc-ember-theme
This will allow us to define tooltips in templates and remove the calls to didInsertElement
. Suggest using the ember-tooltips addon.
I suggest we adopt a Forking with feature branches workflow. I borrowed from various sources, but primarily from here. The rest originated from my own damaged brain:
Distinguishes four types of branches:
master – main branch: only fully stable, working releases
release – branch serving as a testing space before releases
develop – this is the place where all development happens
feature/fix/hotfix-branches – a single branch which can be created by any developer, which is responsible for new features, fixes or reported bugs. Every feature branch name should start with the proper prefix and be named after the corresponding issue with the appropriate label. Branch names should follow the following format: {prefix}-{issue number}-{descriptive-name}
. The {descriptive-name}
doesn't need to match the issue name exactly(keep it short), but I should convey the purpose of the branch.
Examples:
New branches _must_ be created from develop. Branches may be created either by forking, or in the main repo (if you have permissions). Forking is recommended, especially for minor or experimental features. Core feature branches may be created in the main repo to ease collaboration. NOTE: An exception is made for _critical_ hotfix branches - they may be diverged from master, but must be merged into both master and develop.
Branch on which the main development happens. New feature/fix branches must be created from develop. Feature branch pull requests must be made against develop. It is recommended to rebase the feature branch to clean/fix/squash unnecessary commits prior to any pull request. Merge conflicts must be resolved by the branch owner (or person issuing pull request).
Branches used for testing before releasing. Release branches are diverged from the develop branch. Release branches constitute a "feature-freeze". Any bugs may be fixed via pull request using fix branches created from the newest release branch. However, changes must be synced back to develop.
The main branch that contains only fully stable, already released iterations of project. Accepts merges from the latest release branch only. Every merge to master must be properly tagged.
Branches must include tests for new functionality and pass(or update) existing tests before Pull Requests will be accepted.
Branches merged into master or develop will be deleted from the main repository. An exception is made to maintain branches for the last version of major releases so that bug fixes may be applied. "Stale" branches will be reviewed after minor releases and deleted if no longer relevant.
GitHub is used for issue tracking. Accepted "bug" or "enhancement" issues must be assigned an appropriate milestone and tag[fix|hotfix|feature
]. Semantic versioning is used for Milestones and corresponding Release Tags.
Issues should be closed by a feature branch via a commit message or pull request.
The goal is to generate changelogs from closed issues related to a milestone.
See this post from chris.beams.io. Summarized below:
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
ember-power-select-with-create might be a better long-term solution. ember-power-select is well supported and this just adds the create option. ember-power-select comes with a Bootstrap theme.
Though I would start a conversation about how to handle deleting contacts...
I see a check box on the contact tab operating similar to a 'show hidden' switch. This would flip from a 'show all' to 'show for resource'.
Resource contacts can NOT be deleted, only removed.
Contacts can be deleted from 'show all' but a search needs to be preformed before deleting. But search what? The open resource? All loaded resources?
We will definitely need a method of handling orphaned responsibleParties. Loading the contact block when saving the record might cover most cases. When loading the resource missing contacts could be restored. For this to work we would need to load the mdJson contact block on saving, but also on switching between resources.
All this same-same for dictionaries.
adiwg/mdCodes will be used in various places in the editor, mostly for input lists. The required codelist(s) should be pre-loaded and made available as a service.
List of ideas for record profiles:
Should we add a profile route with descriptions of use?
We'll need to implement some sort of ScrollSpy-like functionality for the section menus. See screenshot below for example.
There is ember-strap which we can probably steal from - if it still works (code).
However, we might want to roll our own component if the routing's going to be a pain.
UI Mockup:
Add in app/pods/{record type}
Note: Requires feature 32
Hi,
I have installed mdEditor (App Version: 0.0.0+2c2ea582) on Ubuntu 16-04. The install seemed to succeed, however when accessing the application, no metadata fields are visible (see screen cap). A warning message is presented in the console, but it does not seem to be related:
vendor.js:17266DEPRECATION: ember-getowner-polyfill is now a true polyfill. Use Ember.getOwner directly instead of importing from ember-getowner-polyfill [deprecation id: ember-getowner-polyfill.import]
at logDeprecationStackTrace (http://localhost:4200/assets/vendor.js:17248:19)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:17358:7)
at raiseOnDeprecation (http://localhost:4200/assets/vendor.js:17278:12)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:17358:7)
at invoke (http://localhost:4200/assets/vendor.js:17374:7)
at deprecate (http://localhost:4200/assets/vendor.js:17342:32)
at Object.deprecate (http://localhost:4200/assets/vendor.js:30207:37)
at Module.callback (http://localhost:4200/assets/vendor.js:159591:21)
at Module.exports (http://localhost:4200/assets/vendor.js:140:32)
I am having the same experience with a local install on Mac OS X 10.11.6
Have you seen similar behavior? Thoughts on possible causes or troubleshooting approaches?
it all looks like ember framework stuff... Which branch should I be looking at?
The "Add Keywords" button actually adds a new thesaurus. This may be confusing to some users. Recommend renaming to "New Thesaurus" or "Add Thesaurus".
Moved to #83
This will make it easy to deploy the demo to GitHub pages @ http://www.adiwg.org/mdEditor.
Note that we must use the hash locationType when deploying to GitHub pages, see the docs.
/pods/components/input
The contacts model & components need to be updated to be compatible with mdJSON 2.0.
isOrganization
property determines the type of contact.name
have changed, see mdToolspositionName
will only be valid for individual contacts.Address
is now an arrayphoneBook
changed to phone
hoursOfService
was added as an array of character strings.contactType
was added as a user defined contact type (might want to have this as an editable select).electronicMailAddress
is an array of strings. It was moved to the base of 'contact' from 'address'.contactInstructions
addedRefer to adiwg/mdJson-schemas/issues/48.
Possibly add entry of point, line, or poly to contacts to represent the location of a contact (person or org).
This is the method I wrote to clean the JSON. Am I missing anything? It's set to retain the empty arrays at the root (configurable). Blows away everything else, including empty objects and arrays, null, undefined, empty strings. Uses isBlank, so it kills strings with only whitespace, too. I considered allowing null, but the schemas only allow it in the GeoJSON - so it shouldn't ever be an issue.
Add md-object-contacts and any sub-components needed to support contacts.
In: pods/components/object/md-contact
Modules:
Do we need to keep any of the "prototyping" branches besides dictionary?
Using JSON API looks like a good approach. Ember supports it. It also is supported by the ember-local-storage addon (plus it would allow for switching to the JSONAPIAdapter if using a server for persistence).
The meta
property could be used to store general mdEditor config data. Re: profiles, one approach would be to store any used profile in meta
, assign ids, and reference the profile by id in the record (similar to how contact[ ]
works in mdJSON). This would avoid storing the profile multiple times, once per record.
We need to decide how to store entities that exist outside of a record, currently contacts and dictionaries. Store them separately in localstorage? Regardless, we'll need a way to reference them within the record store. Since we're trying to keep the mdJSON intact(right?) within localstorage, we'll need to embed them into each record. It might make sense to use the relationships
property in JSON API to make tracking dependency on these "external" entities easier.
http://opengeoportal.org/software/metadata-toolkit/
I think they're also developing using Ruby, targeting ISO19115-1 content, @chrissbarnett is one of the lead developers. They demo'd the online editor yesterday in a telecom that was recorded, the web page hasn't been updated recently. Maybe can save some dev effort on the mdEditor here?
Using funkensturm/ember-local-storage
We'll need a way to support long lists of keywords. It seems the best way would be to have a "tree" representation of the list. Should be implemented initially as in-repo addon. Possible requirements:
Possible inspiration: http://gcmd.arcticlcc.org/
Related addons:
Should we change the license to one that requires open sourcing of distributed contributions? That is, the GPL. See http://choosealicense.com/ for reference.
Add spatial extent component that supports:
Working Demo with this feature: https://jlblcc.github.io/mdEditor
This may be a good candidate for stand-alone add-on.
Available add-ons/libs:
In /pods/components/object
Note: Requires feature 29
Issues we have been having with ember-cli-selectize have prompted us to try another select list addon. We are hoping that the greater access select2 provides to the HTML will allow us to accomplish some of the more complex features we envision.
So far we have tried ...
This would enable rich-text input in properties like abstract
, but still be readable when output as plain text. Another benefit is that rendering in a markdown parser would not mangle non-markdown(ed) text blocks.
https://github.com/NextStepWebs/simplemde-markdown-editor looks like a good candidate. There's a basic addon for ember: ember-simplemde or we could roll our own component.
We'll need to upgrade the ember-json-tree in-repo addon with a few enhancements to support a taxonomy component. This is what I think we'll need:
Ideally, we can hook into the ITIS API for the taxonomic component and allow searches by common, scientific, or TSN. That will be implemented separately from ember-json-tree.
This is a list of tests that need to be created or updated.
*Probably should handle these in the acceptance tests, unless they have actions.
Should we consider adding a production error tracking service? This will probably be more important as we near a release candidate. Some possibilities are:
I suggest we take a look at the following:
https://github.com/emberjs/ember.js/blob/master/STYLEGUIDE.md
https://github.com/softlayer/ember-style-guide
There are some differences, so I would use the official Emberjs guide as the default and merge in the softlayer one (which is more comprehensive).
One big difference is the whitespace. I prefer the Emberjs rule: Use soft tabs set to 2 spaces.
Requires:
Add in app/pods/{record type}/new
note: Requires feature 29
Stringified code is being inserted!??
list all records
create a new record
not a route!
show the summary for the record
edit the record
not a route!
show the summary for the record
not a route!
show the summary for the record
* Not sure we need routes for these. Will each one have a "page" or be handled in modal pop-up? Maybe both? Pop-up for current record, plus a "dashboard-type" layout for batch actions.
** May not need a route if we can squeeze into another layout. Especially since dicts are managed separately.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.