Added two new cookbook recipes: close down site, use different template for display
Daniel Nouri
recipes for developers which cover two things that developers will
often want to do with their Kotti sites:
- Close it down for anonymous users (set the site's global ACL):
http://readthedocs.org/docs/kotti/en/latest/cookbook/close-for-anonymous.html
- Use a different template for the front-page (or any individual page
really): http://readthedocs.org/docs/kotti/en/latest/cookbook/frontpage-different-template.html
Setting the template used through the web (aka Plone's "Display"
dropdown), and not in code (as in the recipe), is definitely something
we want to add in the future.
Enjoy
Daniel
Christian Neumann
Am Tue, 28 Feb 2012 14:02:32 +0100
schrieb Daniel Nouri <daniel...@gmail.com>:
> Setting the template used through the web (aka Plone's "Display"
> dropdown), and not in code (as in the recipe), is definitely something
> we want to add in the future.
maybe this could be combined with the possibility to set slot renderes
through the web. These settings could be inherited down the node tree.
There could also be away to define custom slots per template (or add
generic slots linke RenderInnerSlot1 ...).
Basically I'm looking for a way to embed content into the
representation of some basic node without having to write a new view
and template. Say I have a document node and want to embed a list of
the newest blog entries into the content. I'm not familiar with Plone,
so I don't know how you would do it there.
In Wikis like MoinMoin, one could simply write a macro
<<LatestBlogEntries()>> that could be inserted (by the user) anywhere
you want. This concept of macros is really powerful and can solve many
problems (but as its implemented in MoinMoin not that user friendly).
In Django CMS (as far as I remember), a page consists of different
content types which can be freely arranged. So one could combine a
"WYSIWYGContent", "BlogEntryList", and again a "WYSIWGYContent". While
this is IMHO not as elegant as macros, it also is very powerful.
How do you solve such problems in Plone or Kotti? Are there similar
concepts?
Best,
Christian
Daniel Nouri
On Tue, Feb 28, 2012 at 2:39 PM, Christian Neumann
<chri...@datenkarussell.de> wrote:
> Am Tue, 28 Feb 2012 14:02:32 +0100
> schrieb Daniel Nouri <daniel...@gmail.com>:
>
>> Setting the template used through the web (aka Plone's "Display"
>> dropdown), and not in code (as in the recipe), is definitely something
>> we want to add in the future.
>
> maybe this could be combined with the possibility to set slot renderes
> through the web. These settings could be inherited down the node tree.
> There could also be away to define custom slots per template (or add
> generic slots linke RenderInnerSlot1 ...).
>
> Basically I'm looking for a way to embed content into the
> representation of some basic node without having to write a new view
> and template. Say I have a document node and want to embed a list of
> the newest blog entries into the content. I'm not familiar with Plone,
> so I don't know how you would do it there.
Hmm, good question.
Plone doesn't have anything like this, though a tool called 'deco' is
in development; it allows you to add, and rearrange content fields on
the page. It's rather complex.
So with your "list of newest blog entries inside content" problem, the
Plone approach would be indeed to add a separate 'blog template' that
users would then select for their blog folder. Or a separate Blog
content type that comes with this view as its default (more user
friendly). The content type could then have extra fields, maybe an
image, another piece of text, and the template would include them,
along with the list of blog entries (in a format that you'd expect
from a blog). Requires a bit of programming, but allows to solve very
custom requirements. This approach also creates a nice separation
between layout and content.
> In Wikis like MoinMoin, one could simply write a macro
> <<LatestBlogEntries()>> that could be inserted (by the user) anywhere
> you want. This concept of macros is really powerful and can solve many
> problems (but as its implemented in MoinMoin not that user friendly).
I believe that Silva, another Zope-based CMS, has had macros like this
for a long time. Might be interesting to look at them for
inspiration. I think they have a little selection UI in place for
their WYSIWYG editor.
The idea of using macros sounds good to me. We should look at a way
to make macros and slots work the same way. Because then we could
more elegantly solve the problem of also adding slot renderers through
the web. Should macros be able to take arguments, or is that too
much? I know Plone's portlets are configurable, e.g. there's a static
text portlet that you can fill with text and display.
If we need arguments, we'll need to revisit how slot renderers use
arguments (currently through settings), and then hopefully macros and
slot renderers can be the same thing.
> In Django CMS (as far as I remember), a page consists of different
> content types which can be freely arranged. So one could combine a
> "WYSIWYGContent", "BlogEntryList", and again a "WYSIWGYContent". While
> this is IMHO not as elegant as macros, it also is very powerful.
Yeah, I think this is maybe what 'deco' wants to be. I prefer the
macros approach.
Greetings
Daniel
Daniel Nouri
> On Tue, Feb 28, 2012 at 2:39 PM, Christian Neumann
>> through the web. These settings could be inherited down the node tree.
>> There could also be away to define custom slots per template (or add
>> generic slots linke RenderInnerSlot1 ...).
>
>
> If we need arguments, we'll need to revisit how slot renderers use
> arguments (currently through settings), and then hopefully macros and
> slot renderers can be the same thing.
This should be easy enough if we process settings on the file system
in one function, and expect kw arguments and do real work in another,
like this:
def render_profile_widget_from_settings(context, request):
# get persistent settings
kw = get_variables_from_settings('kotti_twitter.profile_widget.')
return render_profile_widget(context, request, **kw)
def render_profile_widget(context, request, user='pylons', loop=False, ...):
# do real work ...
return render(...)
I guess we could agree that the keyword arguments should be presented
by the slot renderer as a colander schema. This way we could
automatically render a nice user interface, which would store the
settings into Node.annotations, and then we'd add a persistent slot
renderer for each slot that takes care of these persistent settings.
I think this should be at least initially developed as an add-on.
Existing add-ons with slot renderers could then add support for this
package.
Daniel
Christian Neumann
I think that arguments are really needed and that it's a good idea to
make macros and slot renderes basically the same.
Am Tue, 28 Feb 2012 19:43:25 +0100
schrieb Daniel Nouri <daniel...@gmail.com>:
> I guess we could agree that the keyword arguments should be presented
> by the slot renderer as a colander schema. This way we could
> automatically render a nice user interface, which would store the
> settings into Node.annotations, and then we'd add a persistent slot
> renderer for each slot that takes care of these persistent settings.
I'm not quite sure if I got your idea. Something like this?
- Macros are implemented as function who receive the current context,
request, additional keyword arguments and return rendered content.
- Slot renderers call macros to render content for a specific slot.
- Slot renderers can be configured through the settings, i.e. keyword
arguments are passed from the settings to the macro.
- Slot renderers can be registered for some specific node through the
web, where the settings are stored in node.annotations and set
by the user through an interface generated with information out of a
colander schema.
- Macros can be called from text content through some syntax like
<<Macro(foo=True, bar=False)>> (or something which better fits into
HTML content). The WYSIWYG-Editor may ease insertion of macro
calls (also using the colander schema).
> I think this should be at least initially developed as an add-on.
Willing to contribute!
Best,
Christian
Daniel Nouri
<chri...@datenkarussell.de> wrote:
> Hey Daniel,
>
> I think that arguments are really needed and that it's a good idea to
> make macros and slot renderes basically the same.
>
> Am Tue, 28 Feb 2012 19:43:25 +0100
> schrieb Daniel Nouri <daniel...@gmail.com>:
>> I guess we could agree that the keyword arguments should be presented
>> by the slot renderer as a colander schema. This way we could
>> automatically render a nice user interface, which would store the
>> settings into Node.annotations, and then we'd add a persistent slot
>> renderer for each slot that takes care of these persistent settings.
>
> I'm not quite sure if I got your idea. Something like this?
>
> - Macros are implemented as function who receive the current context,
> request, additional keyword arguments and return rendered content.
Yes.
> - Slot renderers call macros to render content for a specific slot.
> - Slot renderers can be configured through the settings, i.e. keyword
> arguments are passed from the settings to the macro.
Yes.
> - Slot renderers can be registered for some specific node through the
> web, where the settings are stored in node.annotations and set
> by the user through an interface generated with information out of a
> colander schema.
Yes.
I guess that slot renderers might come in two flavours where it makes
sense. One where settings are gathered through get_settings() (i.e.
the ini file), another where settings are provided as keyword
arguments -- where the former could simply call the latter after it
retrieved the settings. (We could call the latter macros, or whatever
we want.)
We're anyway flexible, if you find a more elegant way of doing it,
let's discuss. I'm also cool if we want to rename 'slot renderers' to
'portlets' or something...
Another question that still needs to be answered is how to map macro
names to functions. We'd also have to be able to register these slot
renderers that one can add through the web. Maybe we could use a
pattern similar to 'kotti.available_content_types' for that.
And yet another thing is there's currently no support for third party
packages to add stuff into the editor bar.
> - Macros can be called from text content through some syntax like
> <<Macro(foo=True, bar=False)>> (or something which better fits into
> HTML content). The WYSIWYG-Editor may ease insertion of macro
> calls (also using the colander schema).
>
>> I think this should be at least initially developed as an add-on.
>
> Willing to contribute!
Awesome! Keep us posted.
Daniel