[Grok-dev] Re: Portlets (and maybe other skinning).

[Lennart Regebro]

On 3/21/07, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> > Eh, but if you don't get to choose it, which ClassOrInterface
> > should it be?
>
> class Mammoth(grok.Model):
>      pass
>
> class Index(grok.View):
>      grok.context(Mammoth) # this view is for mammoth objects (which
> is assumed)

Yeah, that's what I mean, you get to choose it. :-) For which objects
should this viewlet appear. I register it with None, now, because that
makes it appear for everything which means that it worked in the proof
of concept.

> > Well, it is possible if we do one separate request per viewlet. But I
> > don't like that.
>
> Deliverance doesn't work that way, at least it doesn't have to use
> separate requests.

Then I don't understand how to do that.

> > And I don't like make Deliverance required for Grok.
>
> Who says it has to be required.

I don't understand why I have such troubles in communicating what I'm
trying to say. It's very frustrating. I'll try again:

Separation of design and content is the first and most basic part of
any web application framework. For clarifications, lets talk about
themes, which includes design and things as breadcrumbs, navigation
and similar. So what we really want to do is separate themes from
content.

There are several possible ways we can achieve this with Grok. One is
to use a master macro. Deliverance can do it, at least for pure
design, but themes are harder. Another way is what I did as a proof of
concept in megrok.viewlets, which imposes a theme onto the HTML
returned by the object. There may be more ways, of which I am not
aware.

These possible ways are not completely interchangeable. Take the
example of setting the <title>. Using a master macro is probably the
easiest, but it requires all templates to include the master macro,
and you set the title by filling a title-slot. Templates that do not
use a master macro will not get any design. The megrok.viewlet way
will ignore anything you put in the head-part of a web page, so the
title needs to be set some other way (by providing an adapter to an
ITitle interface, for example). With Deliverance the rules will pick
the <title> tag up and put it into the design-template, so there you
set it by adding a <title>-tag.

So, these ways are not interchangeable. A Template that is designed to
be used for Deliverance will not get a title when used with the
megrok.viewlet technique. A template with a megrok.viewlet will not
get a title when used with a master-template, and so on.

Therefore, if Martijn makes Grokstar to be used with Deliverance, and
somebody else makes a Wiki with using master templates, and I make a
todo application using megrok.viewlet, THESE APPLICATION WILL NOT WORK
TOGETHER.

Somethings will work together. For example, Deliverance can be used
with both other techniques. However, it also makes those Techniques
partly irrelevant. megrok.viewlet can be used with master macros. But
one of them will be pointless. You can use all three. But at least one
of them will in that case do nothing. But of we decide on the
deliverance way of doing it, then for all intents an purposes,
Deliverance will be a requirement.

Hence, we really should decide on a way of doing this. If we don't
Grok will be just another intellectual excercise in how to make an
application framework that is theoretically excellent, but nobody will
actually use.

And that would really be a shame.

> Sorry, but that's bullshit.

It is pretty much as far away from Bullshit as is possible. It is in
fact the last issue that needs to be addressed before Grok is a
practically useful framework, and a darn good one at that. It would be
really weird to almost make the best web application framework in the
world, but just almost.

> Obviously Grok should come with some manner of creating common themes
> for application (and it already does, ZPT macros)

Grokstar does not use ZPT macros. If it did we would not be having
this conversation, as in fact my aim with all this is to be able to
put up a blog using Grokstar. And currently I can't, because doing
that with ZPT macros would require me to change every single Grokstar
template. Now I can do that, but I refure to do that every time
Grokstar changes, so that means I'll do that, AND CHECK IT IN. And
that means that Grokstar will use master macros for the theming of
it's templates. And for everything else to then be useable with
Grokstar, everything else must *also* use master macros.

> I simply object to the rush.

Well, how long do you want to wait? If we decide on this, Grok is
useful. Until we have decided, Grok is not useful. Why should we wait
with making Grok a useful tool, if we can make it useful pretty soon?
Is this going to be "The wait for Zope 3, part 2", and we have to wait
forever until some people who want to take years to do things The
Right Way decide which way is right?

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64