Developing themes with collective.skinny

[Tim Knapp]

Hi Daniel et al,

I've recently been developing a Plone theme with collective.skinny[1].
On the package page on pypi it says:
<quote>
The better way is to use it as a library and extend it with your own
package. When doing so, you'll probably want to start out by subclassing
and overriding through ZCML the main view, which lives in main.Main.
Look at the configure.zcml file for pointers.
</quote>

I did do this but the problem is that the modules refer to the packages
local 'templates' dir and therefore I found that you need to pretty much
copy across all the code in the collective.skinny package for it to
work. I've had other issues too, when subclassing the modules and I've
found copying and pasting the code across has fixed these too. What is
the correct way to subclass the collective.skinny package?

I also created my own IPublicLayer interface in my package as I'm
planning to have 3 collective.skinny-based packages in the same zope
instance and thought this was the only way for this to work - is that
right?

Thanks,
Tim

[1] http://pypi.python.org/pypi/collective.skinny


_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Daniel Nouri]

Hi Tim!

Tim Knapp writes:

> I've recently been developing a Plone theme with collective.skinny[1].
> On the package page on pypi it says:
> <quote>
> The better way is to use it as a library and extend it with your own
> package. When doing so, you'll probably want to start out by subclassing
> and overriding through ZCML the main view, which lives in main.Main.
> Look at the configure.zcml file for pointers.
> </quote>
>
> I did do this but the problem is that the modules refer to the packages
> local 'templates' dir and therefore I found that you need to pretty much
> copy across all the code in the collective.skinny package for it to
> work. I've had other issues too, when subclassing the modules and I've
> found copying and pasting the code across has fixed these too. What is
> the correct way to subclass the collective.skinny package?

The "use as a library" story is really unfinished.  I should remove that
paragraph until I get to put some work into this to make it work smooth,
and usable from a ZopeSkel template.  Sorry for misleading you.  fRiSi
ran into the same problem recently.

In the meantime, I suggest you use the whole collective.skinny as a
template.  Not so much code after all.

> I also created my own IPublicLayer interface in my package as I'm
> planning to have 3 collective.skinny-based packages in the same zope
> instance and thought this was the only way for this to work - is that
> right?

Yes, you'll need three different interfaces.  I realize that this
contradicts also the paragraph that you quote before: "... overriding
through ZCML the main view...".


> [1] http://pypi.python.org/pypi/collective.skinny


--
http://danielnouri.org


_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Tim Knapp]

Further questions re. developing themes with collective.skinny:
It seems to me that you can't override cmf templates via
collective.skinny?

I've had to do quite a bit of workarounds to get simple things like
'search', 'navigation', 'sitemap' going. I think in the main things like
this should really work OOTB otherwise you end up fighting against the
'framework' too much :(

Thanks,
Tim

On Wed, 2009-04-22 at 06:56 +1200, Tim Knapp wrote:

> Hi Daniel et al,
>
> I've recently been developing a Plone theme with collective.skinny[1].
> On the package page on pypi it says:
> <quote>
> The better way is to use it as a library and extend it with your own
> package. When doing so, you'll probably want to start out by subclassing
> and overriding through ZCML the main view, which lives in main.Main.
> Look at the configure.zcml file for pointers.
> </quote>
>
> I did do this but the problem is that the modules refer to the packages
> local 'templates' dir and therefore I found that you need to pretty much
> copy across all the code in the collective.skinny package for it to
> work. I've had other issues too, when subclassing the modules and I've
> found copying and pasting the code across has fixed these too. What is
> the correct way to subclass the collective.skinny package?
>
> I also created my own IPublicLayer interface in my package as I'm
> planning to have 3 collective.skinny-based packages in the same zope
> instance and thought this was the only way for this to work - is that
> right?
>
> Thanks,
> Tim
>
> [1] http://pypi.python.org/pypi/collective.skinny
>
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Daniel Nouri]

We talked a bit about this on IRC.  Let me answer to this thread, too.

On Mon, Apr 27, 2009 at 10:38 AM, Tim Knapp <[hidden email]> wrote:
> Further questions re. developing themes with collective.skinny:
> It seems to me that you can't override cmf templates via
> collective.skinny?
>
> I've had to do quite a bit of workarounds to get simple things like
> 'search', 'navigation', 'sitemap' going. I think in the main things like
> this should really work OOTB otherwise you end up fighting against the
> 'framework' too much :(

You should be able to register views and call them just fine.  For
your view class, you'll want to inherit from the Main class and set a
page template as the "render_content" attribute.  Therein, you can
render whatever template you want to see in the "content area" of your
skin, like a search widget.

The way I use Skinny is for skins that don't have anything in common
with the Plone interface.  The Plone UI is what we call the editing
interface.  That is, we have a custom public view for all our content
types, and we also implement search by ourselves -- just because it
works very different to the search in the editing interface.  Despite
that, there's nothing that keeps you from using macros out of Plone
templates in Skinny -- but maybe they'll need a bit more context; like
provided by @@plone's globalize.  You can also use Plone's full API,
like the queryCatalog script.

fRiSi and I want to split collective.skinny into a library package and
an example package, the latter will have example implementations for
the most common things like search and sitemap, as well as the demo
skin that's now in Skinny itself.

Daniel

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Tim Knapp]

