scripted as in-app editor

[Phoscur]

My idea is to view processed content/logic on the same site/in the same app (and possibly spanning multiple windows/browsertabs) with the editor, providing the most epic admin backend and dev tool at the same time. Code the game in the game (working on a browsergame).

So I started of with cloning this repo, but I think it would be best to use it encapsulated into a module(?).

I'm still having a little trouble getting started with scripted, what parts(files) of the businesslogic should I address myself to concerning this?

What are your thoughts?

[aclement]

A couple of people have mentioned the desire to do this, I'd love scripted to be used that way. How to include it in the game may depend on the technology you are using for it. Leaving Scripted as a module would be the most straightforward. Does your game have a server side component? What tech are you using for it?

The most important piece will likely be serving up the application files for editing rather than using the local filesystem. We do have the beginnings of a basic filesystem abstraction in there, but:

• I don't believe it isn't totally complete, and certainly not all fs accesses are using it yet
• it isn't externally configurable, via .scripted or via a plugin mechanism

Both of these things are likely to happen when we get some time. Searching the codebase for uses of the node 'fs' module in the server component will be the places that likely need modifying.

[Phoscur]

Currently I only have a simple static connect server. I'm not decided on the packaging yet (webpack?). Probable choices: angular as Framework, twitter bootstrap for visual groundwork.

Is it possible yet to have multiple (more than two) editors on the same site? I would like to start with a simple site navigation bar, which displays up to 4 editors per navigation link. Clicking the link "Config" for example would open editors for specific config files.

Instead of one or two editors one could have a running app component. Refreshing it should not require a pagereload. (-> hot code reloading?)

[Phoscur]

So that component is FileExplorer? Do I have to wrap it or do you think it would make more sense to completely replace it? Is it the only thing that has that dojo dependency?

I probably want to switch out the layoutManager too..

[aclement]

Yes, you can have multiple editors on the same site, but currently there is no coordination. Edits made in one page/editor will not dynamically be reflected in page another accessing the same file (until that page reloads). I want to have them aware of each other but this hasn't bubbled up the priority list yet.

For our current experiments with reloading we are using live reload but that only dynamically replaces css styling/html without restarting, if you change JS it causes a page reload. We'd like to support something where JS could be hot reloaded but I'm not 'up' on the projects currently supporting that.

File Explorer has a dojo dependency that will be gone this week. Whether you want to use it or remove it will depend on what navigation options you want to have. I use our 'open file' dialog much more than I use the fileexplorer/navigator. If your buttons (like the config button) open all the editors you will need, then sounds like you can ditch the explorer. If you want a completely different structure, it does sounds like you don't want our layoutmanager either. You kind of just want to manufacture editor objects and position them as you see fit. The benefit of doing that with Scripted rather than just using a generic editor JS component should be the content assist and better dev experience you get. I want to support this but I'm not sure how consumable Scripted is for this use case just yet. Look at scriptedEditor.makeEditor() - maybe in your front end you just need to call that a few times (4 in your case). I'd be open to making some changes to suit your usecase (i.e. making us more consumable)