It shows up that in local edit mode, we still expect that there is a server to talk to - will fix that later maybe.
this is an offshoot of the simplification I was doing to make a Smaller-than-Smallest-Federated-Wiki
the node.js code begs a couple of questions:
initial GET only implementation of node.js server - where rendering i…
…s all done on the client
refactor a pile of nested if's into data that should go into a cfg
oh, thats how this magic works :)
simplify the server code more
put server code for /view (session record?) and page.html rendering n…
…ear each other, as they are related
begin to deal with PUT
midway through adding POST/PUT, but had a different idea
move the static files to where they can be used by the no-server-scri…
http://uwiki.me is live - using no server side scripts, just this .ht…
docco my email
work around for 404 due to page not existing - the server code should…
… really do the same thing, so that the client can use this status
fix .htaccess for non-existant pages - turning on local mode was a ba…
…d idea, as it hid all updates to the server from me - localmode is probly too confusing in its current state :/
I'm not sure about it for several reasons -
yes, I am conflicted, but after 20 years of writing web renderers (eeeek), I've leaned heavily into leveraging client side js.
fair enough, but what do you expect a client js heavy federated wiki UI to work like in that environment?
and as per 3. does it function now, or are there issues.
(leto - I'm asking for specific datums as applied to federated wiki development now, so that we can make a reasoned decision)
I'm biased by the fact that http://uwiki.me implements a read only federated wiki using just apache rewrite rules - so there's an index.html, a style.css, client.js and jquery, and a pile of json files in /data/pages... (I'll do more to simplify our codebase for that and the node.js server)
If you think that this is going to slow down your work, you should feel free to make everything work without server-side rendering and I will be happy to spend the time making the server rendering work.
mmm, one thing - will Handlebars help with the ruby and C based servers?
the thing i may not have emphasised enough is that the pain I had in doing the node.js implementation is because it is not the only backend (and i really want them all to use the same templates/html/css)... (and the static file one, is a really nice example of how far we could go)
even so - everyone seems to think that having html output is important, so there we go - its easier to design and architect with one goal, and at cross purposes - I'll just have to think harder on how
if Handlebars works for the C, ruby, Perl (that i might need to write for other reasons), node.js, .NET, and java, then its a very good fit... HAML seems to be mostly ruby :/
use a jquery UI Dialog to show the json source for a topic, rather th…
…an navigating away - in the process update to jqueryUI 1.8.16, and add all the pre-req's for UI Dialog - including icons that we might not need
update static.html to use new jquery.ui-1.8.16
update static 'server' to use the source popup dialog
My thought is that items of type paragraph and type image should be rendered in html so that search engines can see them. I don't bother with even this when its inconvenient. Also, I'm not wedded to haml and sass since they seem to play a small part.
The client code now does the right thing for a 404. Can we get rid of missing-page and revise the rewrite rules accordingly? Or is this code completely obsolete?
Here is what I've been doing to serve static json only with apache: http://ward.fed.wiki.org/view/serving-static-content