[Grok-dev] Re: Question about viewlets

[Kevin Smith]

Hi Martijn,

Thanks for the reply.

Ordering by definition order seems pretty cool.

Ordering by dotted module name may create a consistent order, but does 
it have any real value? I typify it as "nice" to have.

When it's time to reorder things, would I rather change the order number 
or cut-n-paste the class? Dunno.

It's not a make or break feature, and it is in a way showcasing that 
grok directives can do a lot more, but *should* grok directives
do more? That's where I'm confused.

Maybe grok is in too highly an experimental stage of grokker development 
to start laying down rules, but  when I'm developing grokkers,
I think I want more rules. I want to have guidelines on when to create a 
directive and when not to. I see this directive and it makes me
wonder where the cut-off is for creating new directives. My gut instinct 
is *not* to create a new directive unless absolutely necessary. 
I think want a rule similar to "measure twice, cut once",  "less is 
more", or  "GROK SMASH ZCML".

So ultimately this may be a cry out for a "Grokkers Guide". (unless I 
already missed something like this on the list :) )

In Grok We Trust,

Kevin Smith


Martijn Faassen wrote:
> Hi there,
>
> Kevin Smith wrote:
> [snip]
>> IOW since grok.viewletmanager and grok.context *cannot* be expressed 
>> as a simple attributes, they *must* be grok directives, and
>> since grok.order can be expressed as a simple attribute it must not 
>> be a grok.directive.
>>
>> I mention this since it seems to fit into the recent "what is 
>> grok/what is not grok" discussion.
>
> I see 'grok.order' as something that will gain a meaning in other 
> places than just viewlets, particularly in menu definitions.
>
> You should see grok.order as related to things like grok.title and 
> grok.description (and hopefully one day grok.icon). The idea is a 
> future menu generator can make use of this information to deduce what 
> should be in there, just like viewlets already do.
>
> Note that grok.order() is a bit more advanced than you might suspect 
> at first. The rules for grokcore.component.util.sort_components:
>
> 1. if grok.order() is used explicitly with a numeric argument, that 
> will be used for sorting. Objects without explicit order will sort 
> before this.
>
> 2. if grok.order() is used without an argument, things are ordered in 
> definition order. If multiple modules are in play, they'll be sorted 
> by dotted module name.
>
> 3. if grok.order() is altogether missing, unfortunately some python 
> limitations make it impossible to use implicit ordering as in 2. 
> Instead  we sort on class name to have at least some consistent ordering.
>
> The idea is that we try to at least define a consistent order even if 
> you don't include grok.order(). There's a defaulting rule too.
>
> Note that you can always create your own grok.ViewletManager subclass 
> that sorts in a different way by overriding the right method.
>
> Anyway, that's why it's a directive: can be used in (potentially) 
> multiple situations, and implements defaulting behavior.
>
> (I wonder incidentally why the grok.order sorting logic moved into 
> grokcore.component. Nothing appears to use it there and it's not 
> really component-architectury. I do think it could be moved down, but 
> perhaps further. Maybe martian would be a reasonable place for this, 
> though Martian currently doesn't define directive policy at all, which 
> is an argument against doing that)
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>
>