post 1.0 Grok development wishlist

[Martijn Faassen-2]

Hi there,

In the hope of prompting some discussions and development activity, here
is a list of post 1.0 Grok wishlist items I have or know about:

* Martian 0.12 porting. Martian 0.12 has a better story about how
inheritance and grok directives interact, and we want Grok to use this.
We made quite a bit of progress on this during the sprint, but the
porting isn't completed yet.

* related to this, grokcore.view refactoring so that templatedir() and
template() behave more predictably.

* related to this, exploring a step towards more explicit directives,
less implicit rules. We could experiment with a megrok.explicit
extension which requires a lot more directives to be present.

* the new grokui.admin, which is a lot more pluggable and hopefully will
lead to the creation of all sorts of plugins (introspector is one,
application configuration screens could be another).

* ZTK integration. Grok and grokcore.* should use the ZTK packages, not
Zope 3.4 anymore.

* Python 2.6 support. The ZTK integration will help a lot.

* megrok.layout integration. Look into integrating megrok.layout
functionality into the Grok core. This would require some discussion on
megrok.layout to see what shape this integration could best be like.

* z3c.hashedresource and hurry.resource integration. Some work was done
at the sprint to explore this.

* declarative model-level security decorators/directives, for the case
where Grok's "view-only" security system isn't enough and security
proxies are desired.

Anything else? Please discuss! Volunteers who want to work on this?

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Gary Poster-3]

On Oct 6, 2009, at 1:25 PM, Martijn Faassen wrote:

> Hi there,
>
> In the hope of prompting some discussions and development activity,
...

Hi Martijn.  Did the grokcore.component.creates change we discussed  
get shot down at sprint, or for lack of any interest from other people?

Gary
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Martijn Faassen wrote:
> * related to this, exploring a step towards more explicit directives,
> less implicit rules. We could experiment with a megrok.explicit
> extension which requires a lot more directives to be present.

This is a ball that we at THA can pick up, as we're quite explicit
about, uhm, explicitly using the directives. We already have a small
megrok.strictrequire package that does this for the grok.require()
directive.

> * ZTK integration. Grok and grokcore.* should use the ZTK packages, not
> Zope 3.4 anymore.
>
> * Python 2.6 support. The ZTK integration will help a lot.

At the very least Jan-Jaap's (and others'!) work on the grok and zope
buildbots can facilitate in this. See:

   http://dev.thehealthagency.com/buildbot/

> * megrok.layout integration. Look into integrating megrok.layout
> functionality into the Grok core. This would require some discussion on
> megrok.layout to see what shape this integration could best be like.

Also something that could interest us at THA.

> * z3c.hashedresource and hurry.resource integration. Some work was done
> at the sprint to explore this.

Idem.

> * declarative model-level security decorators/directives, for the case
> where Grok's "view-only" security system isn't enough and security
> proxies are desired.

Idem.

> Anything else? Please discuss! Volunteers who want to work on this?

So much to do, so little time *sigh* :-)

I'm still working an hour here, an hour there on the 1.0 release. I hope
to finish this soon. Then I will have the necessary mental bandwidth
again. I think I'll start on the megrok.explicit package.

Regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Martijn Faassen wrote:

> * related to this, exploring a step towards more explicit directives,
> less implicit rules. We could experiment with a megrok.explicit
> extension which requires a lot more directives to be present.

What are the benefits of this? What type of changes would this involve?

> * ZTK integration. Grok and grokcore.* should use the ZTK packages, not
> Zope 3.4 anymore.

This is the one I find most exciting. :) Getting Grok onto ZTK would
hopefully inject some more momentum into the ZTK effort, and make it
easier to re-use components across Grok, five.grok, Plone and other
consumers.

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Gary Poster wrote:
> On Oct 6, 2009, at 1:25 PM, Martijn Faassen wrote:
>
>> Hi there,
>>
>> In the hope of prompting some discussions and development activity,
> ...
>
> Hi Martijn.  Did the grokcore.component.creates change we discussed  
> get shot down at sprint, or for lack of any interest from other people?

No work done at the sprint on this. I think it would help a lot if you
could post an updated proposal to the mailing list in a new thread, so
we can have some wider-spread discussion about it (or if lacking this if
you and I agree, just go ahead. :).

