[Sputnik-list] blueprint

[Yuri Takhteyev]

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

YUI (which is what Sputnik uses now) also provides constant rendering.
 The big question for me is: is Blueprint layout really easier to
understand than YUI?

>   - install sputnik : integrated installer + stand alone web server
>  option (xavante?)

This is a documentation issue.  There is no reason why Sputnik
couldn't be used with Xavante, I just haven't had the time to explain
how to do that.  But I see the argument for making it easy for the
user to start with Xavante, rather than treating it as an advanced
configuration.

>   - create some content for testing

I'll ask PA if we can use his Wikipedia data.  (He seems to have
converted them to Markdown.)

>   - deploy
>     - make install on production server
>     - configure web server
>     - import skin build in development environment

Note that you can handle deployment by simply zipping up the
"wiki-data" directory and copying it to a different server.

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

Is that simpler?

>  You can build a custom skin without touching the main template.

At what expense?

>  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 am leaning now on a single template that handles everything we need
to "show" a node.  Editing, history, etc. is all going to be more
complicated and decomposed, but the good news is that in many cases
the users might not care about changing them as much.

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

Well, I am using Lua as the inspiration for Sputnik.  I am not very
familiar with Plone, but as I see it, Sputnik to Lua would be somewhat
like Drupal to PHP.  That is, as I understand, Drupal inherits the
best and the worst of PHP.  I similarly see Sputnik inheriting the Lua
esthetics.  Which is to say that I want to keep it small, generic and
extensible, and hopefully appealing to users who want something
hackable.


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

Yes.

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

People say it can be.

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

Not sure what you mean here.

>  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

Sounds good.

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

What do you mean?


>  Don't bother with semantic class nobody see (use) them.

I understand the argument when designing a particular site.  But it's
a little different when making a wiki engine.  Yes, people will see
the classes and IDs - the downstream developers.  My fear is that a
new user will install it, look at the template, and say "what the hell
is this?"  On the other hand, <div id="logo"> is self-documenting.

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

Stack storage?  What do you mean?  Have different pages use different
storage backend?


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

Explain.

>  Functionality of CouchDB table/view storage is orthogonal to versium
>  document storage.

Well, it's a similar idea.  The main differences are:

1. Versium is an API while CouchDB and Amazon SimpleDB are
implementations.   Versium's "simple" storage is like a baby version
of CouchDB.  There is no reason why one can't make a Versium plugin
for CouchDB / S3, since they align quite well conceptually.  Whether
this is worth the effort is a different question.
2. Versium doesn't support search - yet.
3. Versium has the concept of versioning built in.  I don't think
S3/SimpleDB/CouchDB do that, but it wouldn't be hard to simulate.

>  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

We'll it's a matter of writing them.  At this point I don't have the
time to do that myself, so my plan is to focus on maintaining the
"simple" backend.

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

Very interesting, though you are confusing "versium" (the API) with
"versium.storage.simple" (a file-based implementation).  But I see
what you mean.

André, what do you think about this?


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

Well, the first is easy: just set "templates" to your alternative
templates.  The second would be easy if there was a concept of a
"folder".  The closet you can do now is make a prototype for each
section.

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

Sounds too complicated, frankly.

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

Why?  There is a subtle issue, that perhaps you are alluding to, that
there is sometimes a conflict between what a prototype wants to set
for itself vs. what it wants it's children to inherit.  I haven't
quite figured out what to do about this.

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

And how do they figure out what is inherited from one and what from the other?


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

I.e., @Map would have "templates" set to something like "parent.templates"?

>  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={ ... }

Hmm.  Again, the problem is deciding where to stop.  I don't want to
re-implement Plone.  André has already gave me a talking in the past
for going too far down the Zope road.  (Which is what became Plone,
right?)

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

Great.

>  Local skin switching is a common need.
>  I fink it's important to get it right and early.

By local you mean by section?

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

There is a plan to introduce a single generic syntax for including
anything that's not markdown text.  André and I settled on the
following plan a while back:

1. <name>:: (i.e., [A-Za-z0-9_]*::) starts a the "domain specific
language" section.
2. The end delimiter depends on what follows "::": "::{" goes until
the matching "}", "::(" goes until the matching ")", "::[==[" goes
until the matching "]==]".  "::\n" goes until the end of indentation,
":: " goes until the end of the line, anything else lasts until the
first space.  I.e., you could write

table::{
Lua, 2, 4
Python, 3, 9
}

or you could write

table::
   Lua, 2, 4
   Python, 3, 9

or you could write something like ticket::200 just by itself in the
middle of the line.

In either case, a function with that name will get called and it's
output would be pasted into the HTML.  (Or, to be more precise, it
will be expected to return an object with a to_html() method.)

Which is to say: When it comes to things like portlets, my plan is to
focus on generic mechanisms.  Once the mechanism is in place, the user
will be free to define their own "rockets" (that's what I am calling
them for now), such as "include::Page2.show_content" or
"recent_pages::(5)"

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

Let me think about this one.


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

I do this for cases where I think people would expect the extension,
e.g. MyCalendar.ical or Brazil.svg


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

Yes, thanks for the suggestions.  We'll have to take them one at a
time, though. :)


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

No, quite interesting.

- yuri