Repository navigation
Add get/set/delete a script source with a script object... and use it. #390
Description
I'm going to "override" @sizzlemctwizzle on this but still keep it in line with the current HEAD deployment to keep this from being hung like it was in #150
e.g. this is part of the needed optimization and can be used with migration routines.
Zren has a commit at Zren@c31a0b0#-P0 that does part of this however his branch may be too murky to merge.
Some misc notes:
- Replace existing routines with actual usage of these functions
- At this time keep the abstraction layer between mongoose and our code e.g. avoid at this time using methods in the models themselves in response to Hotfix for a potential security issue #686.
Activity
Attempt to add the Script Page Header to the Source Code Page
Add get/set/delete a script source with a script object.
[-]Add get/set/delete a script source with a script object. [/-][+]Add get/set/delete a script source with a script object... and use it.[/+]Some misc STYLEGUIDE.md conformance in `.../scriptStorage.js`
Martii commentedon Aug 18, 2015
So in your commit @Zren were you planning on not using a stream buffer when searching (for) the metadata block(s)? Perhaps I'm missing the point today so please humor me as I'm still warming up from a much needed break in real life.
In short we should be ready to do this next but if you would like to show me how you wanted to do this to reassert what you want in a PR I'd be just about ready for that. Please limit it to this issue... and it may take me a bit more to fully comprehend everything you were looking for. One minor exception is as far as placing the getters and setters in the models please leave them abstracted from mongoose, etc... e.g. don't put them in the models as I would prefer not seeing a
Scriptobject created, even if temporary, every time we need to access these methods (getters and setters) ... I've barely looked into hooks with mongoose as well but that could be an option at a middle compromise point.Found target code points are currently
.../scriptStorage.jsand.../user.jsZren commentedon Aug 18, 2015
Probably? It was just easier to deal with as a single string than an array of buffers. I never did any performance testing with either case though. The github library (for github import) returned a string, so I needed a way to parse the metadata with a string and it seemed silly to convert it to a Buffer[] just so I could use the getMeta function.
TBH, the GitHub import feature isn't really needed since the user should just copy paste the code when setting up a new script.
Martii commentedon Aug 18, 2015
It is useful when the metadata block is at the top of a file otherwise it is a relooped routine which seems pretty fast... I had a brief concern with @sizzlemctwizzle in private about a possible pitfall in #285 with the blocks, if not used... it's an extra perk in processing a shorter amount of data with the buffer when all (blocks) are present (at the top)... but I realize both this issue and the other one may negate that perk. The benefits of not colliding on key names is one of the ultimate goals of the other issue besides localization support.
I routinely delete Unit Tests on OUJS and reimport from GH so it would nice to keep that in instead of a paste operation... portable devices aren't as easy to do this as well... also if we run into a sync failure issue down the line we can resync scripts manually until it is a little more solid code between Organizations and single use accounts here on GH. (I had to do this once with a connection failure of S3 where script source wasn't showing up but Script objects were updated)