[Sputnik-list] blueprint

[Yuri Takhteyev]

Thanks for all the feedback and links.

Having thought about those things, I am now leaning towards the
following: I'll leave Sputnik's default look and feel largely as it
is, but will look for ways to make it easier for the downstream
developer to change it, and will be looking at whether blueprint can
help in that.

Now a few specific issues.

1. I'll wrap the navbar template into the MAIN template and also
remove everything but "MAIN" from _templates, putting it into
_more_templates.  Basically to keep the _templates file simple.

2. I think that the right thing to do with the nav bar is to format it
as a two-level (or multi-level) list with _all_ second level items
included (under their parents) and then turn it into a horizontal menu
with CSS.  This way moving the menu to the side and controlling which
items show when, etc. would be easy.  The catch here is: I tried to do
it before and failed, I don't remember why, but for one reason or
another I couldn't get it to look right.  If someone can helps me with
CSS here, I will change Sputnik to default to a single nested list
instead of two lists as it does now.

3. Having read more about blueprint I am tempted to switch to it for
the sake of flatter div structure.  I am thinking that perhaps the way
to go is to use "semantic" ids and non-semantic class names.  I.e.,
<div id="logo" class="column span-12 start">.  How does that sound?

4. I tested Pierre's script for generating blueprint css and it works
quite well.  I have a few suggestions about packaging, though.  Rather
than putting the whole thing into a Sputnik node, I think it would be
better to put most of the logic into a module.  (See my first attempt
at refactoring it attached.)  This way this module could be used in
other contexts, outside Sputnik.  To use it with Sputnik one can then
write a trivial wrapper function and put it into, say,
sputnik.actions.css, so that the actual "_blueprint" page would be
limited to just setting the two variables (number of columns and their
width).  And there of course should be a blueprint_css rock.

To comment on

>  You ca use a standard naming system :
>  #header #header_navbar #header_login
>  So user can use his own skin
>  But, nobody use it !!

Can you explain this?

>  The only down-side of Blueprint.
>  You can't re-order content for SEO.

That's unfortunate, but I think I can live without SEO, as long as
someone downstream who really needs SEO can write their own CSS and
rearrange the divs.  As you said, blueprint is a prototype and in some
sense so is Sputnik.  I mean, if someone ends up using it for some
project where there were some serious money involved, they'll probably
customize the design.


>  Incoming version use some Ruby script.
>  I will convert them to Sputnik.

See above.

>  I'm sorry for my very bad english. But I would help as much I can.

No problem, I understood you.  And help is always appreciated.

But speaking of foreign languages: if someone wants to discuss Sputnik
in Portuguese, Kepler-BR might be an appropriate list for that.

>  Sputnik has a very nice architecture.
>  I would try versium.storage.svn.

I haven't had a chance to test it recently, so it might be a bit out
of date.  It's on my list of things to do in the next few weeks.

>  If I can get folder/page hierarchy, it would replace my Dokuwiki.

You are not the first person to ask about this.  Let's start a new
thread on this topic.  I want to know what exactly this would mean.
Depending on what is needed, it might not be hard to add.


>  Have you some project for :
>  - table/view additional storage (ex: http://couchdb.org/), would be
>  nice for folksonomy.

Not sure what you mean here.  Note that to some extent, versium is to
lua what couchdb is to javascript.  Plus versioning, minus search,
which however I hope to get to.


>  - skin switching, DEFAULT_TEMPLATE_SET ? @Root : templates =
>  "_templates"
>  - local skin / sub site. Page can ask directly parent folder for value
>  (independent from prototype)

You can change default templates in _config.  I agree that switching
them in @Root would be more correct and I've been thinking of moving
to that.  I've hesitated to do that since it seems that editing
_config is easier to understand than editing @Root.

For a subsite, you _can_ change the templates though not the
stylesheets.  The long term plan is that each node will have (actually
already has) a "config" field which will override config values for
this node and any node that inherit from it.  (If we take this to the
logical extreme, then _config node could go away: there will just be
the config field of @Root.)  But this hasn't been tested and I suspect
that it won't actually work.  (I.e., the code is probably 50% there.)
Once this works it would in theory be possible to do a subsite with a
different CSS using prototypes.  Now, if you want to talk about
inheriting from folders, the main issue there for me is just working
out a conceptual model where it is clear to everyone what is inherited
from the Prototype and what is inherited from the parent folder.  Note
that you can have confusing cases.  E.g., let's say I add a
"Brazil/Map" with "@Map" as the prototype.  Note that this now starts
getting confusing: this page should inherit certain things from "@Map"
(like being able to generate SVG) and other things from "Brazil"
(e.g., CSS).  I just don't know how this would work.  But I would be
happy to discuss.

However, if you want to help, I think the best thing to do first would
be to come up with a solid and tweakable default CSS, _then_ worry
about switching skins.  Right now there aren't any skins to switch
between...

>  - composite page / portlet

That would be interesting.

I am also interested in use cases / demos / application ideas.  See
http://sputnik.freewisdom.org/en/Demos for what I've got at the
moment.  I have three more half-finished demos which I hope to put up
soon: a calendar (generates HTML and iCal), a mailing list viewer
(integrates with the wiki) and a map (you configure a map in Lua, it
generates an SVG).

 - yuri

---
http://sputnik.freewisdom.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blueprint_css.lua
Type: text/x-lua
Size: 7183 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080211/54a1686a/blueprint_css.bin