Hi Daniel,

Thanks a lot for the clarification on this. I actually worked out the
fact that I can use any 'stuff' in the acquisition chain after I sent
this email (bit dense I guess ;). I had also gathered things need to go
through the 'main.Main' view class but thanks a lot for the
clarification on the 'render_content' attribute, very helpful. (As
discussed on #plone) I've developed a couple of fairly involved
collective.skinny themes now and will post a message to the mailing
list/my blog when they're live as well as my 'war stories' :)


Here's some interesting figures from ab for a collective.skinny theme VS
a standard plone site:

Standard Plone:
Requests per second:    3.27 [#/sec] (mean)

collective.skinny theme (with some heavy customisation):
Requests per second:    7.46 [#/sec] (mean)

Another collective.skinny theme (simple brochureware site):
Requests per second:    12.23 [#/sec] (mean)


Thanks again for an excellent package!

-Tim

On Mon, 2009-05-04 at 21:28 +0100, Daniel Nouri wrote:

> We talked a bit about this on IRC.  Let me answer to this thread, too.
>
> On Mon, Apr 27, 2009 at 10:38 AM, Tim Knapp <[hidden email]> wrote:
> > Further questions re. developing themes with collective.skinny:
> > It seems to me that you can't override cmf templates via
> > collective.skinny?
> >
> > I've had to do quite a bit of workarounds to get simple things like
> > 'search', 'navigation', 'sitemap' going. I think in the main things like
> > this should really work OOTB otherwise you end up fighting against the
> > 'framework' too much :(
>
> You should be able to register views and call them just fine.  For
> your view class, you'll want to inherit from the Main class and set a
> page template as the "render_content" attribute.  Therein, you can
> render whatever template you want to see in the "content area" of your
> skin, like a search widget.
>
> The way I use Skinny is for skins that don't have anything in common
> with the Plone interface.  The Plone UI is what we call the editing
> interface.  That is, we have a custom public view for all our content
> types, and we also implement search by ourselves -- just because it
> works very different to the search in the editing interface.  Despite
> that, there's nothing that keeps you from using macros out of Plone
> templates in Skinny -- but maybe they'll need a bit more context; like
> provided by @@plone's globalize.  You can also use Plone's full API,
> like the queryCatalog script.
>
> fRiSi and I want to split collective.skinny into a library package and
> an example package, the latter will have example implementations for
> the most common things like search and sitemap, as well as the demo
> skin that's now in Skinny itself.
>
> Daniel

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Espen Moe-Nilssen]

Some javascript/style in this post has been disabled (why?)

I havent tried this product yet, so maybe this is a stupid question:

1) A page that uses collective.skinny shows/loads much faster than a "normal page"

2) If 1) is the case, is there any way to "port" an existing theme or is it "buildt from bottom up"?

Den 4. mai. 2009 kl. 23.57 skrev Tim Knapp:

Hi Daniel,

Thanks a lot for the clarification on this. I actually worked out the

fact that I can use any 'stuff' in the acquisition chain after I sent

this email (bit dense I guess ;). I had also gathered things need to go

through the 'main.Main' view class but thanks a lot for the

clarification on the 'render_content' attribute, very helpful. (As

discussed on #plone) I've developed a couple of fairly involved

collective.skinny themes now and will post a message to the mailing

list/my blog when they're live as well as my 'war stories' :)

Here's some interesting figures from ab for a collective.skinny theme VS

a standard plone site:

Standard Plone:

Requests per second:    3.27 [#/sec] (mean)

collective.skinny theme (with some heavy customisation):

Requests per second:    7.46 [#/sec] (mean)

Another collective.skinny theme (simple brochureware site):

Requests per second:    12.23 [#/sec] (mean)

Thanks again for an excellent package!

-Tim

On Mon, 2009-05-04 at 21:28 +0100, Daniel Nouri wrote:

We talked a bit about this on IRC.  Let me answer to this thread, too.

On Mon, Apr 27, 2009 at 10:38 AM, Tim Knapp <[hidden email]> wrote:

Further questions re. developing themes with collective.skinny:

It seems to me that you can't override cmf templates via

collective.skinny?

I've had to do quite a bit of workarounds to get simple things like

'search', 'navigation', 'sitemap' going. I think in the main things like

this should really work OOTB otherwise you end up fighting against the

'framework' too much :(

You should be able to register views and call them just fine.  For

your view class, you'll want to inherit from the Main class and set a

page template as the "render_content" attribute.  Therein, you can

render whatever template you want to see in the "content area" of your

skin, like a search widget.

The way I use Skinny is for skins that don't have anything in common

with the Plone interface.  The Plone UI is what we call the editing

interface.  That is, we have a custom public view for all our content

types, and we also implement search by ourselves -- just because it

works very different to the search in the editing interface.  Despite

that, there's nothing that keeps you from using macros out of Plone

templates in Skinny -- but maybe they'll need a bit more context; like

provided by @@plone's globalize.  You can also use Plone's full API,

like the queryCatalog script.

fRiSi and I want to split collective.skinny into a library package and

an example package, the latter will have example implementations for

the most common things like search and sitemap, as well as the demo

skin that's now in Skinny itself.

Daniel

_______________________________________________

UI mailing list

[hidden email]

http://lists.plone.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Tim Knapp]

On Tue, 2009-05-05 at 09:23 +0200, Espen Moe-Nilssen wrote:
> I havent tried this product yet, so maybe this is a stupid question:
>
>
> 1) A page that uses collective.skinny shows/loads much faster than a
> "normal page"
> 2) If 1) is the case, is there any way to "port" an existing theme or
> is it "buildt from bottom up"?
>
Needs to be built from the ground up unfortunately but if you've got the
standard html/css from a graphics designer its as easy as copying and
pasting it in. I created a collective.skinny-based theme this way in
under half a day. I know others have had similar experiences.

Thanks,
Tim

>
>
> Den 4. mai. 2009 kl. 23.57 skrev Tim Knapp:
>
> > Hi Daniel,
> >
> >
> > Thanks a lot for the clarification on this. I actually worked out
> > the
> > fact that I can use any 'stuff' in the acquisition chain after I
> > sent
> > this email (bit dense I guess ;). I had also gathered things need to
> > go
> > through the 'main.Main' view class but thanks a lot for the
> > clarification on the 'render_content' attribute, very helpful. (As
> > discussed on #plone) I've developed a couple of fairly involved
> > collective.skinny themes now and will post a message to the mailing
> > list/my blog when they're live as well as my 'war stories' :)
> >
> >
> >
> >
> > Here's some interesting figures from ab for a collective.skinny
> > theme VS
> > a standard plone site:
> >
> >
> > Standard Plone:
> > Requests per second:    3.27 [#/sec] (mean)
> >
> >
> > collective.skinny theme (with some heavy customisation):
> > Requests per second:    7.46 [#/sec] (mean)
> >
> >
> > Another collective.skinny theme (simple brochureware site):
> > Requests per second:    12.23 [#/sec] (mean)
> >
> >
> >
> >
> > Thanks again for an excellent package!
> >
> >
> > -Tim
> >
> >
> > On Mon, 2009-05-04 at 21:28 +0100, Daniel Nouri wrote:
> > > We talked a bit about this on IRC.  Let me answer to this thread,
> > > too.
> > >
> > >
> > > On Mon, Apr 27, 2009 at 10:38 AM, Tim Knapp <[hidden email]>
> > > wrote:
> > > > Further questions re. developing themes with collective.skinny:
> > > > It seems to me that you can't override cmf templates via
> > > > collective.skinny?
> > > >
> > > >
> > > > I've had to do quite a bit of workarounds to get simple things
> > > > like
> > > > 'search', 'navigation', 'sitemap' going. I think in the main
> > > > things like
> > > > this should really work OOTB otherwise you end up fighting
> > > > against the
> > > > 'framework' too much :(
> > >
> > >
> > > You should be able to register views and call them just fine.  For
> > > your view class, you'll want to inherit from the Main class and
> > > set a
> > > page template as the "render_content" attribute.  Therein, you can
> > > render whatever template you want to see in the "content area" of
> > > your
> > > skin, like a search widget.
> > >
> > >
> > > The way I use Skinny is for skins that don't have anything in
> > > common
> > > with the Plone interface.  The Plone UI is what we call the
> > > editing
> > > interface.  That is, we have a custom public view for all our
> > > content
> > > types, and we also implement search by ourselves -- just because
> > > it
> > > works very different to the search in the editing interface.
> > > Despite
> > > that, there's nothing that keeps you from using macros out of
> > > Plone
> > > templates in Skinny -- but maybe they'll need a bit more context;
> > > like
> > > provided by @@plone's globalize.  You can also use Plone's full
> > > API,
> > > like the queryCatalog script.
> > >
> > >
> > > fRiSi and I want to split collective.skinny into a library package
> > > and
> > > an example package, the latter will have example implementations
> > > for
> > > the most common things like search and sitemap, as well as the
> > > demo
> > > skin that's now in Skinny itself.
> > >
> > >
> > > Daniel
> >
> >
> >
> >
> > _______________________________________________
> > UI mailing list
> > [hidden email]
> > http://lists.plone.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Espen Moe-Nilssen]

Some javascript/style in this post has been disabled (why?)

Probably another stupid question:

Is it possible to base it (partly) on another skin?

or just "add" the .css files from another skin?

(this is how I have made the subskins-preset themes (that for some reason have disappeared from plone.org, will try to add them back)

Espen Moe-Nilssen

_______________________________________________

Subskins III , build your own theme for Plone

http://www.medialog.no/plone/subskins-iii

Den 5. mai. 2009 kl. 10.38 skrev Tim Knapp:

On Tue, 2009-05-05 at 09:23 +0200, Espen Moe-Nilssen wrote:

I havent tried this product yet, so maybe this is a stupid question:

1) A page that uses collective.skinny shows/loads much faster than a

"normal page"

2) If 1) is the case, is there any way to "port" an existing theme or

is it "buildt from bottom up"?

Needs to be built from the ground up unfortunately but if you've got the

standard html/css from a graphics designer its as easy as copying and

pasting it in. I created a collective.skinny-based theme this way in

under half a day. I know others have had similar experiences.

Thanks,

Tim

Den 4. mai. 2009 kl. 23.57 skrev Tim Knapp:

Hi Daniel,

Thanks a lot for the clarification on this. I actually worked out

the

fact that I can use any 'stuff' in the acquisition chain after I

sent

this email (bit dense I guess ;). I had also gathered things need to

go

through the 'main.Main' view class but thanks a lot for the

clarification on the 'render_content' attribute, very helpful. (As

discussed on #plone) I've developed a couple of fairly involved

collective.skinny themes now and will post a message to the mailing

list/my blog when they're live as well as my 'war stories' :)

Here's some interesting figures from ab for a collective.skinny

theme VS

a standard plone site:

Standard Plone:

Requests per second:    3.27 [#/sec] (mean)

collective.skinny theme (with some heavy customisation):

Requests per second:    7.46 [#/sec] (mean)

Another collective.skinny theme (simple brochureware site):

Requests per second:    12.23 [#/sec] (mean)

Thanks again for an excellent package!

-Tim

On Mon, 2009-05-04 at 21:28 +0100, Daniel Nouri wrote:

We talked a bit about this on IRC.  Let me answer to this thread,

too.

On Mon, Apr 27, 2009 at 10:38 AM, Tim Knapp <[hidden email]>

wrote:

Further questions re. developing themes with collective.skinny:

It seems to me that you can't override cmf templates via

collective.skinny?

I've had to do quite a bit of workarounds to get simple things

like

'search', 'navigation', 'sitemap' going. I think in the main

things like

this should really work OOTB otherwise you end up fighting

against the

'framework' too much :(

You should be able to register views and call them just fine.  For

your view class, you'll want to inherit from the Main class and

set a

page template as the "render_content" attribute.  Therein, you can

render whatever template you want to see in the "content area" of

your

skin, like a search widget.

The way I use Skinny is for skins that don't have anything in

common

with the Plone interface.  The Plone UI is what we call the

editing

interface.  That is, we have a custom public view for all our

content

types, and we also implement search by ourselves -- just because

it

works very different to the search in the editing interface.

Despite

that, there's nothing that keeps you from using macros out of

Plone

templates in Skinny -- but maybe they'll need a bit more context;

like

provided by @@plone's globalize.  You can also use Plone's full

API,

like the queryCatalog script.

fRiSi and I want to split collective.skinny into a library package

and

an example package, the latter will have example implementations

for

the most common things like search and sitemap, as well as the

demo

skin that's now in Skinny itself.

Daniel

_______________________________________________

UI mailing list

[hidden email]

http://lists.plone.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui

[Daniel Nouri]

Espen Moe-Nilssen writes:

> Probably another stupid question:
>
> Is it possible to base it (partly) on another skin?
>
> or just "add" the .css files from another skin?
>
> (this is how I have made the subskins-preset themes (that for some
> reason have disappeared from plone.org, will try to add them back)

If you mean is it possible to base it on a Plone skin?  You could reuse
CSS files from Plone if you wanted to.  You just add them to
`templates/head.pt`.

But if I understand you right, you want to make a main theme and allow
varieties thereof, like in Subskins III, yes?  I imagine you could make
a Plone control panel that allows to configure conditions for inclusion
of CSS files into `head.pt`, based on where you're in.  Or better, you
use classes on the <body> for your individual sections, and make that
configurable if that's what you want to do.


--
http://danielnouri.org


_______________________________________________
UI mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ui