[Grok-dev] Re: Skinning/themeing
Kevin Smith
kevin at mcweekly.com
Mon May 21 14:20:31 EDT 2007
Martijn Faassen wrote:
> kevin at mcweekly.com wrote:
>> By default, Z3 viewlets have no sort order at all. I think default
>> ordering by definition order in a module sounds great, but I need
>> code today.
>
> Oh, understood. I'm not telling you to change your code now. I'm just
> pondering what we should be doing in time.
Oops, replied to the wrong post. There are lot of Mart.*n's floating
around these days. :)
>
>> When starting to use this in production, I didn't find it confusing
>> or cluttered. Default ordering by class name means one less directive
>> to code, one less directive to remember.
>
> Real-world use is of course a good data-point. I just find the numbers
> in the class names in order to order them ugly... I hope we can do
> away with these by taking the in-module order in the future.
That's your decision to make. There are complications though with
in-module ordering too if additional viewlets are added from outside the
module.
>
>> I don't think it's as big a sin as it's being made out to be,
>> especially since it's easily overridden. :)
>
> I'm not saying you're sinning. I'm just thinking we can probably do
> better, but that'll take time, more work, and more thought. Agreed?
Agreed, this was definately sent to the wrong post. :)
Currently, a viewletmanager does nothing more than iterate over the
viewlets, sort order and filters are optional. The common case however
is an ordered viewletmanager. Grok may want to do something like plone
portlets and create a new flavor of viewlet. For draft purposes, let's
call it a groklet.
class MyView(grok.View):
pass
class InfoBox(grok.Groklet):
grok.context(MyView)
grok.name('left_column')
grok.order(10) # if missing, raise error or possibily replace with
in-module ordering
class WeatherBox(grok.Groklet):
grok.context(MyView)
grok.name('left_column')
grok.order(20)
Appears in template as...myview.pt
<span tal:replace="structure groklet:left_column" />
Note, there is no need to create an additional class for viewletmanager
here, since we are exercising the common case. When custom
viewletmanagers are needed, use viewlets. When dynamic policy and user
permissions are important use, plone portlets.
Best regards,
Kevin Smith
More information about the Grok-dev
mailing list