You could also create a blueprint for it; we haven't been very good at
managing those so far but perhaps we'll get better. (I notice though
that the documentation team has done a lot of blue prints recently).

Regards,

Martijn



_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Jan-Wijbrand Kolman wrote:
> Martijn Faassen wrote:
>> * related to this, exploring a step towards more explicit directives,
>> less implicit rules. We could experiment with a megrok.explicit
>> extension which requires a lot more directives to be present.
>
> This is a ball that we at THA can pick up, as we're quite explicit
> about, uhm, explicitly using the directives. We already have a small
> megrok.strictrequire package that does this for the grok.require()
> directive.

Yes, I'm hoping we can go further this way, offering this as an
extension. Then if we like more explicitness, carefully fold it into Grok.

>> * ZTK integration. Grok and grokcore.* should use the ZTK packages, not
>> Zope 3.4 anymore.
>>
>> * Python 2.6 support. The ZTK integration will help a lot.
>
> At the very least Jan-Jaap's (and others'!) work on the grok and zope
> buildbots can facilitate in this. See:
>
>    http://dev.thehealthagency.com/buildbot/

Yes, that is a big improvement indeed!

This dummy also hopes we can also find an "reading and using the Grok
buildbot for dummies" document on grok.zope.org sometime soon. :)

>> * megrok.layout integration. Look into integrating megrok.layout
>> functionality into the Grok core. This would require some discussion on
>> megrok.layout to see what shape this integration could best be like.
>
> Also something that could interest us at THA.

It looks like we're starting to use this in one of my customer apps too.

>> * z3c.hashedresource and hurry.resource integration. Some work was done
>> at the sprint to explore this.
>
> Idem.

Yeah, I want to get this going myself too. :)

>> * declarative model-level security decorators/directives, for the case
>> where Grok's "view-only" security system isn't enough and security
>> proxies are desired.
>
> Idem.

This is mostly on your plate (and whoever else wants to drive this). I'm
happy to assist talking through the design and implementation, but
actually implementing it and testing it will be largely done by someone
else.

Regards,

Martijn


_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Martin Aspeli wrote:
> Martijn Faassen wrote:
>
>> * related to this, exploring a step towards more explicit directives,
>> less implicit rules. We could experiment with a megrok.explicit
>> extension which requires a lot more directives to be present.
>
> What are the benefits of this? What type of changes would this involve?

Two main reasons:

The first reason: We've noticed that in cases of inheritance, the
interactions between directives and default behavior can be very hard to
get right/explain. We see this issue especially in grokcore.view. That's
at least a danger sign.

We've also noticed there are two kinds of defaults:

* defaults which really are equivalent to the directive being on the
baseclass. I.e. grok.require('zope.View'), whatever the default layer
story is for grok.layer, etc.

* defaults which are calculated and depend on the existence of things in
the Python code and the existence of certain directories. grok.context
is an example, and so is grok.templatedir if auto-calculated, etc.

The second reason: at least JW at THA feels more explicit works better
in multi-person projects, as opposed to using the rules. Because I value
JW's opinion a lot, that's at least interesting input. :)

A related topic is that we want to explore other patterns of organizing
templates and resources instead of all stuffing them in _templates
directories (and the resources all in static or, in case of
hurry.resource my pattern is _resources).

Please note that I at this point am not convinced that we *should* get
rid of the more complicated default directives, but I want there to be
an extension that explores this topic, and see how it all feels.

>> * ZTK integration. Grok and grokcore.* should use the ZTK packages, not
>> Zope 3.4 anymore.
>
> This is the one I find most exciting. :) Getting Grok onto ZTK would
> hopefully inject some more momentum into the ZTK effort, and make it
> easier to re-use components across Grok, five.grok, Plone and other
> consumers.

Yes, the Grok project practically pushed the ZTK project into existence
earlier this year, so we're definitely interested in this. I'd very much
like to see a Grok that uses a lot less packages than it does today,
because it'll be easier to manage and easier to explain. And also
because I have BFG envy. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

On Tue, 06 Oct 2009 19:25:30 +0200
Martijn Faassen <faassen@...> wrote:

> Hi there,
>

   Good morning,

   I have been busy, and thinking.

