XSSFilter could not parse (X)HTML:
<p>From yuri at sims.berkeley.edu Thu Feb 7 03:08:14 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Thu Feb 7 03:09:42 2008
Subject: [Sputnik-list] blueprint
Message-ID: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<p>Considering Lua list's reaction to the Nanoki demo's clean interface
and the fact that it's seems to be based on [blueprint][1] almost
without any custom CSS, I was wondering:</p>
<ol>
<li>Would it make sense to move Sputnik's templates to blueprint and
get rid of most stylesheets. (Or does anyone have recommendations for
alternatives.)</li>
<li>More generally, what do people think about the visual appearance?
Is there interest in a "cleaner" default? No borders? No underlining
for headers? What might be a "cleaner" alternative to the current
menu bar? (I've been thinking of making the menu bar optional, but
ultimately I don't think one can have a serious website without some
form navigation element on every page.)</li>
</ol>
<p>In regard to question 1, note that blueprint requires a somewhat
non-semantic class names for divs. But then the YUI framework that I
am using now has it's ugly side too.</p>
<p>On a somewhat related note: Nanoki supports search, but only for exact
match in page titles. Sputnik supports full page search, but only for
pages that were indexed by google. What makes more sense as default?
(I can add page title search quite trivially.)</p>
<p>[1] http://files.bjorkoy.com/blueprint/tests/sample.html</p>
<p>--
http://sputnik.freewisdom.org/</p>
<p>From jerome.vuarand at gmail.com Thu Feb 7 03:48:54 2008
From: jerome.vuarand at gmail.com (=?UTF-8?Q?J=C3=A9r=C3=B4me_Vuarand?=)
Date: Thu Feb 7 03:50:23 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a>
Message-ID: <a href="mailto:89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com">89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com</a></p>
<p>2008/2/7, Yuri Takhteyev <a href="mailto:yuri@sims.berkeley.edu">yuri@sims.berkeley.edu</a>:</p>
<blockquote>
<p>Considering Lua list's reaction to the Nanoki demo's clean interface
and the fact that it's seems to be based on [blueprint][1] almost
without any custom CSS, I was wondering:</p>
<ol>
<li>Would it make sense to move Sputnik's templates to blueprint and
get rid of most stylesheets. (Or does anyone have recommendations for
alternatives.)</li>
<li>More generally, what do people think about the visual appearance?
Is there interest in a "cleaner" default? No borders? No underlining
for headers? What might be a "cleaner" alternative to the current
menu bar? (I've been thinking of making the menu bar optional, but
ultimately I don't think one can have a serious website without some
form navigation element on every page.)</li>
</ol>
</blockquote>
<p>I personnally don't like the appearance of the default Sputnik
template, but I must admit it works very well, both in show mode and
edit mode. I still use it for my configuration pages. However as a
basis for custom templates it's maybe too complicated, it took me some
time to understand how everything works.</p>
<p>On the navigation bar subject, I made changes to my sputnik copy to
have a flat navigation bar with all sub-sections displayed all the
time. I think it's more common, and easier to use. This allows quicker
navigation, and with a cascaded menu with javascript to close by
defaults sections other than the current one it doesn't take much more
space. On my website I don't have many sections/subsections yet, so I
have it fully expanded on every pages (see http://piratery.net/em/ for
an example template, and http://piratery.net/em/_navigation for the
navigation data). I can share the code (it may take some time for me
to setup a clean install to make a diff though).</p>
<p>About navbar-less sites, I think that a wiki with a sufficiently dense
network of internal links maybe very usable even without a navigation
bar. Also optionnal may mean hidden by default, but still accessible
with a client-side script.</p>
<p>From yuri at sims.berkeley.edu Thu Feb 7 04:13:37 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Thu Feb 7 04:15:05 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com">89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:fa4efbc00802062213r11e91dd5q3526041edab7db41@mail.gmail.com">fa4efbc00802062213r11e91dd5q3526041edab7db41@mail.gmail.com</a></p>
<blockquote>
<p> I personnally don't like the appearance of the default Sputnik
template, but I must admit it works very well, both in show mode and
edit mode. I still use it for my configuration pages. However as a
basis for custom templates it's maybe too complicated, it took me some
time to understand how everything works.</p>
</blockquote>
<p>Can you be more specific? I don't consider myself much of a designer,
so I promise to not take visual appearance comments personally!</p>
<p>In regards to the difficulty of figuring it out, what would have made
it easier? E.g., would it help to divide the templates between
different pages, e.g., keep all the "advanced" stuff (RSS, edit UI,
etc.) in a different node. Or is it a matter of figuring out how
Cosmo templates work? Would the new documentation
(http://sputnik.freewisdom.org/cosmo/) have helped ?</p>
<blockquote>
<p> On the navigation bar subject, I made changes to my sputnik copy to
have a flat navigation bar with all sub-sections displayed all the
time. I think it's more common, and easier to use. This allows quicker</p>
</blockquote>
<p>This makes sense for a vertical navigation bar. I'll add a config
variable for this: this one is actually quite easy. I assume that
making the menu display vertically wasn't hard, right?</p>
<blockquote>
<p> navigation, and with a cascaded menu with javascript to close by
defaults sections other than the current one it doesn't take much more
space. On my website I don't have many sections/subsections yet, so I</p>
<p> navigation data). I can share the code (it may take some time for me
to setup a clean install to make a diff though).</p>
</blockquote>
<p>If at some later point you decide to upgrade, then send me the new diff.</p>
<blockquote>
<p> About navbar-less sites, I think that a wiki with a sufficiently dense
network of internal links maybe very usable even without a navigation
bar. Also optionnal may mean hidden by default, but still accessible
with a client-side script.</p>
</blockquote>
<p>Or, simpler, there could be a flag to turn it on or off. The issue is
the following: if you install a wiki and it has a menu bar, and you
don't want one, you would presumably ask: "How do I get rid of it?"
and find the solution if it exists and is documented. If you install
a wiki that doesn't seem to have a menu bar and you decide you want
one, you might just assume that there is no support for that and give
up. No?</p>
<ul>
<li>yuri</li>
</ul>
<p>From jerome.vuarand at gmail.com Thu Feb 7 04:46:58 2008
From: jerome.vuarand at gmail.com (=?UTF-8?Q?J=C3=A9r=C3=B4me_Vuarand?=)
Date: Thu Feb 7 04:48:27 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802062213r11e91dd5q3526041edab7db41@mail.gmail.com">fa4efbc00802062213r11e91dd5q3526041edab7db41@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><89d273ba0802062148w40f251d9u69df25ff199cbf0d@mail.gmail.com>
<fa4efbc00802062213r11e91dd5q3526041edab7db41@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:89d273ba0802062246m70c2290ah910f11e9d6227168@mail.gmail.com">89d273ba0802062246m70c2290ah910f11e9d6227168@mail.gmail.com</a></p>
<p>2008/2/7, Yuri Takhteyev <a href="mailto:yuri@sims.berkeley.edu">yuri@sims.berkeley.edu</a>:</p>
<blockquote>
<blockquote>
<p> I personnally don't like the appearance of the default Sputnik
template, but I must admit it works very well, both in show mode and
edit mode. I still use it for my configuration pages. However as a
basis for custom templates it's maybe too complicated, it took me some
time to understand how everything works.</p>
</blockquote>
<p>Can you be more specific? I don't consider myself much of a designer,
so I promise to not take visual appearance comments personally!</p>
<p>In regards to the difficulty of figuring it out, what would have made
it easier? E.g., would it help to divide the templates between
different pages, e.g., keep all the "advanced" stuff (RSS, edit UI,
etc.) in a different node. Or is it a matter of figuring out how
Cosmo templates work? Would the new documentation
(http://sputnik.freewisdom.org/cosmo/) have helped ?</p>
</blockquote>
<p>Actually I didn't ran into Cosmo when modifying the template but only
later when I added support for a "flat" nav bar, but the link is
welcome.</p>
<p>The problem I think comes from the _templates page, which is big and
contains many things, maybe too much. The way path "MAIN -> $nav_bar
-> sputnik sources -> NAV_BAR -> $do_sections -> _navigation" for
example is rather deep, for a feature that I consider to be an
example/tutorial of features the user can add.</p>
<p>Maybe that's the lack of documentation, maybe it's because I do most
of my web admin while watching television :-)</p>
<p>Another point that was not very clear is the Prototype system. I would
have appreciated that links to the default prototypes were in the
default navigation bar. For example on my site I use Sputnik more like
a CMS than an open wiki, and I had to modify the @Root template before
anything else just to make sure I'm the only one with the rights to
create a new page. Categories are another matter that I still have to
discover.</p>
<blockquote>
<blockquote>
<p> On the navigation bar subject, I made changes to my sputnik copy to
have a flat navigation bar with all sub-sections displayed all the
time. I think it's more common, and easier to use. This allows quicker</p>
</blockquote>
<p>This makes sense for a vertical navigation bar. I'll add a config
variable for this: this one is actually quite easy. I assume that
making the menu display vertically wasn't hard, right?</p>
</blockquote>
<p>Actually, as said above, I thought at first I would have been able to
change that only with data files, until I discovered the link between
$nav<em>bar and the NAV</em>BAR template is hardcoded.</p>
<blockquote>
<blockquote>
<p> navigation, and with a cascaded menu with javascript to close by
defaults sections other than the current one it doesn't take much more
space. On my website I don't have many sections/subsections yet, so I</p>
<p> navigation data). I can share the code (it may take some time for me
to setup a clean install to make a diff though).</p>
</blockquote>
<p>If at some later point you decide to upgrade, then send me the new diff.</p>
<blockquote>
<p> About navbar-less sites, I think that a wiki with a sufficiently dense
network of internal links maybe very usable even without a navigation
bar. Also optionnal may mean hidden by default, but still accessible
with a client-side script.</p>
</blockquote>
<p>Or, simpler, there could be a flag to turn it on or off. The issue is
the following: if you install a wiki and it has a menu bar, and you
don't want one, you would presumably ask: "How do I get rid of it?"
and find the solution if it exists and is documented. If you install
a wiki that doesn't seem to have a menu bar and you decide you want
one, you might just assume that there is no support for that and give
up. No?</p>
</blockquote>
<p>That's true, without a doubt. You can apply that argument to any
advanced feature though. However I agree that nav bar is essential
enough to be present by default. Having it fully data-driven would
make it a good example for customization, on the other hand having a
small base of static features helps to stabilize the global
architecture while experimenting with templates.</p>
<p>From pierre.pracht at gmail.com Sun Feb 10 00:21:45 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Sun Feb 10 00:23:27 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a>
Message-ID: <a href="mailto:57B8BF72-1A5D-45CC-B504-5025D249FBB8@gmail.com">57B8BF72-1A5D-45CC-B504-5025D249FBB8@gmail.com</a></p>
<p>Le 7 f?vr. 08 ? 06:08, Yuri Takhteyev a ?crit :</p>
<blockquote>
<p> Would it make sense to move Sputnik's templates to blueprint and
get rid of most stylesheets. (Or does anyone have recommendations for
alternatives.)</p>
</blockquote>
<p>Blueprint 0.7 use erb template for css generation.
A few Lua lines we can do it. (My first Lua lines :) )</p>
<p>I would extend this to typography (custom vertical rhythm)</p>
<blockquote>
<p>In regard to question 1, note that blueprint requires a somewhat
non-semantic class names for divs.</p>
</blockquote>
<p>They have a new function who can aggregate several class content:</p>
<blockquote>
<blockquote>
<p> semantic_classes:</p>
<pre><code>"#footer, #header": column span-24 last
"#content": column span-18 border
"#extra-content": last span-6 column
"div#navigation": last span-24 column
"div.section, div.entry, .feeds": span-6 column
</code></pre>
</blockquote>
</blockquote>
<p>Trying to implement it, would help me to learn Lua.</p>
<p>@+</p>
<p>-------------- next part --------------
Skipped content of type multipart/mixed</p>
<p>From yuri at sims.berkeley.edu Mon Feb 11 07:53:46 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Mon Feb 11 07:55:28 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:48031A48-2491-4246-A332-A994C1A9865C@gmail.com">48031A48-2491-4246-A332-A994C1A9865C@gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com">fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com</a></p>
<p>Thanks for all the feedback and links.</p>
<p>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.</p>
<p>Now a few specific issues.</p>
<ol>
<li><p>I'll wrap the navbar template into the MAIN template and also
remove everything but "MAIN" from _templates, putting it into
<em>more</em>templates. Basically to keep the _templates file simple.</p></li>
<li><p>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 <em>all</em> 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.</p></li>
<li><p>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?</p></li>
<li><p>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 "<em>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</em>css rock.</p></li>
</ol>
<p>To comment on</p>
<blockquote>
<p> You ca use a standard naming system :
#header #header<em>navbar #header</em>login
So user can use his own skin
But, nobody use it !!</p>
</blockquote>
<p>Can you explain this?</p>
<blockquote>
<p> The only down-side of Blueprint.
You can't re-order content for SEO.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> Incoming version use some Ruby script.
I will convert them to Sputnik.</p>
</blockquote>
<p>See above.</p>
<blockquote>
<p> I'm sorry for my very bad english. But I would help as much I can.</p>
</blockquote>
<p>No problem, I understood you. And help is always appreciated.</p>
<p>But speaking of foreign languages: if someone wants to discuss Sputnik
in Portuguese, Kepler-BR might be an appropriate list for that.</p>
<blockquote>
<p> Sputnik has a very nice architecture.
I would try versium.storage.svn.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> If I can get folder/page hierarchy, it would replace my Dokuwiki.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> Have you some project for :
- table/view additional storage (ex: http://couchdb.org/), would be
nice for folksonomy.</p>
</blockquote>
<p>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.</p>
<blockquote>
<ul>
<li>skin switching, DEFAULT<em>TEMPLATE</em>SET ? @Root : templates =
"_templates"</li>
<li>local skin / sub site. Page can ask directly parent folder for value
(independent from prototype)</li>
</ul>
</blockquote>
<p>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.</p>
<p>For a subsite, you <em>can</em> 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.</p>
<p>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, <em>then</em> worry
about switching skins. Right now there aren't any skins to switch
between...</p>
<blockquote>
<ul>
<li>composite page / portlet</li>
</ul>
</blockquote>
<p>That would be interesting.</p>
<p>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).</p>
<ul>
<li>yuri</li>
</ul>
<hr/>
<p>http://sputnik.freewisdom.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blueprint<em>css.lua
Type: text/x-lua
Size: 7183 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080211/54a1686a/blueprint</em>css.bin</p>
<p>From pierre.pracht at gmail.com Mon Feb 11 19:22:28 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Mon Feb 11 19:25:01 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com">fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com">BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com</a></p>
<p>Le 11 f?vr. 08 ? 10:53, Yuri Takhteyev a ?crit :</p>
<blockquote>
<p>Thanks for all the feedback and links.</p>
<p>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.</p>
</blockquote>
<p>Integrating Blueprint very helpful :
- provide sensible default for typography (vertical rhythm)
- easy layout (grid based)
- constant rendering (CSS tweak for different browser)</p>
<p>It would be nice to sketch a use case :
- install sputnik : integrated installer + stand alone web server <br/>
option (xavante?)
- first request trigger a custom page with essential configuration <br/>
and common option
- create some content for testing
- test some option for changing look and feel</p>
<pre><code>- color font size border image...
- navigation structure
- common web site layout
</code></pre>
<p> - explore configuration option to see if it fit requirement</p>
<pre><code>- user management
- content structure
- different type of document
</code></pre>
<p> - customize look and feel</p>
<pre><code>- 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)
</code></pre>
<p> - deploy</p>
<pre><code>- make install on production server
- configure web server
- import skin build in development environment
</code></pre>
<p>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.</p>
<blockquote>
<p>Now a few specific issues.</p>
<ol>
<li>I'll wrap the navbar template into the MAIN template and also
remove everything but "MAIN" from _templates, putting it into
<em>more</em>templates. Basically to keep the _templates file simple.</li>
</ol>
</blockquote>
<p>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 <br/>
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).</p>
<p>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 <br/>
element minus variable content ?</p>
<p>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 <br/>
good base.</p>
<blockquote>
<ol>
<li>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 <em>all</em> 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.</li>
</ol>
</blockquote>
<p>You mean like this :
http://logicalinteractive.com/about/default.aspx
http://www.cssdrive.com/index.php/menudesigns/item/harbor<em>curved</em>two<em>level</em>menu/</p>
<p>I'm not sure it can be done only with css AND nested list. I would try <br/>
to do it.</p>
<blockquote>
<ol>
<li>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?</li>
</ol>
</blockquote>
<p>Very good ! Typical usage can be :
- Build prototype with Blueprint class helper :</p>
<pre><code><div class="last span-6 column">
</code></pre>
<p> - Tweak template option : color font size ... :</p>
<pre><code>TEMPLATE_OPTION = <a href='/en/COLUMN_WIDTH_40,_.'>COLUMN_WIDTH = 40, </a>
</code></pre>
<p> - Name custom part with id and recurrent use with class :</p>
<pre><code><div id="extra-content" class="last span-6 column">
</code></pre>
<p> - Let Blueprint/Sputnik build aggregate rule :</p>
<pre><code>SEMANTIC_CLASSES = <a href='/en/_#extra-content"="last span-6 column", ... '>"</a>
<div id="extra-content">
</code></pre>
<blockquote>
<ol>
<li>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 "<em>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</em>css rock.</li>
</ol>
<p>To comment on</p>
</blockquote>
<p>A module can be a good fit as you say it could be used in other context.</p>
<p>I would completing it :
- Custom font-size and vertical rhythm (test done see attachment)
- Color font border ... option
- Semantic class aggregation</p>
<pre><code>- Simple concatenation first
- Property parsing and masking later
</code></pre>
<p>It leads to a question (independent of extraction in a module)
How separate template from its own options ? (not site wide)</p>
<blockquote>
<blockquote>
<p>You ca use a standard naming system :</p>
<h1>header #header<em>navbar #header</em>login</h1>
<p>So user can use his own skin
But, nobody use it !!</p>
</blockquote>
<p>Can you explain this?</p>
</blockquote>
<p>I can't bring back a link on this.
Basically, if all site use :</p>
<h1>header #header_navbar #content #footer ...</h1>
<p>You can build your own CSS (user css) and tweak every site at your <br/>
taste.
Some web site do it (don't remember which)</p>
<p>At least it means :
Don't bother with semantic class nobody see (use) them.</p>
<p>On the other side : http://microformats.org/ are very use-full.</p>
<blockquote>
<blockquote>
<p>The only down-side of Blueprint.
You can't re-order content for SEO.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>Yes, and they would make a prototype with Blueprint first.</p>
<blockquote>
<blockquote>
<p>Incoming version use some Ruby script.
I will convert them to Sputnik.</p>
</blockquote>
<p>See above.</p>
<blockquote>
<p>I'm sorry for my very bad english. But I would help as much I can.</p>
</blockquote>
<p>No problem, I understood you. And help is always appreciated.</p>
<p>But speaking of foreign languages: if someone wants to discuss Sputnik
in Portuguese, Kepler-BR might be an appropriate list for that.</p>
<blockquote>
<p>Sputnik has a very nice architecture.
I would try versium.storage.svn.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>I would try luarocks based install first.
SCM based storage is important for me, but there's many to-do in the <br/>
mean time.</p>
<p>For the future, would it be possible to stack storage (like proto in <br/>
page) ?
More on this over.</p>
<blockquote>
<blockquote>
<p>If I can get folder/page hierarchy, it would replace my Dokuwiki.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>At first, svn (sub) folder hierarchy = page hierarchy = navigation <br/>
automatic generation</p>
<blockquote>
<blockquote>
<p>Have you some project for :
- table/view additional storage (ex: http://couchdb.org/), would be
nice for folksonomy.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>Functionality of CouchDB table/view storage is orthogonal to versium <br/>
document storage.
See Amazon SimpleDB / S3
Other CMS put everything in SQL Database.
Plone get Object / Document oriented storage hierarchy (completed by <br/>
index)</p>
<p>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</p>
<p>Example :
- Insert a page with extra field for keywords.
- A filter is set in request pipeline.</p>
<pre><code> - find keywords field
- spit field in individual keyword
- make insert keyword table
</code></pre>
<p> - A filter is set in response pipeline</p>
<pre><code>- find document id
- request a keyword view sorted by document id
- find page keywords
- request a keyword view sorted by keyword
- find related document
</code></pre>
<p> - Page is displayed with his keyword and related document link.</p>
<p>Why this ?
- scan every documents is too slow.
- SQL is overkill, lua table + file backup can do it.</p>
<pre><code> - table / view can be generalized to many back-end.
</code></pre>
<p> - Play well with other format : XML,Json, ...</p>
<pre><code> - each table / view entry is a independent set of information
</code></pre>
<p>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 <br/>
versium)
- skin storage for customs templates (would use versium in <br/>
development phase)
- base storage for : user configuration and document</p>
<pre><code> - alternate storage for test, staging edition. May be mapped to
</code></pre>
<p>SCM branching.</p>
<blockquote>
<blockquote>
<ul>
<li>skin switching, DEFAULT<em>TEMPLATE</em>SET ? @Root : templates =
"_templates"</li>
<li>local skin / sub site. Page can ask directly parent folder for <br/>
value
(independent from prototype)</li>
</ul>
</blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>For a subsite, you <em>can</em> change the templates though not the
stylesheets.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.)</p>
</blockquote>
<p>It would be very useful.
With this you can add basic option for a special document (template, <br/>
site-map ...).
User can have a simple and convenient interface for editing option.
Site wide option would be more structured.</p>
<blockquote>
<p>Once this works it would in theory be possible to do a subsite with a
different CSS using prototypes.</p>
</blockquote>
<p>Maybe it would be necessary to split option in to :
- overriding defaults
- document specific option</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Yes, it has heart plone/zope badly.
In zope technology it's named "acquisition"
It's very convenient and powerful :
Objet get comportment based</p>
<pre><code> - on localization (folder)
- and type (class and inheritance)
</code></pre>
<blockquote>
<p>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.</p>
</blockquote>
<p>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 <br/>
hierarchy)</p>
<p>Basically you can do it before action code by requesting and <br/>
aggregating meta-data storage along the node path.
For this you just need to build a view of option with absolute path as <br/>
key.
The result can be stored in request table under a key : <br/>
acquisition={ ... }</p>
<p>When it's sensible default, option field can be tagged to use <br/>
acquisition value (ex: skin, user permission ...)</p>
<blockquote>
<p>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, <em>then</em> worry
about switching skins. Right now there aren't any skins to switch
between...</p>
</blockquote>
<p>Yes you right, I would complete Blueprint / lua / Sputnik integration <br/>
first.
Then a custom skin.</p>
<p>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.</p>
<blockquote>
<blockquote>
<ul>
<li>composite page / portlet</li>
</ul>
</blockquote>
<p>That would be interesting.</p>
</blockquote>
<p>The first usage is a custom homepage who present a summary of site <br/>
content.
Ideally a document could be allowed to contain reference to other <br/>
document :
<a href='/en//section/page'>/section/page</a> would build a link to page default presentation
{{/section/page.summary}} would include content generated by a custom <br/>
action.
{{/section.list&last=5}} would give a formated list of 5 last pages.</p>
<p>So you can do internal request and target node must be aware of <br/>
originated node.
Used in document, you get a composite page.
Used in template you get a portlet.</p>
<p>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 <br/>
hierarchy. But you didn't get directly a mean-full representation.
Taking it easy by processing internal request as external simply by <br/>
dropping main template, this would cover more frequent use case.</p>
<p>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 <br/>
with a tweaked base URL
- Useful generalization :</p>
<pre><code> - External request could be turned in a request of main template
</code></pre>
<p>porlet (same node but different action / proto / template)</p>
<pre><code> - main template would internally request rendered request node
</code></pre>
<p>content part</p>
<pre><code> - In some case it won't ex: meta-data edition
</code></pre>
<p>Content aggregation, with local skinning are the most obvious <br/>
shortcoming in existing frame work.</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>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 <br/>
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 <br/>
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 / <br/>
edition.</p>
<p>Typical use case :
- You use your favorite editor directly on file or a copy.
- You keep presentation option aside of document.</p>
<p>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 <br/>
good architecture.
Plone is overkill for many use case, but small frame work have many <br/>
short coming.
My fell is that : you can do 1/2 of Plone functionality with 1/100 of <br/>
his code base, it would cover 90% of common use case.
An example : look at document versioning in Plone ! How many LOC in <br/>
Versium ?
You could say : It isn't the same functionality, but it cover the same <br/>
use case !!</p>
<p>Many of previous idea aren't trivial. But keeping them in mind can pay <br/>
off in long run.
I'm sure this can lead to a versatile framework with a relatively <br/>
small code base.</p>
<p>End of dream to-do for now :
- blueprint_css.lua
- a test template based on
- custom form for editing template option</p>
<pre><code> - color selector (maybe predefine color class )
http://thephotofinishes.com/colors3.htm
- A grid helper
http://www.sprymedia.co.uk/article/Design
</code></pre>
<p>I'm sure that Sputnik+Blueprint would shine at letting designer step in.</p>
<p>I hope you wouldn't bother that I have turned this mail in a diary of <br/>
my thinking :(</p>
<p>-------------- next part --------------
A non-text attachment was scrubbed...
Name: <em>blueprint</em>screen.lua
Type: application/octet-stream
Size: 8402 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080211/e91ac831/<em>blueprint</em>screen.obj</p>
<p>From yuri at sims.berkeley.edu Tue Feb 12 08:35:43 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Tue Feb 12 08:37:27 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com">BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com">fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com</a></p>
<blockquote>
<p> Integrating Blueprint very helpful :
- provide sensible default for typography (vertical rhythm)
- easy layout (grid based)
- constant rendering (CSS tweak for different browser)</p>
</blockquote>
<p>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?</p>
<blockquote>
<ul>
<li>install sputnik : integrated installer + stand alone web server
option (xavante?)</li>
</ul>
</blockquote>
<p>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.</p>
<blockquote>
<ul>
<li>create some content for testing</li>
</ul>
</blockquote>
<p>I'll ask PA if we can use his Wikipedia data. (He seems to have
converted them to Markdown.)</p>
<blockquote>
<ul>
<li>deploy
<ul>
<li>make install on production server</li>
<li>configure web server</li>
<li>import skin build in development environment</li>
</ul></li>
</ul>
</blockquote>
<p>Note that you can handle deployment by simply zipping up the
"wiki-data" directory and copying it to a different server.</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>Is that simpler?</p>
<blockquote>
<p> You can build a custom skin without touching the main template.</p>
</blockquote>
<p>At what expense?</p>
<blockquote>
<p> 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 ?</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> You mean like this :
http://logicalinteractive.com/about/default.aspx
http://www.cssdrive.com/index.php/menudesigns/item/harbor<em>curved</em>two<em>level</em>menu/</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p> I'm not sure it can be done only with css AND nested list. I would try
to do it.</p>
</blockquote>
<p>People say it can be.</p>
<blockquote>
<ul>
<li>Name custom part with id and recurrent use with class :
<div id="extra-content" class="last span-6 column"></li>
<li>Let Blueprint/Sputnik build aggregate rule :
SEMANTIC_CLASSES = <a href='/en/_#extra-content"="last span-6 column", ... '>"</a>
<div id="extra-content"></li>
</ul>
</blockquote>
<p>Not sure what you mean here.</p>
<blockquote>
<p> A module can be a good fit as you say it could be used in other context.</p>
<p> I would completing it :
- Custom font-size and vertical rhythm (test done see attachment)
- Color font border ... option
- Semantic class aggregation</p>
<pre><code>- Simple concatenation first
- Property parsing and masking later
</code></pre>
</blockquote>
<p>Sounds good.</p>
<blockquote>
<p> It leads to a question (independent of extraction in a module)
How separate template from its own options ? (not site wide)</p>
</blockquote>
<p>What do you mean?</p>
<blockquote>
<p> Don't bother with semantic class nobody see (use) them.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> For the future, would it be possible to stack storage (like proto in
page) ?
More on this over.</p>
</blockquote>
<p>Stack storage? What do you mean? Have different pages use different
storage backend?</p>
<blockquote>
<p> At first, svn (sub) folder hierarchy = page hierarchy = navigation
automatic generation</p>
</blockquote>
<p>Explain.</p>
<blockquote>
<p> Functionality of CouchDB table/view storage is orthogonal to versium
document storage.</p>
</blockquote>
<p>Well, it's a similar idea. The main differences are:</p>
<ol>
<li>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.</li>
<li>Versium doesn't support search - yet.</li>
<li>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.</li>
</ol>
<blockquote>
<p> 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</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> 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</p>
<pre><code> - alternate storage for test, staging edition. May be mapped to
</code></pre>
<p> SCM branching.</p>
</blockquote>
<p>Very interesting, though you are confusing "versium" (the API) with
"versium.storage.simple" (a file-based implementation). But I see
what you mean.</p>
<p>Andr?, what do you think about this?</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>Sounds too complicated, frankly.</p>
<blockquote>
<p> Maybe it would be necessary to split option in to :
- overriding defaults
- document specific option</p>
</blockquote>
<p>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.</p>
<blockquote>
<p> Yes, it has heart plone/zope badly.
In zope technology it's named "acquisition"
It's very convenient and powerful :
Objet get comportment based</p>
<pre><code> - on localization (folder)
- and type (class and inheritance)
</code></pre>
</blockquote>
<p>And how do they figure out what is inherited from one and what from the other?</p>
<blockquote>
<p> 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)</p>
</blockquote>
<p>I.e., @Map would have "templates" set to something like "parent.templates"?</p>
<blockquote>
<p> 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={ ... }</p>
</blockquote>
<p>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?)</p>
<blockquote>
<p> Yes you right, I would complete Blueprint / lua / Sputnik integration
first.
Then a custom skin.</p>
</blockquote>
<p>Great.</p>
<blockquote>
<p> Local skin switching is a common need.
I fink it's important to get it right and early.</p>
</blockquote>
<p>By local you mean by section?</p>
<blockquote>
<p> 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 :
<a href='/en//section/page'>/section/page</a> 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.</p>
</blockquote>
<p>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:</p>
<ol>
<li><name>:: (i.e., [A-Za-z0-9_]*::) starts a the "domain specific
language" section.</li>
<li>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</li>
</ol>
<p>table::{
Lua, 2, 4
Python, 3, 9
}</p>
<p>or you could write</p>
<p>table::
Lua, 2, 4
Python, 3, 9</p>
<p>or you could write something like ticket::200 just by itself in the
middle of the line.</p>
<p>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.)</p>
<p>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<em>content" or
"recent</em>pages::(5)"</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>Let me think about this one.</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>I do this for cases where I think people would expect the extension,
e.g. MyCalendar.ical or Brazil.svg</p>
<blockquote>
<p> 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.</p>
</blockquote>
<p>Yes, thanks for the suggestions. We'll have to take them one at a
time, though. :)</p>
<blockquote>
<p> I hope you wouldn't bother that I have turned this mail in a diary of
my thinking :(</p>
</blockquote>
<p>No, quite interesting.</p>
<ul>
<li>yuri</li>
</ul>
<p>From carregal at fabricadigital.com.br Tue Feb 12 12:22:29 2008
From: carregal at fabricadigital.com.br (Andre Carregal)
Date: Tue Feb 12 12:24:20 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com">fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:92ab989c0802120622g36659955ya302f71713501394@mail.gmail.com">92ab989c0802120622g36659955ya302f71713501394@mail.gmail.com</a></p>
<p>On Feb 12, 2008 8:35 AM, Yuri Takhteyev <a href="mailto:yuri@sims.berkeley.edu">yuri@sims.berkeley.edu</a> wrote:</p>
<blockquote>
<blockquote>
<p> 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</p>
<pre><code> - alternate storage for test, staging edition. May be mapped to
</code></pre>
<p> SCM branching.</p>
</blockquote>
<p>Very interesting, though you are confusing "versium" (the API) with
"versium.storage.simple" (a file-based implementation). But I see
what you mean.</p>
<p>Andr?, what do you think about this?</p>
</blockquote>
<p>I'm not sure I got the point correctly, but while I agree that
different resources may need different storage policies, using
different APIs for that would be confusing.</p>
<p>If you are talking about using a common API (versium) but separate
storage models for the resources then it may be a reasonable idea. On
the other hand, if one of the layers uses versioning, then why not use
it for every resource?</p>
<p>The way I see it, Sputnik is a curious case of "paradigm overload"... :o)</p>
<p>While it tries to offer Pareto balances on different areas (storage,
information architecture and retrievability for example), it also
tries to keep things simple, small and flexible. I guess this is not
doable in the long run, since you have to compromise somewhere.</p>
<p>Sputnik started as a really simple/flexible wiki engine and has
evolved into a very powerfull wiki framework, I just can't see it as
simple anymore. Not that this is bad news per se, it's just a matter
of having the driving keywords clear during the design.</p>
<p>Maybe it's time to decide if Sputnik should focus on the early game or
in the late game. A third option would be to consider an explicit
split between a framework and a wiki instance.</p>
<p>Thus one layer would have real power while the other would customize
this power in order to be reachable by the masses. While way more
advanced, Zope/Plone are one example of this approach. One is a
generic content biased web framework, while the second focus on
solving the CMS case.</p>
<p>In our case, one layer could offer the basic tools (versioning,
templating, search, categorization, user management, plugins etc)
while another layer could be comprised of applications that use those
tools (be it a wiki, blog, cms, GTD helper, CRM etc).</p>
<p>I hope this has not been too noisy. :o)</p>
<p>Andr?</p>
<p>From pierre.pracht at gmail.com Tue Feb 12 15:46:31 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Tue Feb 12 15:48:59 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:92ab989c0802120622g36659955ya302f71713501394@mail.gmail.com">92ab989c0802120622g36659955ya302f71713501394@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
<92ab989c0802120622g36659955ya302f71713501394@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:1223FE8C-37A3-4F54-9F04-508A840D6460@gmail.com">1223FE8C-37A3-4F54-9F04-508A840D6460@gmail.com</a></p>
<p>Le 12 f?vr. 08 ? 15:22, Andre Carregal a ?crit :</p>
<blockquote>
<p>On Feb 12, 2008 8:35 AM, Yuri Takhteyev <a href="mailto:yuri@sims.berkeley.edu">yuri@sims.berkeley.edu</a> <br/>
wrote:</p>
<blockquote>
<blockquote>
<p>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</p>
<pre><code>- alternate storage for test, staging edition. May be mapped to
</code></pre>
<p>SCM branching.</p>
</blockquote>
<p>Very interesting, though you are confusing "versium" (the API) with
"versium.storage.simple" (a file-based implementation). But I see
what you mean.</p>
<p>Andr?, what do you think about this?</p>
</blockquote>
<p>I'm not sure I got the point correctly, but while I agree that
different resources may need different storage policies, using
different APIs for that would be confusing.</p>
</blockquote>
<p>No, for me "stack storage" was mean for : "versium over versium"
More on this point later.</p>
<p>Disclaimer : I just started to look at lua/sputnik a few day ago. So I <br/>
can make wrong assumption. I would dive into the code later.</p>
<blockquote>
<p>If you are talking about using a common API (versium) but separate
storage models for the resources then it may be a reasonable idea. On
the other hand, if one of the layers uses versioning, then why not use
it for every resource?</p>
</blockquote>
<p>Yes, "No need of versium" would have been versium.storage.null
I agree that cost of versioning is cheap.
But a direct mapper of node could be trivial to write and cover some <br/>
specific case. Look at pre-populated content of sputnik. Some content <br/>
will be over written by user : Home<em>page.lua. But who would edit <br/>
@Root.lua ?
Root.lua is part of sputnik code. Better is to let it in so it will be <br/>
update with it.
If we get a versium.storage.null pointing sputnik/node</em>default, <br/>
wiki_data would be keep clean.</p>
<p>But what would happen if user edit Home<em>page.lua ?
Then came the "stack storage" : user would get a Home</em>page.lua copy in <br/>
his wiki-data SCM backed versium.storage.svn
What happen here is a copy on write semantic.</p>
<p>You can object it didn't belong to versium to handle this !
But that's possible : making a copy to a new storage is equivalent to <br/>
copying file to a new version. The only difference is that you use a <br/>
storage axis instead of a temporal axis.
Name it : versium.storage.versium</p>
<blockquote>
<p>The way I see it, Sputnik is a curious case of "paradigm <br/>
overload"... :o)</p>
</blockquote>
<p>What in a programming language isn't a paradigm ?
- Good one let solve problem with ease.
- Bad one make you struggle at endorsing complexity in your mind.</p>
<blockquote>
<p>While it tries to offer Pareto balances on different areas (storage,
information architecture and retrievability for example), it also
tries to keep things simple, small and flexible. I guess this is not
doable in the long run, since you have to compromise somewhere.</p>
</blockquote>
<p>I agree that complexity need to be balanced :
- Introduce paradigm, and you get a step learning curve.
- Always keep idiomatic way and you would suffer as complexity raise</p>
<p>Decoupling storage in sputnik is very good thing, offering some nice <br/>
perspective. So I disagree on "simple, small and flexible"</p>
<p>"simple, small and flexible" pickup two of three :
Simple and small : do nothing, get nothing.
Simple and flexible : keep it kiss, do as need, but rewrite it later.
Small and flexible : use-full paradigms, need to master them.</p>
<p>There is no silver bullet, people always do them in order.</p>
<blockquote>
<p>Sputnik started as a really simple/flexible wiki engine and has
evolved into a very powerfull wiki framework, I just can't see it as
simple anymore. Not that this is bad news per se, it's just a matter
of having the driving keywords clear during the design.</p>
</blockquote>
<p>I have throw some idea. It isn't that they need to be done. That was a <br/>
test bed to see yours objectives. For my own need I wouldn't do even a <br/>
third of that.</p>
<blockquote>
<p>Maybe it's time to decide if Sputnik should focus on the early game or
in the late game.</p>
</blockquote>
<p>I'm interested in seeing if you foresee post "Earth (0.5)".
I would help immediately on my center of interest (blueprint).</p>
<blockquote>
<p>A third option would be to consider an explicit
split between a framework and a wiki instance.</p>
</blockquote>
<p>Or progressively split part as concepts emerge ?
Post 0.5 goal ?</p>
<blockquote>
<p>Thus one layer would have real power while the other would customize
this power in order to be reachable by the masses. While way more
advanced, Zope/Plone are one example of this approach. One is a
generic content biased web framework, while the second focus on
solving the CMS case.</p>
</blockquote>
<p>IMHO Zope/Plone is in this case a contriver example.
Zope didn't reach a large audience due a step learning curve.
Plone brings Zope to people by offering a powerful solution.
But dive into Plone is difficult you rapidly head to Zope.</p>
<p>When I use Plone as argument it's simply :
- It get a good architecture (Five / Zope 3.0 rewrite).
- All his functionality have been written to cover existing need.</p>
<p>But Plone is doomed by his past :
- Still based on Zope 2.0
- Too many functionality
- Tied to a storage technology</p>
<blockquote>
<p>In our case, one layer could offer the basic tools (versioning,
templating, search, categorization, user management, plugins etc)
while another layer could be comprised of applications that use those
tools (be it a wiki, blog, cms, GTD helper, CRM etc).</p>
</blockquote>
<p>I take a look at sputnik because I see in it : A document / resource <br/>
oriented architecture. Something that exist in Zope, but with too many <br/>
complexity. Immediately Sputnik lack of categorization / meta-data / <br/>
indexing (see a for-coming mail for this point).</p>
<p>For now call it a wiki. Later you can build on it : blog, cms, GTD <br/>
helper, CRM etc ...
But a wiki has very low requirement on template (one document = one <br/>
page).
So if you need to split, this is the critical point. But it would <br/>
bring a hug complexity.</p>
<p>Just an insight on my personal reflexion :
I don't see Controller / View coupling as a bad thing for user <br/>
interface.
Better push more thing on model, see how you have bring versioning in <br/>
storage.</p>
<p>My feel is that there is a market for a strong document / resource <br/>
back-end that bring representation at URI level (REST ?)
User interaction and data representation can be a fin layer on top of <br/>
it. Empowering a wiki can be a good base for it.
See :
Delivrance / Plone
http://www.openplans.org/projects/deliverance/project-home
Ajatus / CouchDB
http://www.ajatus.info/</p>
<p>Why Lua ? Not sure need to master it but :
- Table orientation who fit the objective
- Small footprint allowing to enable it in web server</p>
<pre><code> (collapsing network stack)
</code></pre>
<p> - Support of coroutine</p>
<pre><code> (Need to dive in Kepler, but a single instance of Lua can
</code></pre>
<p>handle multiple request in an event handled fashion ?)</p>
<p>Be care I didn't says that Sputnik must be that dream.
It just what I was fiddling in very long foresight.</p>
<blockquote>
<p>I hope this has not been too noisy. :o)</p>
</blockquote>
<p>me too</p>
<p>pierre</p>
<p>From pierre.pracht at gmail.com Wed Feb 13 13:45:17 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Wed Feb 13 13:47:10 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com">fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com">28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com</a></p>
<p>Le 12 f?vr. 08 ? 11:35, Yuri Takhteyev a ?crit :</p>
<blockquote>
<blockquote>
<ul>
<li>Name custom part with id and recurrent use with class :
<div id="extra-content" class="last span-6 column"></li>
<li>Let Blueprint/Sputnik build aggregate rule :
SEMANTIC_CLASS = [["#extra-content"="last span-6 <br/>
column", ... ]]
<div id="extra-content"></li>
</ul>
</blockquote>
<p>Not sure what you mean here.</p>
</blockquote>
<p>See in attachment, I have in order :
- set class="span-6 colum" to put it in place
- add id="search" to attach some custom property in css
- strip of class="span-6 colum" by building them in SEMANTIC_CLASS</p>
<blockquote>
<blockquote>
<p>A module can be a good fit as you say it could be used in other <br/>
context.</p>
<p>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</p>
</blockquote>
<p>Sounds good.</p>
</blockquote>
<p>A prototype is done.
But I use Xavante with WSAPI. I need to relaunch it to see change. Is <br/>
there a development node ? I stuck in trying to use it with CGI.</p>
<blockquote>
<blockquote>
<p>It leads to a question (independent of extraction in a module)
How separate template from its own options ? (not site wide)</p>
</blockquote>
<p>What do you mean?</p>
</blockquote>
<p>If a template use some parameters, user will first tweak parameters.
Ideally they need a custom form.</p>
<p>Currently, you get both in same field.
See other mail for reflexion on local meta-data.</p>
<blockquote>
<blockquote>
<p>Don't bother with semantic class nobody see (use) them.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>I agree, with semantic class you get both :</p>
<blockquote>
<blockquote>
<p><div id="logo">
SEMANTIC<em>CLASS = { ["#logo"] = {".span-4", ".column"}, }
But if the downstream developers want to change site layout, it need <br/>
to dive into configuration to find SEMANTIC</em>CLASS parameter.</p>
</blockquote>
</blockquote>
<p>First, when I have finish semantic class functionality, I was <br/>
thinking : What a heck, not very use-full.
Rapidly I saw were it pay of : You get all your layout parameter in <br/>
one place.</p>
<p>See above for reflexion on use of a custom form.
User will in order :
- Change common option : color, font, size, image ...
- And later dive into template</p>
<p>PS: I didn't understand how luarocks must be packaged
You would see in attachment :</p>
<p>a tar.gz of blueprint module :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blueprintcss.tar.gz
Type: application/x-gzip
Size: 4160 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080213/82095f1a/blueprintcss.tar.bin
-------------- next part --------------</p>
<p>a modified version of css.lua who add blueprint_css action :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: css.lua
Type: application/octet-stream
Size: 1074 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080213/82095f1a/css.obj
-------------- next part --------------</p>
<p>a css template who use it :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: <em>blueprint</em>screen.lua
Type: application/octet-stream
Size: 1309 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080213/82095f1a/<em>blueprint</em>screen.obj
-------------- next part --------------</p>
<p>a other style sheet and an HTML template for test :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: <em>blueprint</em>layout.lua
Type: application/octet-stream
Size: 1327 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080213/82095f1a/<em>blueprint</em>layout.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: <em>templates.lua
Type: application/octet-stream
Size: 13770 bytes
Desc: not available
Url : http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080213/82095f1a/</em>templates.obj
-------------- next part --------------</p>
<p>From yuri at sims.berkeley.edu Thu Feb 14 17:19:46 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Thu Feb 14 17:21:40 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com">471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
<28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com>
<fa4efbc00802140057n4135cddcp7aac923f8b46ee7e@mail.gmail.com>
<471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com">fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com</a></p>
<p>Great, I'll test this in the evening. For now here are a few suggestions:</p>
<ol>
<li><p>There is a script in my svn repository that you can use to package
rocks: scripts/make<em>a</em>rock.sh Also, I would create your own
repository, which is really a web directory with rocks and a simple
"manifest" file (see http://sputnik.freewisdom.org/rocks/manifest).
At some points all rocks should be featured in the main repository,
but for experimental versions I think it really helps to have your own
directory.</p></li>
<li><p>I would make this into two rocks: "blueprintcss" (everything not
sputnik-specific) and "sputnik-blueprint". Note that
sputnik-blueprint should reproduce sputnik's folder hiearchy:</p></li>
</ol>
<p>sputnik-blueprint/lua/sputnik/actions/blueprint<em>css.lua
sputnik-blueprint/lua/sputnik/node</em>defaults/<em>blueprint</em>templates.lua
sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>screen.lua
sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>layout.lua</p>
<p>This way those files will be available as if they were a part of
"sputnik" package: require("sputnik.actions.blueprint_css")</p>
<p>For now, let's keep this as a "plugin" that could be added on top of
"standard" sputnik: I promised people that the current version would
be feature-frozen until it's tested, documented and properly released.
I want to at least <em>try</em> to keep this promise. :) For the next
iteration we can think if some of it would better be integrated into
the core. This means that let's assume for now that the plugin will
add files and nodes rather than override existing ones. E.g., instead
of replacing _templates, let's add <em>blueprint</em>templates and tell the
user to set DEFAULT<em>TEMPLATE</em>SET in _config.</p>
<p>If small changes are necessary for the current sputnik, I'll make
them, but please send them as a patch against SVN if possible.</p>
<ol>
<li><p>You should email the Kepler list about the generic blueprint
library. I think it's an interesting idea and it's may be useful for
Lua-based web stuff beyond Sputnik. And we might get good
suggestions.</p></li>
<li><p>If you have a google account, I can add you to the sputnik-wiki
project (http://code.google.com/p/sputnik-wiki/) so that you could
check the files into SVN.</p></li>
<li><p>Any hope for documentation? One possibility would be to start a
page at http://sputnik.freewisdom.org/en/BlueprintCSS. Don't worry
about English grammar - we'll fix it up later.</p></li>
<li><p>yuri</p></li>
</ol>
<p>On Thu, Feb 14, 2008 at 8:04 AM, pierre pracht <a href="mailto:pierre.pracht@gmail.com">pierre.pracht@gmail.com</a> wrote:</p>
<blockquote>
<p>Le 14 f?vr. 08 ? 09:57, Yuri Takhteyev a ?crit :</p>
<p>I can see where this is going, but for some reason I am getting an
error when I replace by <em>templates with your version. I got rid of
the error by getting rid of NAV</em>BAR,</p>
<p>My bad, I have change get<em>nav</em>bar action in wiki.lua
Sorry for the mess, I just packed them in hurry to illustrate my answer.
I would take a look at the way you pack rocks.
And takes file from svn as base install, so I can easily build patch.
Is there some particular recommendation on :
svn / rocks / sputnik / sputnik-xxx ?
I really need to get It right, actually I was trying to integrate :
http://dnevnikeklektika.com/uni-form/
(Rq: a choice for JavaScript library ?)</p>
<p>I would finish blueprint later as without form handling, It isn't very
useful.</p>
<p>but the the layout doesn't quite look right.</p>
<p>Rq : It miss the IE style Sheet, be care if you use it.</p>
<p> Next time can you attach a screen shot so that I know
what I should expect to see?</p>
<p>Done, but there is nothing new.
Interesting parts are in <em>blueprint</em>screen :
- You can change site and column size of grid
- You set a base typography with a corect handling of line spacing
- You can change typography of base element : h1={ 3 },
- Or of your own style ["#menu, #submenu"]={ 1.5 ,2 },
- It's a very strong point of blueprint,</p>
<pre><code> this code give you easy customization of it. (btw need to be finished)
</code></pre>
<p> - Semantic class : let you use blue print class</p>
<pre><code>without putting them in your template.
</code></pre>
<p>All of this could be completed with class dedicated to color (<em>color)
Have you a naming scheme for it ? :
tonic dominant secondary shade ...
ex : ["#menu"] = { ".tonic", ".bg</em>dominate<em>shade</em>5" },</p>
<p>In the end we could imagine a dedicated form to help user in those
customization.</p>
<p>Also installation instructions... BTW, if you want to see how I
handle page defaults, look for the modules inside
sputnik.node_defaults. If you adjust your <em>blueprint</em>screen.lua and
<em>blueprint</em>layout.lua this way, you can just tell people to copy those
files to sputnik/node_defaults and the pages will appear when
requested. (the same will work for <em>templates, but only if the users
deletes wiki-data/</em>templates</p>
<p>Good !
In a way, it answer to my question on staked storage.
At first I have think that all file were copied at first run.
I missed corresponding lines in versium/smart/repository.
As excuse I would say I only start to grasp how sputnik work.</p>
<p>PS : I would answer to the other mail later, it would take some time to put
it in a mindful shape.
Your right "we are on the same page". I missed some point on versium /
versium.smart</p>
<ul>
<li>pierre</li>
</ul>
<p>Screenshot :</p>
<p>A tar.gz of blueprint (to unpack in rocks directory) :</p>
<p>A modified version of css.lua who add blueprint_css action :</p>
<p>A modified version of wiki.lua who add if<em>notlast helper at get</em>nav_bar
action :</p>
<p>A modified version of <em>templates, this one need to bee put in node</em>defaults,
wiki-data/_templates need to bee removed :</p>
<p>A css template who use blueprint rock module :</p>
<p>A css template who custom rules (not blueprint) :</p>
<p>Two previous need :
- to be drop in node_defaults
- to be seen by seen by rocks/manifest</p>
<p>, ['sputnik.node<em>defaults.</em>blueprint<em>layout']={'sputnik/8.01.01-0'}
, ['sputnik.node</em>defaults.<em>blueprint</em>screen']={'sputnik/8.01.01-0'}
- to be referenced in _config</p>
<p>STYLESHEETS = {
NICE<em>URL.."</em>blueprint<em>screen.css",
NICE</em>URL.."<em>blueprint</em>layout.css",
}</p>
</blockquote>
<p>--
http://sputnik.freewisdom.org/</p>
<p>From pierre.pracht at gmail.com Thu Feb 14 23:11:44 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Thu Feb 14 23:13:58 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com">fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
<28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com>
<fa4efbc00802140057n4135cddcp7aac923f8b46ee7e@mail.gmail.com>
<471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com>
<fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com">055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com</a></p>
<p>Le 14 f?vr. 08 ? 20:19, Yuri Takhteyev a ?crit :</p>
<blockquote>
<p>Great, I'll test this in the evening. For now here are a few <br/>
suggestions:</p>
<ol>
<li>There is a script in my svn repository that you can use to package
rocks: scripts/make<em>a</em>rock.sh</li>
</ol>
</blockquote>
<p>Not found</p>
<blockquote>
<p>Also, I would create your own
repository, which is really a web directory with rocks and a simple
"manifest" file (see http://sputnik.freewisdom.org/rocks/manifest).</p>
</blockquote>
<p>You must explain a bit your work flow.
I have made a new install
- with luarocks for : luafilesystem, lualogging, wsapi ....
- and a checkout of svn trunk as sputnik-trunk</p>
<p>So I have :
/rocks
/sputnik-svn/rocks</p>
<p>In my mind, It was clear that I can tell luarocks to look at both :</p>
<blockquote>
<blockquote>
<p>repositories = {
"http://luarocks.luaforge.net/rocks",
-- "http://sputnik.freewisdom.org/rocks",
"http://www.lua.inf.puc-rio.br/~mascarenhas/rocks",
"/opt/sputnik2/sputnik-svn/rocks"
}
Nope...
I have take e few hours at searching...
ending attrying to look in luarocks code ...</p>
</blockquote>
</blockquote>
<p>In-fine, I take an other way, making symbolic link.
It work, but :
cd /opt/sputnik2/share/lua/5.1
ln -s ln -s ../../../sputnik-svn/rocks/<em>/lua/</em> .</p>
<p>As you say over, serval rocks have a sputink dir
So I think that isn't the way to go.</p>
<blockquote>
<ol>
<li>I would make this into two rocks: "blueprintcss" (everything not
sputnik-specific) and "sputnik-blueprint". Note that
sputnik-blueprint should reproduce sputnik's folder hiearchy:</li>
</ol>
<p>sputnik-blueprint/lua/sputnik/actions/blueprint<em>css.lua
sputnik-blueprint/lua/sputnik/node</em>defaults/<em>blueprint</em>templates.lua
sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>screen.lua
sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>layout.lua</p>
<p>This way those files will be available as if they were a part of
"sputnik" package: require("sputnik.actions.blueprint_css")</p>
</blockquote>
<p>Explain !
Luarocks would handle the (base) path ? See above.</p>
<blockquote>
<p>For now, let's keep this as a "plugin" that could be added on top of
"standard" sputnik: I promised people that the current version would
be feature-frozen until it's tested, documented and properly released.
I want to at least <em>try</em> to keep this promise. :) For the next
iteration we can think if some of it would better be integrated into
the core. This means that let's assume for now that the plugin will
add files and nodes rather than override existing ones. E.g., instead
of replacing _templates, let's add <em>blueprint</em>templates and tell the
user to set DEFAULT<em>TEMPLATE</em>SET in _config.</p>
</blockquote>
<p>Good</p>
<blockquote>
<p>If small changes are necessary for the current sputnik, I'll make
them, but please send them as a patch against SVN if possible.</p>
</blockquote>
<p>I would, but I need my new setup to work !
With "Sputnik on the Rocks" I wasn't able to use CGI</p>
<p>...wsapi/common.lua:177: bad argument #1 to 'match' (string expected, <br/>
got nil)
stack traceback:function 'match'
...wsapi/common.lua:177: in function 'splitext'
...wsapi/common.lua:192: in function <...wsapi/common.lua:182>
(tail call): ?
...bin/wsapi.cgi:16: in function
(tail call): ?function 'xpcall'
...wsapi/common.lua:135: in function 'run_app'
...wsapi/common.lua:159: in function 'run'
...wsapi/cgi.lua:16: in function 'run'
...bin/wsapi.cgi:24: in main chunk</p>
<p>May be an explanation :
I haven't : bin/wsapi
I have : bin/wsapi.cgi</p>
<p>Did I get the good version of wsapi ?</p>
<h1>bin/luarocks list</h1>
<p>wsapi</p>
<pre><code>cvs-1 (installed) - /opt/sputnik2/rocks/
</code></pre>
<p>In my previous install I take the xavante way.
But If I make some module, I need to use CGI. (installed thttpd)</p>
<blockquote>
<ol>
<li>You should email the Kepler list about the generic blueprint
library. I think it's an interesting idea and it's may be useful for
Lua-based web stuff beyond Sputnik. And we might get good
suggestions.</li>
</ol>
</blockquote>
<p>I need first to put it in good shape (1 week min)
Actual code is a mess, juste a proto to show that it would work.
But to work proprely I need to make a new setup with SCM and CGI.</p>
<blockquote>
<ol>
<li>If you have a google account, I can add you to the sputnik-wiki
project (http://code.google.com/p/sputnik-wiki/) so that you could
check the files into SVN.</li>
</ol>
</blockquote>
<p>Yes this email.
If needed in the mean time I can keep change in a git copy.</p>
<blockquote>
<ol>
<li>Any hope for documentation? One possibility would be to start a
page at http://sputnik.freewisdom.org/en/BlueprintCSS. Don't worry
about English grammar - we'll fix it up later.</li>
</ol>
</blockquote>
<p>I will, but maybe I will make a custom form for common parameters <br/>
before.</p>
<ul>
<li>pierre</li>
</ul>
<p>From yuri at sims.berkeley.edu Fri Feb 15 01:03:29 2008
From: yuri at sims.berkeley.edu (Yuri Takhteyev)
Date: Fri Feb 15 01:05:21 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com">055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
<28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com>
<fa4efbc00802140057n4135cddcp7aac923f8b46ee7e@mail.gmail.com>
<471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com>
<fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com>
<055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:fa4efbc00802141903w6432fcboad55084519ac4b37@mail.gmail.com">fa4efbc00802141903w6432fcboad55084519ac4b37@mail.gmail.com</a></p>
<blockquote>
<p> > 1. There is a script in my svn repository that you can use to package
> rocks: scripts/make<em>a</em>rock.sh</p>
<p> Not found</p>
</blockquote>
<p>Oops, I never actually committed that directory. It's committed now.</p>
<blockquote>
<p> You must explain a bit your work flow.</p>
</blockquote>
<p>At this point I keep all of my code in "rocks" separated by which
"rock" it will be released with.</p>
<p>I start off by doing a fresh install, as per instructions on the web
page. I install everything into some directory inside ~/tmp/. E.g.,
~/tmp/sputnik-7/. (I often have a few versions running at the same
time.) If I want to make sure that a particular rock is up to date
relative to SVN then I go through the steps that I just described on
the wiki:</p>
<p>http://sputnik.freewisdom.org/en/Installing<em>from</em>SVN</p>
<blockquote>
<p> >> "/opt/sputnik2/sputnik-svn/rocks"</p>
</blockquote>
<p>"file:///opt/sputnik2/sputnik-svn/rocks"</p>
<blockquote>
<p> > sputnik-blueprint/lua/sputnik/actions/blueprint_css.lua
> sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint_templates.lua
> sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>screen.lua
> sputnik-blueprint/lua/sputnik/node<em>defaults/</em>blueprint<em>css</em>layout.lua
>
> This way those files will be available as if they were a part of
> "sputnik" package: require("sputnik.actions.blueprint_css")</p>
<p> Explain !
Luarocks would handle the (base) path ? See above.</p>
</blockquote>
<p>LuaRocks just adds each rock to your search path. So, when you say
require("sputnik.actions.blueprint_css"), Lua will go through every
rock looking for
<rock_name>/<version>/lua/sputnik/actions/blueprint_css.lua and will
use the first match it will find. (It's a bit of a simplification
because LuaRocks may filter the search by <version>.)</p>
<blockquote>
<p> I would, but I need my new setup to work !
With "Sputnik on the Rocks" I wasn't able to use CGI</p>
</blockquote>
<p>Let me look into this. It's possible that wsapi rock changed.</p>
<blockquote>
<p> Did I get the good version of wsapi ?
# bin/luarocks list
wsapi</p>
<pre><code>cvs-1 (installed) - /opt/sputnik2/rocks/
</code></pre>
</blockquote>
<p>Well, you are getting it from CVS, so it might change from one day to another.</p>
<blockquote>
<p> I need first to put it in good shape (1 week min)
Actual code is a mess, juste a proto to show that it would work.
But to work proprely I need to make a new setup with SCM and CGI.</p>
</blockquote>
<p>Yeah, whenever you feel it's ready for that.</p>
<blockquote>
<p> > 4. If you have a google account, I can add you to the sputnik-wiki
> project (http://code.google.com/p/sputnik-wiki/) so that you could
> check the files into SVN.</p>
<p> Yes this email.</p>
</blockquote>
<p>Ok, I'll add you.</p>
<blockquote>
<p> I will, but maybe I will make a custom form for common parameters
before.</p>
</blockquote>
<p>Deal.</p>
<ul>
<li>yuri</li>
</ul>
<p>--
http://sputnik.freewisdom.org/</p>
<p>From pierre.pracht at gmail.com Fri Feb 15 12:40:21 2008
From: pierre.pracht at gmail.com (pierre pracht)
Date: Fri Feb 15 12:42:19 2008
Subject: [Sputnik-list] blueprint
In-Reply-To: <a href="mailto:fa4efbc00802141903w6432fcboad55084519ac4b37@mail.gmail.com">fa4efbc00802141903w6432fcboad55084519ac4b37@mail.gmail.com</a>
References: <a href="mailto:fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com">fa4efbc00802062108s731f85ep852f99755e3f9ca2@mail.gmail.com</a></p>
<pre><code><48031A48-2491-4246-A332-A994C1A9865C@gmail.com>
<fa4efbc00802110153w74695a03t54613d9ac2f7d268@mail.gmail.com>
<BAF5DA28-56F2-4D73-A10A-81A6C98CA19C@gmail.com>
<fa4efbc00802120235w2cb1c01el6f0ade0bcf1a519d@mail.gmail.com>
<28D0F321-0991-4C7B-AF83-C146EC209C3F@gmail.com>
<fa4efbc00802140057n4135cddcp7aac923f8b46ee7e@mail.gmail.com>
<471A2A47-E738-4E63-B2D2-440696F2BFA9@gmail.com>
<fa4efbc00802141119q6bd2334ejbec5e7ea9e50cdf2@mail.gmail.com>
<055F8657-CBA7-4559-8E96-4ACA532960A0@gmail.com>
<fa4efbc00802141903w6432fcboad55084519ac4b37@mail.gmail.com>
</code></pre>
<p>Message-ID: <a href="mailto:2A1CB2C1-5974-46A2-9979-CDB25997936E@gmail.com">2A1CB2C1-5974-46A2-9979-CDB25997936E@gmail.com</a></p>
<p>Le 15 f?vr. 08 ? 04:03, Yuri Takhteyev a ?crit :</p>
<blockquote>
<blockquote>
<blockquote>
<p>You must explain a bit your work flow.</p>
</blockquote>
</blockquote>
<p>At this point I keep all of my code in "rocks" separated by which
"rock" it will be released with.</p>
</blockquote>
<p>So trunck/rocks contain repertory ready to be packaged as rocks
It's neither :
- rocks ready to install
- modules ready to be imported by lua</p>
<blockquote>
<p>I often have a few versions running at the same
time.) If I want to make sure that a particular rock is up to date
relative to SVN then I go through the steps that I just described on
the wiki:</p>
<p>http://sputnik.freewisdom.org/en/Installing<em>from</em>SVN</p>
</blockquote>
<p>To see If have understood :
- You edit in trunk/rocks
- To test you push (copy) edited version in share/lua/5.1/
- To keep a trace of change you commit to svn
- At a point you run a script</p>
<pre><code> to bundle a repertory of trunk/rocks as a rocks
</code></pre>
<blockquote>
<blockquote>
<blockquote>
<blockquote>
<p> "/opt/sputnik2/sputnik-svn/rocks"</p>
</blockquote>
</blockquote>
</blockquote>
<p>"file:///opt/sputnik2/sputnik-svn/rocks"</p>
</blockquote>
<p>Can't work as trunck/rocks isn't a rocks repository ! wrong ?</p>
<blockquote>
<blockquote>
<p>Luarocks would handle the (base) path ? See above.</p>
</blockquote>
<p>LuaRocks just adds each rock to your search path. So, when you say
require("sputnik.actions.blueprint_css"), Lua will go through every
rock looking for
<rock_name>/<version>/lua/sputnik/actions/blueprint_css.lua and will
use the first match it will find. (It's a bit of a simplification
because LuaRocks may filter the search by <version>.)</p>
</blockquote>
<p>I have take this functionality of Luarocks for an other workflow :
- make a regular install of lua , rocks , sputnik ...
- checkout svn trunk/rocks to sputnik-rocks
- make symbolic link : rocks/sputnik/cvs-1 -> ../../sputnik-rocks/
sputnik</p>
<pre><code>Rq: need to change
sputnik-rocks/sputnik/rockspec in
sputnik-rocks/sputnik/sputnik-cvs-1.rockspec
</code></pre>
<p> - run bin/luarocks-admin make_manifest</p>
<p>By this way you can have many install of lua/rocks with many working <br/>
copy of svn. You simply build symbolic links between each.</p>
<p>I don't know what are recommendation regarding SCM / LuaRocks, but :</p>
<p>If you change in the repository rockspec in $ROCK-cvs-1.rockspec you <br/>
have just a line to change in your script.</p>
<p>An other way(not tested) is to simply checkout svn trunck/rocks/$ROCK <br/>
to local rocks/$ROCK/cvs-1
So if you change svn layout with cvs-1 repertories, it would make it <br/>
more explicit.
I the same time, it would ease symbolic link creation.</p>
<p>I don't know if LuaRocks have some policy / docs / helper for this, <br/>
but It would have been very helpful for me. I have spend 2 day just to <br/>
get a correct setup.</p>
<p>Need to take a break :(</p>
<blockquote>
<blockquote>
<p>I would, but I need my new setup to work !
With "Sputnik on the Rocks" I wasn't able to use CGI</p>
</blockquote>
<p>Let me look into this. It's possible that wsapi rock changed.</p>
</blockquote>
<p>I took your last install script, it work fine.
I get xavante so no extra / config
your xavante work with CGI so no server restart
Rq: first instal was done with xavante/wsapi (painful !)</p>
<ul>
<li>pierre</li>
</ul>
<p>From petite.abeille at gmail.com Thu Feb 21 21:19:59 2008
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu Feb 21 21:22:15 2008
Subject: [Sputnik-list] blueprint
Message-ID: <a href="mailto:D158545E-FC64-4BFB-9053-865CDD92328C@gmail">D158545E-FC64-4BFB-9053-865CDD92328C@gmail</a></p>
<p>On Feb 7, 2008, at 3:08 AM, Yuri Takhteyev wrote:</p>
<blockquote>
<p>Nanoki supports search, but only for exact match in page titles.</p>
</blockquote>
<p>Not quiet... while Nanoki do indeed search the titles only, such <br/>
search is, hmm, "fuzzy":</p>
<p>For example, searching for 'mac':</p>
<p>http://svr225.stepx.com:3388/search?q=mac</p>
<p>Returns things such as:</p>
<p>Automated Teller Machine
Barbary Macaque
Macintosh
Niccolo Machiavelli</p>
<p>In essence, it's a trie search:</p>
<p>http://dev.alt.textdrive.com/browser/HTTP/WikiSearch.lua
http://dev.alt.textdrive.com/browser/HTTP/Trie.lua</p>
<p>Cheers,</p>
<p>PA.</p>
