Sorry I couldn't make it this week to the workshop. Sounds like a fun project so I figured that I would tinker. I'm sure that other are like this too but I needed to get my hands dirty to figure out the inner workings, thus I set my self a simple example of building out a route that just lists the known pages. So far so good though I did run in to some issues and confusion. Disclaimer: I think in perl so this whole ruby universe still feels foreign, I'm sure that much of my confusion is just not knowing the expected baselines, sorry in advance.
Ok off to the races: Where did I get confused?
So those are the big ones, I'm sure that as I play I'll have more questions, is there a preferred channel for them as they come up? Thanks again ward and team for helping make a happy place for content.
Let me know how I can help.
Im planning on doing just a simple route that lists all the known pag…
…es, baby steps to make sure that I understand where everything is
looks like I should have my own template, though this would likely be…
… betternamed something like system.haml... we=ll see what happens
this pages thing should not have a journal as its generated and shoul…
…d never be cloned, as for story... Im having a hell of a time figuring out this page thing?
there, simples case works... though kinda useless.
ok again simpe and kinda silly but it works... need to work out the l…
…ist syntax and the location keeps getting rewritten?
I cant figure out what the link notation is, so forcing it
remove the old JSON test
Ben -- Welcome to the project. Thanks for jumping in. There is no better way to learn code than by using it. I especially like your commit stream. I felt like I was sitting next to you.
Had I been actually sitting next to you I would of mentioned that Ruby/Sinatra are playing increasingly less significant roles in this project. I like the use case you've chosen. But I'm not comfortable with your strongly server-side implementation approach. Let me summarize it and then suggest an alternative:
The direction we're heading puts the center of control on the client side with one script, client.js, interpreting JSON objects which are the wiki pages (soon to be call articles) which can co-exist with other articles within a single web page. The way to extend this repertoire of functionality is by adding new types of elements to the JSON object.
Here is how it might work. Say your wiki started with welcome-visitors that included a paragraph-like section listing all available pages on your site. This then gets rendered as follows:
The advantage of all this is that instead of creating a new web page you are creating a new type of paragraph (more correctly a new type of story item). This item can participate in drag-and-drop refactoring when you decide that the list should appear on another page.
There is a model for this in the "changes" plugin that lists pages stored in the browser's localStorage. There is a short-hand list of plugins in the client.coffee code. Look for "changes" there.
Fair warning: I'm not above editing JSON to call for a new plugin before there is any interface to create instances of that item type. This lets me feel what it is like to have something before I figure out how to make them.
Thanks Ward for the very detailed reply. I think that it's very
interesting move toward a js only core. This would make it insanely
portable. Is this the intent or is it just a happy accident? Though if
that's the direction, then I wonder why having Sinatra on the backend
at all? It seems like overkill if the intent is to just ship a single
page app, wouldn't that be doable by just a simple flat html file?
Then if I understand thing correctly, with that move then the app
would then use local storage rather then the JSON file scheme that is
currently set up with Sinatra. Then the wiki cross talk would be done
via JSON packed snapshots from local store. All possible via JS, it
just needs to get to the browser.
Does it sound like I have a good understanding on where you want to
see SFW heading? Either way this is a great excuse for me to play with
We have been discussing the distribution of responsibilities between client and server in issue #47. There the question is how much the server participates in retrieving remote pages. So far Sinatra has been helpful in that pretty much anything I would expect of a server is easy to realize with Sinatra and standard gems.