[Sputnik-list] usage (was blueprint)

[pierre pracht]

Le 12 févr. 08 à 11:35, Yuri Takhteyev a écrit :

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

Yes, but not necessary for your intended use.
Basically you start on a base grid, and lay your content on it at will.
You didn't directly have a header / content / sidebar / footer.
Scarce if you just intend in a plain old wiki.
But powerful if you drop more composite content.

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

I never have installed a CGI script, so I take this way first (lost a  
few hours on it !)
For me having an integrated web server, would ease first contact.

>>  - create some content for testing
>
> I'll ask PA if we can use his Wikipedia data.  (He seems to have
> converted them to Markdown.)

I wasn't talking about Sputnik default configuration, but I was  
thinking on the first step of a new user.

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

Yes, but in a typical use case, you would move just the skin part, not  
the whole data. A uniform interface is good for simplicity. But having  
all data on the same floor can bring confusion.
What did you think of having a dedicated folder for skin ?

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

No, I take Plone as a contrived example.
Put too complex content in front of user is bad.
But in last version Plone offer a good solution by inverting the scheme.
Main template didn't pull everything, some content can register them  
selves to push content in certain part of template.

>> You can build a custom skin without touching the main template.
>
> At what expense?

You right. I just wanted to warm you on a design where main template  
pull everything. It's a common design, but there's drawback of  
exposing user to unwanted complexity.

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

It sound good, I love the idea of giving user all and just what he need.

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

By hackable, you mean changing original code ?
Imagine, I solve myself the page hierarchy, what happened when you  
change your code ?

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

Just :
   wiki-data
      Folder1
         Doc1.1
         Doc1.2
         Doc1.3
      Folder2
         Doc2.1
         Doc2.2

Would give in Home page
     Folder1 Folder2
     Doc1.1 Doc1.2 Doc1.3

But You need meta-data to sort menu order.

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

It's a good solution. (with folder concept)

>> 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, for me some meta-data belong exclusively to local document.
So having two poll would help to keep it clear.
Generally each property type belongs exclusively to one poll.
But by making local meta-data poll out of prototype chain, you would  
solve your problem. Local meta-data poll would take on prototype poll.

Originally I was thinking on _color.css or _blueprint.css (same model)
I get the feel that CSS and parameters would have better been split.

It could lead to some interesting solution.
Imagine a page can inherit content from his prototype.
Application at _search :
   _search by default give all site result.
   Make a new page who have _search as prototype
   Change some option in local meta-data poll
      (May be an custom edit form)
   You get a page for specialized search.

I think it would be a simple and powerful way for little extension.
Local meta-data poll would be parameters of extension.

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

Yes

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

I have heard you.
I just say once you get folder problem would raise.
Look at Zope for potential problem and their solution.
No need to redo Plone, it works wery well.
But there is a lack of light document oriented framework in software  
landscape.

>> Local skin switching is a common need.
>> I fink it's important to get it right and early.
>
> By local you mean by section?

Yes, but I prefer say folder.

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

It's very interesting.
You should take a look at tal/zope or better hobo/rails : http://hobocentral.net/

Transposed to sputnik it could lead to this :
If <name> could be a link to a page, following parameters would be  
used as local meta-data in a temporary node who have linked page as  
proto.

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

See previous point.
An additional remarque, It ease caching on solution cover partial and  
page caching. More, later you could switch to SSI if available.

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

No I say Mine Type : Store directly ical or svg file in Versium, not a  
lua file containing some ical or svg data. Sputnik would look in order :
   - a .lua file with appropriate action if no matching :
   - a file with file extension then :
     - lookup in a Mine type table a node (ex: svg.lua)
     - build a a node with content the file and proto the mine type node

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

Take it easy, I take interest in lua/Sputnik.
Just give feedback :
   never other-way long-way later work-around ...

pierre