> In the hope of prompting some discussions and development activity,
> here is a list of post 1.0 Grok wishlist items I have or know about:
>
> [...]
>
>
> * megrok.layout integration. Look into integrating megrok.layout
> functionality into the Grok core. This would require some discussion
> on megrok.layout to see what shape this integration could best be
> like.
>

  As I use heavily that package in Silva (since I somehow made it in
  Silva), I would like to work on that as well, as it's a feature I
  already use.

  So if there is people interested to brainstorm, I am all open.

  If JW and Jan Jaap are interested maybe we can setup some kind of
  local sprint a Friday afternoon at Infrae to talk about it (since we
  are in the same city).

> * z3c.hashedresource and hurry.resource integration. Some work was
> done at the sprint to explore this.
>

  I use my own cooked things for resources now, based in
  z3c.resourceinclude, but I am not 200% satisfied, I am interested
  to see how things are going here as well.

> * declarative model-level security decorators/directives, for the
> case where Grok's "view-only" security system isn't enough and
> security proxies are desired.
>

  That last point is the one which interest me the most. There two
  things I can think of:

  - a decorator, which takes a permission and protect that method with
    the given permission. As soon as you specify one decorator in your
    class, all non-specified authorized access are forbidden, i.e. you
    need to declare each method you want to access using a decorator:

    class MyContent(grok.Model):

       @grok.require('my.permission')
       def doMe(self, bla, blabla):
           pass


    The decorator could take an instance of grok.Permission as well.

    It sounds like in Zope2 with security.declarePrivate calls.

    It sounds easy as well, to understand, and write.

    But it doesn't sounds complete: I want to be able to protect
    attributes as well, with one permission for view, and one for set.

  - so we could create two directives, one for view, one for set (so
    it cover the property usecase). They takes an interface, and a
    permission, and do their jobs. If you don't set a view directive
    but a set, the view fallback to the same permission than the view.


    class IMyContent(grok.IContext):

        lastDone = interface.Attribute()

        def doMe(bla, blabla):
            pass


    class MyContent(grok.Model):

        grok.restrict(IMyContent, 'my.changepermission')
        grok.restrictAccess(IMyContent, 'my.viewpermission')

        ...
   

    It's nice because this does everything I want of (in fact it's just
    a translation of the ZCML configuration in grok directives, it's
    not that original).

    But you need to write interfaces to declare your security.
    Interface are always a good thing anyway, but it sound complicated
    for Grok newbies, whenever the first solution sounds more easy to
    understand.

    It might be shorter for complex declaration: you don't have to
    repeat 20 times the grok.require with the same permission for a
    class with 20 methods.

  I think the best will still be only to implement the second 'idea' as
  if you need to setup content-level security, that means your
  application is complex, and so you are not a newbie anymore, so you
  can understand and write interfaces. But if someone want the first
  one anyway, I think it's doable in a megrok.something extension to
  have it.

  In both case, I propose the default security should be 'open' for a
  class. If you specify a security definition on a class, all
  non-declared attributes should be forbidden of access (let say
  'closed').

  For people who want to enforce security everywhere, I think that
  megrok.strictrequire could check that.

  Anyway I think everybody will agree that, that code should end up in
  grokcore.security.

  Note: all the directives name I propose are just the one who popup in
  my mind when writing that mail. I am sure we can think of something
  better.

  If anyone have comments, I would love to have them. Maybe someone
  have a better way/idea to define security.

  Best regards,

  Sylvain,

--
Sylvain Viollon -- Infrae
t [phone] -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

On Mon, 26 Oct 2009 09:59:59 +0100
Sylvain Viollon <sylvain@...> wrote:

Hello,

   Anybody have any idea about I proposed here ?

   Anybody is interested about the topic ?

   Best regards,

   Sylvain,

