Hi @jlauer , do you have any tips for developing under JSFiddle? I’m having some real issues, for example Chrome won’t seem to search within the Javascript view unless the text you’re looking for is already visible on the screen. For that reason I’m investigating developing under my usual web IDE (PHPStorm).
I’ve tried setting up a local development environment, but I can’t replicate your geturl proxy - mine returns something like a bootloader for the fiddle rather than the actual fiddle yours returns - is there something special you’re doing in the background?
Is there any particular route for submitting pull requests once a fiddle has been forked a-la GitHub?
Thanks for the work you and everyone else have done so far!
I’m not John, and I don’t play him in TV. But I do use JSFiddle (with ChiliPeppr), so here’s my input. In terms of editing files, I never use JSFiddle. I keep all my sources local, edit, copy and paste in to JSFiddle to test. I’m RELIGIOUS about this because I don’t want to even lose something I did just to try it.
Right now if you develop a fiddle you’ll need to ask John to add it to the system. We do have future plans, but they are just that, for now.
Hi Richard. I hear you on the search. It kills me too. That’s a reason to cut/paste to a local editor. My hope is either JSFiddle fixes that or ChiliPeppr eventually has it’s own JSFiddle (which is sort of wip right now).
On the proxy, yes, there are some very special tricks in the background. JSFiddle made some special changes just for ChiliPeppr to make sure they supported it.
For pull requests, this is where I wish I was using Github, but you have to just manually ask right here and it’ll get added.
Can you share what you’re working on so we can all get excited?
Thanks for your responses guys, I’m glad it’s not just me missing something simple!
I’ve been delving into the Eagle Brd widget, hoping to add a dropdown to select which layer to work on - most of my circuits use through hole components so a lot of the traces are on the bottom layer rather than the top. I think I’ve got a decent idea on how to implement it but I got a little stuck when it came to testing!
I think I may have got my local test suite working (somewhat sporadically), although it does (rather cheekily) utilise your proxy John, I hope you don’t mind!
I have my code hosted (currently without any changes) on GitHub here - https://github.com/shaggythesheep/chilipeppr-eagle-brd and you can actually view it on JSFiddle using the link in the README. The only problem is you can’t view it with ‘show/light’ at the end of the URL so it won’t actually work within the UI.
Thinking of Chilipeppr having it’s own JSFiddle, would a script that looked at a GitHub repository and combined the html, js and css files into one work, or is there a bit more going on under the hood?
Ok, that’s awesome. Yeah, you are using JSFiddle’s weak implementation of Github which I abandoned because trying to edit stuff on-the-fly using that technique was awful. It’s completely fine if you use my proxy. That’s what it’s there for. It’s using Google App Engine’s infrastructure, so thank Google. When you embed a widget in ChiliPeppr, you aren’t forced to use that “show/light” URL, rather you just specify whatever URL has the combined HTML/CSS/Javascript. So, you’d have to generate your own version probably since you are using Github.
On your question of looking at Github and combining the content, I don’t think that’s a big deal at all. There’s nothing major going on under the hood there. You could try doing it via Javascript possibly. Remember though that the main goal of using JSFiddle was to nurture forking and encapsulation. The moment you move to Github you start to lose out on new folks understanding how the overall CP app works and you lose on the intimidation factor. You also lose on people having to setup their dev environment, which seems to be where you are struggling.
Yeah, trying to edit it via their GitHub interface didn’t seem like it was going to turn out well!
Now you mention it, JavaScript could definitely do the combining - infact, that’s how my development environment is working: https://gist.github.com/shaggythesheep/7287adc43a21594d59d7
It parses the folder structure in the same way JSFiddle’s interface does and loads any necessary resources before loading in the rest of the module files.
You make a good point about the benefits of not having to setup a dev environment for new folk, but do you think JSFiddle’s GitHub interface (as weak as it is) might be enough to get those people off the ground, whilst using GitHub as the actual repository would help support those of us who have a little more experience with development?
I’m going to have a think tonight to see if I can think of something to make setting up the dev environment easier.
Yeah, I’d really like to have my cake and eat it too with respect to Github and JSFiddle. ChiliPeppr is a really unique web app in that it’s a mashup of independent widgets. I want devs to be able to see the standalone widget in working condition, just like you did with the Eagle BRD widget. I also want the widgets to be easily modified on their own with an iterative process. If a dev had to keep reloading the entire CP interface each time they changed the Javascript for a small widget, which is how web development happens today, then you’ll never end up with a massive project like CP is starting to become. So can I have this brilliant approach while also gaining from a nice repo like Github? The problem really with Github is that it’s a generic repo. If somebody were to come up with a version of Github specific to HTML/CSS/Javascript then I think it could be a game changer.
You’re bang on - and it’s frustrating as both GitHub and JSFiddle are so close in their own rights - if JSFiddle had a git backend it’d be pretty much perfect!
Hi @jlauer , just wanted to drop you a line to let you know that I’ve spent the last couple of evenings putting together a simple server so that working on ChiliPeppr modules might be doable on your local machine.
I am having one (major) issue, in that the loading of the javascript in the backend seems to be rather sparodic, needing several refreshes to get the full module to load - it tends to work perfectly on the first load, then not so well after that - I wonder if you’d be able to take a look and see if I’ve overlooked something.
In order for a folder to be recognised as a ChiliPeppr module, the files inside it must match the expectations of JSFiddle’s GitHub integration - http://doc.jsfiddle.net/use/github_read.html - that is there must be a file called demo.details as well as demo.html, demo.css and demo.js.
Hey Richard, this looks really amazing. I’m a bit unsure how to get it going though. Any chance you could do a video recording of it sort of as a tutorial? Or, want to do a Google Hangout On Air with me and we’ll use that to educate folks on how to use it?
Just as an alternate in case this is too much for folks, I did create a Plunker version of a ChiliPeppr widget the other day instead of using JSFiddle. Plunker has a real find feature since they’re using the Ace editor. It also has intellisense. That solves some of the reason I think Richard made this local editor. Here’s an example of the ChiliPeppr 3D viewer inside Plunker http://plnkr.co/edit/oHnmFv?p=preview
That looks pretty good, definitely handy being able to search properly! Tip for anyone else: make sure you’re in the code editor window before you press Ctrl+F - the in built browser search works the same as JSFiddle.
Do you know how Plunker handles pull requests? Does it show you what’s changed since it was forked?
Did you have any luck getting the sample environment up and running?
Sadly I did not find a way for Plunker to solve the Github problem. It only solved giving a better search. Nobody seems to have solved all the issues.
I did get your sample environment running. It was pretty easy with the Jar, but then I wasn’t sure how to make my own module. Then I wasn’t sure what your approach was for a publish. I’m guessing I’d make my own new Github repo. Attach that new module to it. Then give ChiliPeppr the Github URL as the published URL? Technically Github doesn’t like to be used a hosting server, although ChiliPeppr will support it because it overrides headers and it caches the content (which is why you have to do ?forcerefresh=true in the URL to make CP re-read the cached URLs).
That’s pretty much exactly how I use it - I’ve got the jar set to point to the root folder of my GitHub repos (I keep them all in same parent folder) and then as I add a new repo it, so long as I’ve defined a demo.details file, it’ll show up as a new module.
That’s cool that ChiliPeppr would handle the distribution - I was wondering what GitHubs terms are with regard to being a CDN! I guess it would be manageable to either chilipeppr.load function to accept a GitHub URL and look for the demo.html / css / js files within it?
I don’t suppose you got any of the modules to load the JavaScript files properly? At the moment it’s the only real bug I’m aware of but it’s a bit of a show stopper!
Hi Jon, just to let you know that I have managed to solve the module loading bug, so as far as I can tell this is ready for some testing if you or anyone else (@Kevin_Hauser ) are keen.
That is there’s a demo.details that declares any external resources that are required as well as a name and description; and demo.html, demo.js and demo.css for storing the actual code.
Hi Richard. Very cool! I’ll give it a shot hopefully tomorrow. I bought a 3d printer which arrived yesterday, so I’m “not in a coding mood” right now. Someone’s going to ask so: I got a Rigidbot last weekend on sale. So far assembly has been pretty easy, but only because of the videos. The manual is definitely lacking.