[Sputnik-list] blueprint

[pierre pracht]

Le 11 févr. 08 à 10:53, Yuri Takhteyev a écrit :

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

Integrating Blueprint very helpful :
   - provide sensible default for typography (vertical rhythm)
   - easy layout (grid based)
   - constant rendering (CSS tweak for different browser)

It would be nice to sketch a use case :
  - install sputnik : integrated installer + stand alone web server  
option (xavante?)
  - first request trigger a custom page with essential configuration  
and common option
  - create some content for testing
  - test some option for changing look and feel
    - color font size border image...
    - navigation structure
    - common web site layout
  - explore configuration option to see if it fit requirement
    - user management
    - content structure
    - different type of document
  - customize look and feel
    - sketch his web site layout (on a grid)
    - rework main template to reflect it
    - dispatch functionality to the appropriate block
    - rework sub template functionality (ex: html code of navigation)
  - deploy
    - make install on production server
    - configure web server
    - import skin build in development environment

Plone is a nice CMS, very powerful.
User can create content and site structure in a snap.
But is default look bother user and is difficult to change.

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

Plone is a perfect example : Main template is a mess. It scare people.
Plone 3.0 introduce the viewlet concept
http://plone.org/documentation/tutorial/customizing-main-template-viewlets/introduction
Basically, you build independent part, who would be injected in main  
template.
You can build a custom skin without touching the main template.
But Plone is the J2EE of CMS, very hard to get in.
However, we can learn a lot of his architecture (and mistakes).