> On Tue, 06 Oct 2009 19:25:30 +0200
> Martijn Faassen <faassen@...> wrote:
>
> > Hi there,
> >
>
>    Good morning,
>
>    I have been busy, and thinking.
>
> > In the hope of prompting some discussions and development activity,
> > here is a list of post 1.0 Grok wishlist items I have or know about:
> >
> > [...]
> >
> >
> > * megrok.layout integration. Look into integrating megrok.layout
> > functionality into the Grok core. This would require some discussion
> > on megrok.layout to see what shape this integration could best be
> > like.
> >
>
>   As I use heavily that package in Silva (since I somehow made it in
>   Silva), I would like to work on that as well, as it's a feature I
>   already use.
>
>   So if there is people interested to brainstorm, I am all open.
>
>   If JW and Jan Jaap are interested maybe we can setup some kind of
>   local sprint a Friday afternoon at Infrae to talk about it (since we
>   are in the same city).
>
> > * z3c.hashedresource and hurry.resource integration. Some work was
> > done at the sprint to explore this.
> >
>
>   I use my own cooked things for resources now, based in
>   z3c.resourceinclude, but I am not 200% satisfied, I am interested
>   to see how things are going here as well.
>
> > * declarative model-level security decorators/directives, for the
> > case where Grok's "view-only" security system isn't enough and
> > security proxies are desired.
> >
>
>   That last point is the one which interest me the most. There two
>   things I can think of:
>
>   - a decorator, which takes a permission and protect that method with
>     the given permission. As soon as you specify one decorator in your
>     class, all non-specified authorized access are forbidden, i.e. you
>     need to declare each method you want to access using a decorator:
>
>     class MyContent(grok.Model):
>
>        @grok.require('my.permission')
>        def doMe(self, bla, blabla):
>            pass
>
>
>     The decorator could take an instance of grok.Permission as well.
>
>     It sounds like in Zope2 with security.declarePrivate calls.
>
>     It sounds easy as well, to understand, and write.
>
>     But it doesn't sounds complete: I want to be able to protect
>     attributes as well, with one permission for view, and one for set.
>
>   - so we could create two directives, one for view, one for set (so
>     it cover the property usecase). They takes an interface, and a
>     permission, and do their jobs. If you don't set a view directive
>     but a set, the view fallback to the same permission than the view.
>
>
>     class IMyContent(grok.IContext):
>
>         lastDone = interface.Attribute()
>
>         def doMe(bla, blabla):
>             pass
>
>
>     class MyContent(grok.Model):
>
>         grok.restrict(IMyContent, 'my.changepermission')
>         grok.restrictAccess(IMyContent, 'my.viewpermission')
>
>         ...
>    
>
>     It's nice because this does everything I want of (in fact it's
> just a translation of the ZCML configuration in grok directives, it's
>     not that original).
>
>     But you need to write interfaces to declare your security.
>     Interface are always a good thing anyway, but it sound complicated
>     for Grok newbies, whenever the first solution sounds more easy to
>     understand.
>
>     It might be shorter for complex declaration: you don't have to
>     repeat 20 times the grok.require with the same permission for a
>     class with 20 methods.
>
>   I think the best will still be only to implement the second 'idea'
> as if you need to setup content-level security, that means your
>   application is complex, and so you are not a newbie anymore, so you
>   can understand and write interfaces. But if someone want the first
>   one anyway, I think it's doable in a megrok.something extension to
>   have it.
>
>   In both case, I propose the default security should be 'open' for a
>   class. If you specify a security definition on a class, all
>   non-declared attributes should be forbidden of access (let say
>   'closed').
>
>   For people who want to enforce security everywhere, I think that
>   megrok.strictrequire could check that.
>
>   Anyway I think everybody will agree that, that code should end up in
>   grokcore.security.
>
>   Note: all the directives name I propose are just the one who popup
> in my mind when writing that mail. I am sure we can think of something
>   better.
>
>   If anyone have comments, I would love to have them. Maybe someone
>   have a better way/idea to define security.
>
>   Best regards,
>
>   Sylvain,
>

--
Sylvain Viollon -- Infrae
t [phone] -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Hi Sylvain,

Sylvain Viollon wrote:

> On Mon, 26 Oct 2009 09:59:59 +0100
> Sylvain Viollon <sylvain@...> wrote:
>
> Hello,
>
>    Anybody have any idea about I proposed here ?
>
>    Anybody is interested about the topic ?
>  
>>   So if there is people interested to brainstorm, I am all open.
>>
>>   If JW and Jan Jaap are interested maybe we can setup some kind of
>>   local sprint a Friday afternoon at Infrae to talk about it (since we
>>   are in the same city).

I think your ideas are interesting and yes indeed, we're very close
togteher and so we can easily "mini sprint" on these topics! I'd very
much like that idea! Let's do that!

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev