[Zope3-dev] Re: Siesia: A new UI for Zope 3

[Michael Zeltner]

Sorry for responding so late, i had a hard day yesterday and slept way 
too long and i'm still not on top yet.

Am 05.05.2004 um 14:28 schrieb Max M:
> The parts I understand the best are the skin documentation section. 
> Which remainds a lot of Plone 2.0

Indeed, it's inspired by our work there, but because it's "just" 
inspired by the concepts, we've got a lot cleaner markup and css (to 
quote joe: we scrubbed everything with an industrial carwash.) - it's 
actually written from scratch.

> The problem is that you are comming from another world. Your concepts 
> are alien, and not clearly explained. There is too much implied 
> knowledge in there.

Yes... but we try to clarify everything now :)

> Ok. I can see that it is easier to follow, if you don't have to know a 
> skin order, and if all skins are not global. But you are talking about 
> A Filesystem Directory View with an invisible layer. This implies that 
> major skin development is done through the browser. Personally I never 
> develop through the browser. The first thing I do when starting a 
> Plone site, is to create a filesystem based skin. So this approach is 
> important. It seems like that would be hard with your 2 layer 
> approach.

Sorry i haven't been too clear about the FS-skin development, i don't 
use the ZMI for skin development very often myself. When this is all 
reality, then there *has* to be the ability to inherit (with a python 
install script) an FS-skin for a "new" FS-skin, because ...

> Perhaps the subskin you are talking about does that, but it's hard to 
> say from the docs.

... a subskin is just for small changes, and not meant to be used for 
the whole Zope instance, just for subsections.

> Pagelets system
> ---------------
>
> Ok. This could be a good idea. As I understand it, you want to take 
> the main_template from Plone, and turn it into a tool, where the 
> elements from the main_template are made programmatically.

Not exactly, to keep flexibility the templates should call it.

> As it is right now, the main_template is just one big placeholder for 
> slots. So it seems like a good fit. You are in a world of hurt, 
> whenever the main template changes. A pagelet system could help there.

Exactly :)

> Metal & Tales additions
> -----------------------
>
> I don't understand the issues here.

Okay, the given attribute condition example was quite bad, i'll try 
again:

We have a script that returs 5 values which has in combination with a 
few other ones, that were put out above, two values that are not 
needed. To keep the markup as semantic as possible we don't display it, 
with the attribute condition. It's not mandatory but a *nice to have* 
feature, that'd make a lot of perfectionists happy.

The global slot is really important, if someone wants to use the 
pagelet system in a clean way. I hope that'll explain everything 
better:

I'm viewing a document, a template gets accessed, from which i need to 
call a macro from a different template, that covers all main structure 
etc. (In Plones case that would be document_view and the master macro 
from main_template) Now i'm able to fill slots in the macro from the 
structure related template.

So: view-document.pt uses the macro root from root.pt (like master and 
main_template) and is able to fill every slot defined inside the macro 
root. But because of the pagelet system, and our wish to do everything 
as clean as possible, we want to fill slots that are somewhere else - 
for example, a css slot in head-styles.pt that gets invoked via the 
pagelet system, or the most extreme example: i need to fill the content 
into a template/macro that is about 3 templates away from my current 
position.

And currently slots don't get passed over.

> Skin documentation
> ------------------
>
> That all seem very plone like, which isn't too bad. It's a sane way to 
> do it.

See the inspired part from above ;)

> miscs
> -----
>
> I miss a discussion/section on how to make the skin cacheable. But off 
> course that is hard to do without an example.
>
> It seems to me that the design of Plone makes it difficult to cache 
> efficiently. I believe that easy cachability would be a major plus.

Thats something for Joe, rather than for me. He currently has some 
problems sending mails, but he'll answer asap. You can probably catch 
him (Arnia) earlier on IRC.

Regards, Michael
-- 
Michael Zeltner
Netalley Networks LLP
http://www.netalleynetworks.com/