...more recent posts
So I've run into an issue with geneva. It's not a programming problem, it's conceptual. This is sure to be boring, but I'll just write it out in the hopes of making it more clear to myslef.
You build pages in geneva by selecting templates. Templates are basically HTML files. You can either use a pre built template, or use the browser based HTML editor to make your own. The only difference between a geneva template and a regular HTML file is that templates can contain "containers" which hold editable parts of the page. You insert containers into a template by like this: {{container name}}, where "container name" is any name you choose. Then you define your container on another admin page. Containers can be "textareas" (which gives you an editable piece of text), "snippets" (which are like textareas, but specifically for HTML, CSS, or Javascript code,) "blogs", "images", and eventually things like "photo galleries", "sign up forms", and any other type of component I make.
So far so good. One of the powerful things about containers is reusability. Once you define a container you can insert it into any page. So, image you have an image for your site logo. You create a container called, say, "logo", define that container as an image component, and upload your image. Now you can just put {{logo}} into any page you create and this will be rendered as your uploaded logo image. If you then edit the logo container and change the image it will be updated on all pages of the site.
The problem I am having has to do with naming the containers. I want to have a central repository of pre built templates. These templates will of course include containers since this is the whole point of geneva - making pages which are editable by the site admins. But since you choose your own names for containers, this might lead to problems. A template might specify a container called "main" which holds the main content of a page (say a textarea with a bio for an /about-us/ page.) But you might have already used the name "main" for a different type of container. If so, when you choose the prebuilt template with container "main", instead of getting the intended textarea, you might get a blog, or an image gallery, or whatever component you have previously assigned to the "main" container.
The typical solution here is something like name spacing. I could prefix every container name with the template name. So if you choose a template called, say, "minimal two column", and it contains a container "main", that container would actually have the full name something like "minimal two column : main". Now there can't be any collisions between similarly named containers in different templates. Problem solved.
Except no, because although that would be useful in some situations (where you don't want collisions) it defeats another of the powers of containers: reusability. Sometimes you want the same container to work across multiple templates. Take our original logo container as an example. In this case you want the container "logo" to be the same no matter which template a page is using so that future updates to the contents of "logo" (i.e., you upload a new image when your logo changes) update all pages.
So how do I make it so that I can build new templates with containers that can be used by anybody with a geneva web site, without knowing ahead of time whether a particular geneva web site already has a container specified with that name?
I think the solution is in this direction: templates specify empty containers. Like: {{ }}. Then when you choose a template to use you have to name the containers. But I don't like the extra step this involves. I'd like a site builder to just be able to drop in new templates and have them immediately work. I don't think there is a way around this issue.
Maybe (now I'm just thinking out loud here which I guess is the point) templates can specify containers differently. Something like {{{ }}} and inside have not a container name, but the suggested component. So the template would initally have containers like {{{image}}}, or {{{textarea}}} or {{{blog}}}. And when you choose a template for a page, and then view that page for the first time, you see each container with a default version of that component (a default geneva logo for {{{image}}} containers, lorum ipsum text for {{{textarea}}}, etc...). Then you just edit the page as normal (which is super easy and I'm really excited about this part, but that's another story...) and replace the default content with your own.
Hmmm. Would that work?
I've been working on geneva non stop. The delay is because I decided to include a feature that was going to wait for the 2.0 release. It's a visual CSS editor. I'm not the first (or hundreth) person to build one, but it is not an easy thing to do. So it's taking longer than expected. Still, it's taking perhaps less time than I thought it might, so that's good. I don't have controls for every CSS selector I want to include, but I have a good start. Certainly I'm passed the proof of concept stage and as a result I don't anticipate running into any show stopping bugs. Perhaps I'll find that it doesn't work in older versions of IE, but this is only on admin pages and I don't mind excluding those versions of IE from being usable on the admin side.
Still have to make a few basic templates. Then get a fresh copy of the database ready. And then I'll be ready for some outside testing to begin. Not sure if I'll get a full day of work tomorrow, but if so I might be ready.
I am jumping the gun here, but today is my deadline, so I'm just going to do it. I've "launched" a new site: genevawebsites.com.
This is the culmination of many years work. There is still a lot more to do, but at a very basic level it is functional and so I want to start getting feedback as soon as possible.
I have a blog on the new site where I will post about the site as it matures: genevawebsites.com/blog/
And you can use it to build a website of your own by going to: genevawebsites.com/createsite/
There probably isn't enough documentation yet for you to get very far, but you never know. New sites created will initially exist at something.genevawebsites.com where "something" is a name you supply on the /checkitout/ page. You build your site at that URI, and then if someone decides to stick with it they can supply a "real" URI ("whateveryouwant.com") which I can map to your something.genevawebsites.com subdomain.
I'll have a lot more to say in the coming days, but I wanted to give myself a little birthday present by launching at least something today. Have fun.
The image upload function (only from the new [post] page, not from [image upload] which is deprecated) now tries to deal with image orientation. As far as I know this is only an issue with the iPhone (and I think maybe only with older iPhones.) The problem is that when you take a portrait style (as opposed to landscape style) image the iPhone adds some exif data to the image file noting that it is rotated, but it doesn't actually rotate the image. When viewing the image some display programs know to look for the orientation data and rotate the image, but most do not (like, for instance, Apple's own Safari browser - wtf Apple?) So when you upload an image like this it will display as landscape even though it should be rotated 90 degrees. The upload script here now looks for the exif orientation data, and if present it actually rotates the image for you.
I'm only mentioning this so that people will speak up if this screws up and rotates an image that should not be rotated. Thanks.
Fargo is a new browser based outliner that syncs with dropbox. Created by Dave Winer. Looks pretty cool. Very simple but I can see the power.
Introduction on Dave Winer's blog.
I tweaked the post/edit editor so that it preserves line breaks in the source code. Still not perfect, but better. The "feature" where it strips out lots of code you might enter by hand in Source view (classes, inline styles, etc...) still needs some work. I just have to decide how to handle things.
Also, since it's not necessarily clear, the enter key makes a new paragraph, wrapping the content in <p></p> tags and thus creating a double line break (although the size of this break can ultimately be determined through CSS on a page by page basis.) To get a regular single line break ( <br> ) you can use shift + enter.
Bluepen visual CSS editor looks interesting.
Finally made some progress integrating the Ace editor into my software. Unlike the new WYSIWYG editor on [post] and [edit] pages (based on CKEditor), Ace is for editing HTML (and CSS and Javascript.) So this will only be for end users who want to get their hands a little dirty. But my target market will hopefully include a lot of these sorts of people. For others it will be possible to just select templates and never have to edit HTML directly.
This document defines a new request Client Hint header field, "CH", that allows the client to make available hints, both static and dynamic, to origin and intermediate servers about its preference and capabilities. "CH" allows server-side content adaption without imposing additional latency on the client, requiring the use of additional device databases, while allowing cache-friendly deployments.
This is such an obvious thing to do I've always wondered why it wasn't already implemented. At least it's being worked on. The idea here, if you can believe it, is when a URI is requested from a server, the server has very little information about the requesting client, and the information it does get (mainly, the "User-Agent" string), is difficult to convert into anything reliable or helpful. As URIs have transitioned away from being static documents towards more dynamic applications, our client browsers have multiplied along with device screen sizes and screen pixel densities. To serve an acceptable experience to the myriad of device types, we need to know more about the device which initiated the request. This is exactly what Client Hints hopes to accomplish. Good luck!
Image uploads from post and edit pages are now a little more robust and can handle filenames with potentially illegal characters in them.