Syd, and all, thanks for your further comments! Some comments below, and a
new mock-up attached.
On Thu, Apr 27, 2017 at 5:22 PM, Syd Bauman
Good idea. I'm keen on making it as accessible as possible. In addition, I plan on creating a search box at the top that would allow the user to filter the module and elements. So typing "pers" would considerably reduce the lists to only show those modules containing elements whose tag name start with "pers".
Oh. I like that. (And someday we might want to be able to search for "model.biblLike" or "att.datable" and see only those elements that are members of that class.)
Would be nice to have a "collapse this module right out of the main portion of the interface, 'cause I know I don't want it" capability, too.
I had a good exchange with Lou about the prototype and that made me think that it may be a good idea not to have modules as the primary grouping factor. The attached mock-up shows a possible "unified view" that would list every "object" that has an @ident (elements, classes, datatypes). The list can be filtered by object type, or by searching for an object's @ident. Other buttons (not yet in the mock-up) would allow to sort alphabetically or by module. This approach would make it easy to cherry-pick and would free the user from thinking in terms of modules. Module-level operations will still be possible, e.g. (ex|in)clude a module in full, but somewhat secondary. Any thoughts on this approach?
I have to admit I don't understand *why* Javascript can talk to OxGarage but couldn't talk to the server where I store a snippet of ODD for my main ODD to read. But no matter. As long as there's a clear error message, I don't see a problem. For an example, see [2].
It's because of security issues, since JavaScript is someone else's code that you just got from the internet that just runs on your computer without you even knowing. Someone else may speak more precisely to the reason, but in practice it means that resources from the same domain can be accessed no problem, but resources from other domains cannot be accessed unless their provider made them explicitly accessible. See CORS: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing The other issue I foresee has to do with HTTP v HTTPS protocols. If we put Roma JS on HTTPS (and we should), it will only be able to retrieve other secure resources over HTTPS, nada from HTTP. There are ways to work around this and we'll address them as they emerge. Raff