So what should fit in template edited by user :
   - Only body part or the whole page with header ?
   - Only grid layout (#header #content #sidebar) or every visual  
element minus variable content ?

I'm not sure where you want Sputnik to head :
Plone is very power-full but overkill for many use.
PHP CMS have shortcoming.
Wiki base with extension can cover many need.
Sputnik with his architecture and his document orientation can be a  
good base.

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

You mean like this :
http://logicalinteractive.com/about/default.aspx
http://www.cssdrive.com/index.php/menudesigns/item/harbor_curved_two_level_menu/

I'm not sure it can be done only with css AND nested list. I would try  
to do it.

> 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?

Very good ! Typical usage can be :
  - Build prototype with Blueprint class helper :
	<div class="last span-6 column">
  - Tweak template option : color font size ... :
	TEMPLATE_OPTION = [[COLUMN_WIDTH = 40, ... ]]
  - Name custom part with id and recurrent use with class :
	<div id="extra-content" class="last span-6 column">
  - Let Blueprint/Sputnik build aggregate rule :
	SEMANTIC_CLASSES = [["#extra-content"="last span-6 column", ... ]]
	<div id="extra-content">

> 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

A module can be a good fit as you say it could be used in other context.

I would completing it :
  - Custom font-size and vertical rhythm (test done see attachment)
  - Color font border ... option
  - Semantic class aggregation
    - Simple concatenation first
    - Property parsing and masking later

It leads to a question (independent of extraction in a module)
How separate template from its own options ? (not site wide)

>> 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?

I can't bring back a link on this.
Basically, if all site use :
#header #header_navbar #content #footer ...
You can build your own CSS (user css) and tweak every site at your  
taste.
Some web site do it (don't remember which)

At least it means :
Don't bother with semantic class nobody see (use) them.

On the other side : http://microformats.org/ are very use-full.

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

Yes, and they would make a prototype with Blueprint first.

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

I would try luarocks based install first.
SCM based storage is important for me, but there's many to-do in the  
mean time.

For the future, would it be possible to stack storage (like proto in  
page) ?
More on this over.

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

At first, svn (sub) folder hierarchy = page hierarchy = navigation  
automatic generation

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

Functionality of CouchDB table/view storage is orthogonal to versium  
document storage.
See Amazon SimpleDB / S3
Other CMS put everything in SQL Database.
Plone get Object / Document oriented storage hierarchy (completed by  
index)

So if you add an indexed meta-data storage (table/view) ?
  - not tied to SQL schema
  - With swappable back-end : SimpleDB, CouchDB, SQL, lua table + file

Example :
   - Insert a page with extra field for keywords.
   - A filter is set in request pipeline.
     - find keywords field
     - spit field in individual keyword
       - make insert keyword table
  - A filter is set in response pipeline
    - find document id
    - request a keyword view sorted by document id
      - find page keywords
    -  request a keyword view sorted by keyword
      - find related document
   - Page is displayed with his keyword and related document link.

Why this ?
   - scan every documents is too slow.
   - SQL is overkill, lua table + file backup can do it.
     - table / view can be generalized to many back-end.
   - Play well with other format : XML,Json, ...
     - each table / view entry is a independent set of information

More why not generalizing storage in hook in the rendering pipeline ?
An other usage would be to stack storage :
   - install storage for : special page, base template (No need of  
versium)
   - skin storage for customs templates (would use versium in  
development phase)
   - base storage for : user configuration and document
     - alternate storage for test, staging edition. May be mapped to  
SCM branching.

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

Yes for shake of simplicity you need a global skin switch.
But in common use need you got :
   - Custom template for a page (home page)
   - Custom template for a folder/section.

> For a subsite, you _can_ change the templates though not the
> stylesheets.

See above for viewlet, css can be independents documents.
You hook them in rendering pipeline by config option.
They add link in the header slot.

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

It would be very useful.
With this you can add basic option for a special document (template,  
site-map ...).
User can have a simple and convenient interface for editing option.
Site wide option would be more structured.

> Once this works it would in theory be possible to do a subsite with a
> different CSS using prototypes.

Maybe it would be necessary to split option in to :
   - overriding defaults
   - document specific option

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

Yes, it has heart plone/zope badly.
In zope technology it's named "acquisition"
It's very convenient and powerful :
   Objet get comportment based
     - on localization (folder)
     - and type (class and inheritance)

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

Zope 3.0 get this back by requiring explicit acquisition
So object comportment is defined by type.
But class can be define so some property depend of environment (folder  
hierarchy)

Basically you can do it before action code by requesting and  
aggregating meta-data storage along the node path.
For this you just need to build a view of option with absolute path as  
key.
The result can be stored in request table under a key :  
acquisition={ ... }

When it's sensible default, option field can be tagged  to use  
acquisition value (ex: skin, user permission ...)

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

Yes you right, I would complete Blueprint / lua / Sputnik integration  
first.
Then a custom skin.

Local skin switching is a common need.
I fink it's important to get it right and early.
In many framework you have to resort hack to do it.

>> - composite page / portlet
>
> That would be interesting.

The first usage is a custom homepage who present a summary of site  
content.
Ideally a document could be allowed to contain reference to other  
document :
[[/section/page]] would build a link to page default presentation
{{/section/page.summary}} would include content generated by a custom  
action.
{{/section.list&last=5}} would give a formated list of 5 last pages.

So you can do internal request and target node must be aware of  
originated node.
Used in document, you get a composite page.
Used in template you get a portlet.

IMHO, its very important to have a homogenous way to grab resource.
Internally you can use the same path as the resource URL.
ex : request.root.section.page
Plone fall short on this requirement, you can navigate object  
hierarchy. But you didn't get directly a mean-full representation.
Taking it easy by processing internal request as external simply by  
dropping main template, this would cover more frequent use case.

Porlet would be a request on the same node with different action / proto
   - navigation can be a special porlet
Document aggregation would be a request of the rendered content part  
with a tweaked base URL
   - Useful generalization :
     - External request could be turned in a request of main template  
porlet (same node but different action / proto / template)
     - main template would internally request rendered request node  
content part
       - In some case it won't ex: meta-data edition

Content aggregation, with local skinning are the most obvious  
shortcoming in existing frame work.

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

When you want a calendar, you use iCal.app :)
All joke aside, everything is lua is good in sputnik but :
When you edit data in a common format, it's nice to keep it under a  
file with the proper extension.
It would be good to have a mine type system.
When you request a URL, it find a file with html extension.
Sputnik would build a request node with the appropriate proto.
If the file need some additional option, Sputnik can find them in a  
meta-data storage :
   - table/view storage
   - parallel hierarchy with lua file
   - lua file with the same in name in same directory
All those storage using the same interface.
File based storage can be cached in internal table for efficiency
Ideally you could get some conversion tools for meta-date migration /  
edition.

Typical use case :
   - You use your favorite editor directly on file or a copy.
   - You keep presentation option aside of document.

DISCLAIMER :
Often I make reference to Plone.
I didn't see Sputnik as a Plone replacement.
But despite it's stepped learning curve, Plone/Zope (3.0) has a very  
good architecture.
Plone is overkill for many use case, but small frame work have many  
short coming.
My fell is that : you can do 1/2 of Plone functionality with 1/100 of  
his code base, it would cover 90% of common use case.
An example : look at document versioning in Plone ! How many LOC in  
Versium ?
You could say : It isn't the same functionality, but it cover the same  
use case !!

Many of previous idea aren't trivial. But keeping them in mind can pay  
off in long run.
I'm sure this can lead to a versatile framework with a relatively  
small code base.

End of dream to-do for now :
   - blueprint_css.lua
   - a test template based on
   - custom form for editing template option
      - color selector (maybe predefine color class )
         http://thephotofinishes.com/colors3.htm
      - A grid helper
          http://www.sprymedia.co.uk/article/Design
I'm sure that Sputnik+Blueprint would shine at letting designer step in.

I hope you wouldn't bother that I have turned this mail in a diary of  
my thinking :(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: _blueprint_screen.lua
Type: application/octet-stream
Size: 8402 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080211/e91ac831/_blueprint_screen.obj