Hi Veda,

I'm been silent on this list due to work but have been reading. I  
agree with you on this point completely.

-Johnpaul Burbank



On May 1, 2008, at 4:56 PM, Veda Williams wrote:

> Hello,
>
> The current plone3 paster recipe creates skin-related files in more  
> than one
> location. Does anyone have any thoughts on why it would be good  
> practices to
> put skin related information into the browser directory?
>
> I'm leaning towards asking for a paster recipe revision so that skins
> information stays in the skins folder and nowhere else (and I'd like  
> to
> recommend this as a best practice).
>
> A fairly urgent reply is requested, as we are ramping up to the next  
> round
> of OOTB theming and I'd like the cleanest skins possible.
>
> Thanks,
>
> - Veda
>
>
> ------------------------
> Veda Williams
> Project Manager/Skinner/OOTB Theming Champiion
> ONE/Northwest
>
> New tools and strategies for engaging people in protecting the  
> environment
>
> veda@...
> http://www.onenw.org
> Skype ID: vedawms
> Phone: 206.286-1235 x24
> Fax: 206.260.2737
>
> Subscribe to ONEList, our email newsletter!
> Practical advice for effective online engagement
> http://www.onenw.org/full_signup
>
>
>
> --
> Archive: http://www.openplans.org/projects/ootb-plone-themes/lists/ootb-plone-themes-discussion/archive/2008/05/1209686168874
> To unsubscribe send an email with subject unsubscribe to ootb-plone-themes-discussion@... 
> .  Please contact ootb-plone-themes-discussion-manager@... 
>  for questions.
>
>

> The current plone3 paster recipe creates skin-related files in more than one
> location. Does anyone have any thoughts on why it would be good practices to
> put skin related information into the browser directory?
> 
> I'm leaning towards asking for a paster recipe revision so that skins
> information stays in the skins folder and nowhere else (and I'd like to
> recommend this as a best practice).
> 

As far as I understand it is the correct zope 3 way. Skinning becames more
complicated (compare to skinning for plone 2) for pure css designers. It forse
them to learn things that are not a designer's stuff. Personally I am anxious
about this. This makes me think that even with the deliverance skinning won't
be that simple for a designer. Sorry for this pessimistic  thought :)

On May 2, 2008, at 1:56 AM, Veda Williams wrote:

> Hello,
>
> The current plone3 paster recipe creates skin-related files in more  
> than one
> location. Does anyone have any thoughts on why it would be good  
> practices to
> put skin related information into the browser directory?
>
> I'm leaning towards asking for a paster recipe revision so that skins
> information stays in the skins folder and nowhere else (and I'd like  
> to
> recommend this as a best practice).
>
> A fairly urgent reply is requested, as we are ramping up to the next  
> round
> of OOTB theming and I'd like the cleanest skins possible.

Hello Veda,

As you could see in my themes - first thing I do after creating the  
theme with paster - remove browser resources and put images and  
stylesheets back to skins/ folder.

There are 2 reasons:
	1. I hate those urls like ++resource++...
	2. I still like to use DTML variables from base_properties in my  
stylesheets

So, I agree to support using skins/ as the main place for stylesheets :)

------------------------------------------------------------------
Denys Mishunov           denis@...

WEB COUTURIER      www.webcouturier.com
                                         info@...

Web Couturier - making style in Plone themes

Hi all,

First, please accept my apologies for not being more present on this  
list, and specifically on this discussion, I'm struggling with time  
for several reasons.

Second, let me congratulate all the skinners/themers for their hard  
work. It is the first time that such a collaborative work has been  
driven in order to provide more than one quality themes for Plone.  
You are filling a big, long standing gap. Thank you!

Now about the plone3_theme template of ZopeSkel, and how to deal with  
themeing resources in a theme product:

I understand very well the concerns that are addressed here. I am  
currently writing some up-to-date documentation about themeing Plone  
(the Plone 3 way), and I agree that having to learn python+zope2+zope3 
+plone_the_old_way+plone_the_new_way before being able to start  
customizing Plone is far too much for a newcomer who is a talented  
designer/web founder but who doesn't have all that background (and  
doesn't have the time to turn his mind around all of it).
Having to teach all this background before letting students start  
working on a theme project for Plone sounds even more inappropriate:  
people who are used to learn by themselves can accept many kinds of  
complexity, those who want/need to be teached (there are many good  
reasons for that) will not. This is what keeps me away from teaching  
Plone for now.

The ZopeSkel template shares the same goals as the DIYPloneStyle  
product: being a tool able to generate the base code for  
bootstrapping a "File System Based Theme Product", including all the  
needed parts of such a product, but nothing more.
While writing documentation about how to develop a theme for Plone, I  
also paid attention to have DIY/ZopeSkel be the right example of best  
practices to use when it comes to develop a theme for Plone.
These goals were easy enough to achieve while we were talking about  
Plone 2.1/2.5 as there was one canonical way to override skin  
elements through the portal_skins tool (or through Acquisition).
Now that we are dealing with Plone 3, there is more than "the only  
one way to it". Worse: both ways sometimes clash (for instance, you  
can't declare a background image located in the Acquisition chain in  
a stylesheet that is a zope 3 resource, which is not in the  
Acquisition chain). So the idea behind the plone3_theme template has  
slightly moved to this: showing what you _can_ do, not only what you  
_should_ be doing. To me, both approaches have their own advantages,  
and I'm not the one who will stop people from using Zope 3 style  
resources. Yes, there are advantages to it (please read below the  
pasted messages, they are from private emails but contain public  
domain informations.. thx martin :-) ).

