[Grok-dev] Using z3c.template in Grok
Souheil CHELFOUH
trollfot at gmail.com
Fri Jan 8 17:18:40 EST 2010
That's why I built Dolmen
There are usecases, there are bricks, sometimes, we are lazy, so we
need some helpers.
I'm currently working on dolmen.menu with some success. I'll present
something working this week end
2010/1/8 Jeroen Michiel <jmichiel at yahoo.com>:
>
> I've been working with Grok/Zope3 for about a year now, and I did my menu
> implementation in the first few months, so I think I didn't realize how you
> could trick megrok.menu to use it for something else than context-like
> menus, hence my limited feel to it.
>
> However, I still find it strange that there isn't an all-inclusive menu
> package out there. From a newbie point of view, it's very confusing: I wrote
> my 'content menus' like you described by using a viewlet that collects the
> objects, but at the time, it was sort of my 'last resort' because I thought
> I was somehow missing the point, because from an experienced Grokker's point
> of view, writing content menus from scratch that way is repetitive and
> tedious, and doesn't seem very productive to me. Admitted, it doesn't take
> that much time to write, unless you're a newbie, and you can waste a lot of
> time trying things out, thinking that you're doing it 'grandma's way' while
> there has to be some magic, do-it-all package out there that you couldn't
> find.
>
> A home link is very simple to write from scratch, too, but it is so basic
> and ubiquitous, that I expected it to be one of the first things a menu
> package would offer. Having to write a redirecting view just to make a home
> link seems like killing a fly with a bazooka, if you know what I mean ;-)
> And a year ago, I wouldn't even have grasped the concept.
>
> Perhaps I'm just lazy by nature, but those 'content menus' are probably in
> more than half of the sites out there, so I would have expected there to be
> a package doing that for me: I'm implementing it in just my second app, and
> I felt like 'oh no not again, I've been here before'.
>
> megrok.menu is ideal for context menus: give me all the things (views) I can
> do with the current context. But for 'Global Menus' or 'Site Menus', it
> requires you to do some trickery, which I don't like that much, it's not
> clean.
>
> And I don't know whether it can be used for 'content menus' at all.
> For those I was thinking in the lines of a directive you could specify on a
> container indicating that all its contents should be rendered by menu X,
> also specifying the name of the view to be used for each link. Perhaps
> allowing you to also specify an interface, that restricts the menu to
> objects providing the interface.
>
> So what usecases do we actually have?
>
> - context menus -> megrok.menu
> - global menus/ site menus
> - content menu: build a menu from a container's contents
>
> maybe global and contextual content menu's could also make sense?
>
> Jeroen.
>
>
> Souheil CHELFOUH wrote:
>>
>> Your usecase sounds like a common use case I solved using a simple
>> megrok.menu
>> What's so limited about it, in your case ?
>>
>> For the folders listing, I can advise you to use a simple viewlet with
>> some logic to retrieve the objects.
>> The home link can be solved with megrok.menu by doing a redirection view
>> The link to the admin page would be a simple menuitem protected with a
>> permission on the admin has.
>>
>> For examples, you can have a look at dolmen.app.layout and
>> dolmen.app.authentication (this one is on the git)
>>
>> dolmen.menu is still under construction, I'm not sure where I want it to
>> go
>> Since it sparkled few if no interest at all, i'm left on my own for
>> making a spec up :)
>>
>> - Souheil
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Using-z3c.template-in-Grok-tp27072769p27083069.html
> Sent from the Grok mailing list archive at Nabble.com.
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>
More information about the Grok-dev
mailing list