Skip to content

Page list as simple example to get my head around SFW #50

Closed
wants to merge 7 commits into from

2 participants

@notbenh
notbenh commented Oct 16, 2011

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?

  • Where's 'page' built? I kept running in to errors about page['title'] not found before I just gave it a string in pages.haml. The closest example that I could find was put /pages/.../action, I attempted to build a hash in the route but that wasn't it. In reading over [[Concepts]] it sounds like the expectation is that page is some magic that reads the JSON, but what about system gen pages like this one? Is there a clean way to feed the right data to some method to just make it happy, rather then completely side-step things like I did?
  • I'm completely lost on why going to /pages ends up at /view, I'm guessing that it has something to do with that page thing that I never found as all the other pages seem to do that. I'm sure that there's a very good reason but I couldn't find it in the docs nor in code. Is this a case of: it was explained in person and never made it to the docs? I'll gladly help starting those docs with some coaching.
  • Long term is the expectation that config items will be something... well configurable? Currently it looks like paths to data are hard coded? I followed suit though it seems that doing something like conf.pages.map{} would be prefered over what I've done? I know that this is likely cart before horse as the project is still rather young, so I guess this is more of a feature request rather then a point of confusion.

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.

benh~

ben hengst added some commits Oct 16, 2011
ben hengst 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
bf5d8eb
ben hengst looks like I should have my own template, though this would likely be…
… betternamed something like system.haml... we=ll see what happens
3611bc3
ben hengst 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?
c4f2c60
ben hengst there, simples case works... though kinda useless. 9d6a125
ben hengst ok again simpe and kinda silly but it works... need to work out the l…
…ist syntax and the location keeps getting rewritten?
39f575e
ben hengst I cant figure out what the link notation is, so forcing it c36e423
ben hengst remove the old JSON test 33d6a1f
@WardCunningham
Owner

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:

  • Sinatra detects a unique route (url syntax)
  • Ruby code collects data for a response
  • Haml formats this into a new web page

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:

  • Sinatra generates the boiler-plate for the one-page application
  • A div in that page cites your welcome-visitors which is loaded via ajax and rendered client-side
  • While rendering, your "all pages" paragraph is rendered by consulting the plugin directory
  • Your plugin queries the server for a json object listing every page which it then renders as a list

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.

@notbenh
notbenh commented Oct 25, 2011

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
coffeescript.

@notbenh notbenh closed this Oct 25, 2011
@WardCunningham
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.