For the same reasons as the ones Martin points out, I am quite  
reluctant to changing the way plone3_theme behaves.
Although, this might be of some solution: we could add a basic, ready  
to use stylesheet in the skins tool, which uses DTML, base_properties  
and Acquisition. So that people who prefer to use that one do use it  
(and can ignore the browser/), and people who want to play with zope  
3 resources find their way easily in the bootstrapped code. And no  
real harm would be done to existing documentation.

That said, I agree that the situation could lead to many confusions  
for newcomers, so the ideal solution that I can think of is this:
There is (maybe still in a branch, to be checked)  a way to use  
ZopeSkel for injecting parts of code inside an existing product (for  
instance , add a content type with all its zcml, profile, class  
declarations).
My dream would be to have ZopeSkel generate an empty plone product  
(nested python namespace, with basic zcml and __init__.py only, just  
like the 'plone' ZopeSkel template), and then to be able to inject  
the code needed for creating a skin dierectory (registered with  
portal_skins), or a zope 3 resource style image declaration, or a  
zope 3 skin layer, or the base code for a viewlet.

These were my humble €0.02

cheers everyone,
dav

PS veda, I agree with Martin, lets gain from a wider audience and  
move this discussion to a more a general mailing list (maybe product- 
developers).

> On 05 May 2008, at 19:18, Veda Williams wrote:
>
>
>> Hey David,
>>
>> Not sure if you've been following this thread (see below), but I'd
>> like to
>> know your thoughts on changing the paster template for 3.0 so that it
>> doesn't encourage people to put their themes into the browser
>> directory AND
>> the skins directory.
>>
>> Note that I do build themes which use the browser folder fairly
>> often for
>> customizing viewlets, etc., but I still keep all of my styles and
>> images in
>> the skins folder. I don't really see the down side to doing this.
>>
>> I've read Martin's explanation, and while I somewhat understand
>> where he's
>> coming from, it seems like the approach the plone3_theme recipe
>> currently
>> follows is more appropriate for a complex Plone product than for a
>> theme. As
>> a result, we're introducing sloppiness, and we're expecting themers
>> to have
>> the knowledge level of programmers. We can't expect newcomers to
>> know the
>> difference between "old style" and "new style" -- it's hard even
>> for those
>> of us who have been doing theming with Plone for some time. Should
>> we not be
>> shooting for a lower bar for a simple theme product -- something on
>> the
>> level of Wordpress theme development?
>>
>> As far as Deliverance goes, I don't see yet how it will help the
>> average
>> themer. Chris McDonough recently demo'ed Deliverance for our user
>> group, and
>> it seemed like its main goal is to make various apps look the  
>> same, as
>> opposed to a tool that will be useful to people needing to build
>> complex,
>> unique themes. Sounds great for enterprise level design, but it
>> doesn't fit
>> our use case at all.
>>
>> If the goal is to simplify the theming story, why then are we
>> pushing people
>> to understanding Zope3 programming techniques? My hope is that
>> someday Plone
>> themers won't even have to know what the ZMI is, much less what a
>> browser
>> resource is. Altering the recipe slightly won't disallow
>> programmers from
>> building on top of the themes, but it certainly would make thing
>> clearer for
>> non-programmers.
>>
>> I'm just looking for an satisfying answer as to whether we can
>> alter the
>> recipe slightly to minimize bloat. I think the impact on
>> documentation would
>> be minimal. Can you tell me your thoughts on this, and I'll defer
>> to your
>> opinion.
>>
>> Thanks,
>>
>> - Veda
>>
>>
>> Message: 13
>> Date: Fri, 02 May 2008 08:41:40 +0100
>> From: Martin Aspeli <optilude@...>
>> Subject: Re: [Plone-Users] Skins in the resources directory - why?
>> To: plone-users@...
>> Message-ID: <fvegjn$i42$1@...>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Veda Williams wrote:
>>
>>> Hello,
>>>
>>> The current plone3 paster recipe creates skin-related files in
>>> more than one
>>> location. Does anyone have any thoughts on why it would be good
>>> practices to
>>> put skin related information into the browser directory?
>>>
>>> I'm leaning towards asking for a paster recipe revision so that  
>>> skins
>>> information stays in the skins folder and nowhere else (and I'd
>>> like to
>>> recommend this as a best practice).
>>>
>>> A fairly urgent reply is requested, as we are ramping up to the
>>> next round
>>> of OOTB theming and I'd like the cleanest skins possible.
>>>
>>
>> The main reason, I suspect, is/was a general leaning towards Zope 3
>> techniques and patterns. There is a general benefit in Z3 resources
>> (which are in the ++resource++ "namespace"), because all active  
>> layers
>> in portal_skins are part of a single, global namespace that overlaps
>> with the content hierarchy as well. If you create a skin-layer
>> resource
>> called 'foo.pt', you can't have content with id 'foo' and you can't
>> have
>> any other skin layer resource with id 'foo' either, be that a  
>> template
>> or a pyscript or something else.
>>
>> Now, this is more of a problem for reusable products than it is for
>> bespoke themes, since those tend to be applied "last". I also fully
>> buy
>> the argument that it's confusing to have to do things in two  
>> different
>> places. Unfortunately, we're already there, because if you want to
>> customise any browser views, viewlets or existing Z3 browser
>> resources,
>> you're going to have to register them in the Zope 3 way, which means
>> that by convention they go in the 'browser' folder and require a ZCML
>> directive.
>>
>> When I wrote about this in my book, I took this view and basically
>> suggested that new/custom resources were managed as browser  
>> resources,
>> and that the skins/* folders were used to override "old-style"
>> resources
>> only. If you have my book, this is in chapter 8.
>>
>> As a general principle, I am *extremely* reluctant to see any
>> paster/ZopeSkel template significantly change. That's not just
>> because I
>> have a vested interest in making sure my book stays current and
>> accurate
>> (it describes the outputs of various paster commands in some detail
>> and
>> the example code assumes those things have been generated in this
>> way),
>> but also because of other documentation.
>>
>> I won't oppose changes (and in any case, David owns the plone3_theme
>> template and DIYPloneStyle) if they are carefully considered.  
>> However,
>> rushing a change is definitely the wrong thing to do.
>>
>> This also highlights the urgency (expressed many times already) of
>> unifying the two approaches to visual customisation and scoping out
>> the
>> role of Deliverance in lifting aspects of theming out of this murky
>> world and into something with a much shorter tool chain.
>>
>> Regards,
>> Martin
>>
>> -- 
>> Author of `Professional Plone Development`, a book for developers who
>> want to work with Plone. See http://martinaspeli.net/plone-book
>>
>>
>
>

On 02 May 2008, at 01:56, Veda Williams wrote:
> Hello,
>
> The current plone3 paster recipe creates skin-related files in more  
> than one
> location. Does anyone have any thoughts on why it would be good  
> practices to
> put skin related information into the browser directory?
>
> I'm leaning towards asking for a paster recipe revision so that skins
> information stays in the skins folder and nowhere else (and I'd  
> like to
> recommend this as a best practice).
>
> A fairly urgent reply is requested, as we are ramping up to the  
> next round
> of OOTB theming and I'd like the cleanest skins possible.
>
> Thanks,
>
> - Veda
>
>
> ------------------------
> Veda Williams
> Project Manager/Skinner/OOTB Theming Champiion
> ONE/Northwest
>
> New tools and strategies for engaging people in protecting the  
> environment
>
> veda@...
> http://www.onenw.org
> Skype ID: vedawms
> Phone: 206.286-1235 x24
> Fax: 206.260.2737
>
> Subscribe to ONEList, our email newsletter!
> Practical advice for effective online engagement
> http://www.onenw.org/full_signup
>
>
>
> --
> Archive: http://www.openplans.org/projects/ootb-plone-themes/lists/ 
> ootb-plone-themes-discussion/archive/2008/05/1209686168874
> To unsubscribe send an email with subject unsubscribe to ootb-plone- 
> themes-discussion@....  Please contact ootb-plone- 
> themes-discussion-manager@... for questions.
>

+ in browser it is possible to edit it and it shows right away.
- in debug mode the images doesnt always show (?)

what about speed here? is it the same?


Den 2. mai. 2008 kl. 01.56 skrev Veda Williams:

> Hello,
>
> The current plone3 paster recipe creates skin-related files in more  
> than one
> location. Does anyone have any thoughts on why it would be good  
> practices to
> put skin related information into the browser directory?
>
> I'm leaning towards asking for a paster recipe revision so that skins
> information stays in the skins folder and nowhere else (and I'd  
> like to
> recommend this as a best practice).
>
> A fairly urgent reply is requested, as we are ramping up to the  
> next round
> of OOTB theming and I'd like the cleanest skins possible.
>
> Thanks,
>
> - Veda
>
>
> ------------------------
> Veda Williams
> Project Manager/Skinner/OOTB Theming Champiion
> ONE/Northwest
>
> New tools and strategies for engaging people in protecting the  
> environment
>
> veda@...
> http://www.onenw.org
> Skype ID: vedawms
> Phone: 206.286-1235 x24
> Fax: 206.260.2737
>
> Subscribe to ONEList, our email newsletter!
> Practical advice for effective online engagement
> http://www.onenw.org/full_signup
>
>
>
> --
> Archive: http://www.openplans.org/projects/ootb-plone-themes/lists/ 
> ootb-plone-themes-discussion/archive/2008/05/1209686168874
> To unsubscribe send an email with subject unsubscribe to ootb-plone- 
> themes-discussion@....  Please contact ootb-plone- 
> themes-discussion-manager@... for questions.
>

Attachments

text.html (text/html) 12.1 kB