0.14 todo list

[Martijn Faassen-2]

Hi there,

A while ago I wrote a wishlist for improvements in Grok 0.14. We've had
some discussion then, and some more development, so let's turn this into
a TODO list:

* grokcore.view - useful in five.grok, but also useful as a stand-alone
component in a Zope 3 context. (Godefroid Chapelle, Lennart Regebro,
Philip von Weitershausen). We need to push this towards a release and
merge this with the Grok trunk. Looks like Philipp made some headway
towards separating out something like grokcore.form as well.

* grok.skin directive on interfaces that subclass IBrowserRequest
(Jan-Wijbrand Kolman). This should result in a simplification of the way
skins work in Grok, reflecting better the way they actually work in Zope 3.

* WSGI in Grok (Philipp as driver)

* Paster to start Grok (Philipp as driver)

* Development/deployment profiles with useful WSGI middleware (Philipp
as driver)

* relative REST, i.e. optionally exposing something like <content>/rest/
  for REST access (Craeg Strong as driver. Craeg, do please start a
design discussion. Could possibly also be done as a Grok extension)

Anything else to put on the list? I think we should get 0.14 out of the
door sometime in september, and the WSGI stuff is already quite
ambitious, but if we have people willing to do the work we can certainly
consider more.

Regards,

Martijn

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

[Martin Aspeli]

Martijn Faassen wrote:

> Hi there,
>
> A while ago I wrote a wishlist for improvements in Grok 0.14. We've had
> some discussion then, and some more development, so let's turn this into
> a TODO list:
>
> * grokcore.view - useful in five.grok, but also useful as a stand-alone
> component in a Zope 3 context. (Godefroid Chapelle, Lennart Regebro,
> Philip von Weitershausen). We need to push this towards a release and
> merge this with the Grok trunk. Looks like Philipp made some headway
> towards separating out something like grokcore.form as well.
>
> * grok.skin directive on interfaces that subclass IBrowserRequest
> (Jan-Wijbrand Kolman). This should result in a simplification of the way
> skins work in Grok, reflecting better the way they actually work in Zope 3.
>
> * WSGI in Grok (Philipp as driver)
>
> * Paster to start Grok (Philipp as driver)
>
> * Development/deployment profiles with useful WSGI middleware (Philipp
> as driver)
>
> * relative REST, i.e. optionally exposing something like <content>/rest/
>   for REST access (Craeg Strong as driver. Craeg, do please start a
> design discussion. Could possibly also be done as a Grok extension)
>
> Anything else to put on the list? I think we should get 0.14 out of the
> door sometime in september, and the WSGI stuff is already quite
> ambitious, but if we have people willing to do the work we can certainly
> consider more.

I can't really contribute, but I just wanted to say that this makes me
really, really excited. :)

I think 0.14 sounds like the release where I would seriously consider
Grok for a project, and grokcore.view sounds like something Plone badly
needs. I'll buy anyone who works on it a beer at the Plone conference if
Grok-like views work by the time I give my talk. :)

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@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Philipp von Weitershausen]

Martijn Faassen wrote:
> A while ago I wrote a wishlist for improvements in Grok 0.14. We've had
> some discussion then, and some more development, so let's turn this into
> a TODO list:
>
> * grokcore.view - useful in five.grok, but also useful as a stand-alone
> component in a Zope 3 context. (Godefroid Chapelle, Lennart Regebro,
> Philip von Weitershausen). We need to push this towards a release and
> merge this with the Grok trunk. Looks like Philipp made some headway
> towards separating out something like grokcore.form as well.

Yup. grokcore.view is ready to be split up into grokcore.view and
grokcore.formlib (I feel better about this name since the underlying
framework that it wraps is called zope.formlib). I already split
grokcore.security away from grokcore.view.

> * grok.skin directive on interfaces that subclass IBrowserRequest
> (Jan-Wijbrand Kolman). This should result in a simplification of the way
> skins work in Grok, reflecting better the way they actually work in Zope 3.

Indeed. I'd like to wait for JW's work to land in the trunk, then factor
it into grokcore.view (because that's where this stuff actually lives
now). After that I'd like to get the grokcore.xxx branch merged as
quickly as possible. It will introduce three new dependencies:

* grokcore.security
* grokcore.view
* grokcore.formlib

> * WSGI in Grok (Philipp as driver)
>
> * Paster to start Grok (Philipp as driver)
>
> * Development/deployment profiles with useful WSGI middleware (Philipp
> as driver)

These are all related, of course, but that doesn't mean they all need me
as a driver. I'd be happy if more people were to explore the last bit,
for instance...

Earlier this month I briefly visited with Zope Corporation and had a
little chat with Jim about WSGI integration. We basically agreed on the
new way to go with zope.publisher.paste, publication factories, etc. THe
good news is that it'll all be much simpler with what we have in mind.
The bad news is that it will take some sprint-level coding for which I
will have to make time. Perhaps I shoudl write down the ideas so that
other people could have a go?

> * relative REST, i.e. optionally exposing something like <content>/rest/
>  for REST access (Craeg Strong as driver. Craeg, do please start a
> design discussion. Could possibly also be done as a Grok extension)
>
> Anything else to put on the list?

Model-based security.

> I think we should get 0.14 out of the
> door sometime in september, and the WSGI stuff is already quite
> ambitious, but if we have people willing to do the work we can certainly
> consider more.

I'd also like us to think about the 1.0 roadmap at some point. I think
we could use a 1.0 release after nearly 2 years of development :).

My suggestion is that we should have a 0.xx release that basically
resembles what we think 1.0 should look like. Then, after the dust has
settled (few weeks or months after), we should release 1.0 which would
look much like 0.xx. THis 0.xx would be a beta release, so to speak. As
far as I'm concerned, 0.14 could be this last 0.xx release before 1.0,
but other people might have other opinions, which is fine. I'd just like
us to think about 1.0 if that's ok.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Philipp von Weitershausen wrote:
>> * grok.skin directive on interfaces that subclass IBrowserRequest
>> (Jan-Wijbrand Kolman). This should result in a simplification of the
>> way skins work in Grok, reflecting better the way they actually work
>> in Zope 3.
>
> Indeed. I'd like to wait for JW's work to land in the trunk, then factor
> it into grokcore.view (because that's where this stuff actually lives
> now).(...)

Right, well, I'm getting there. I have the directive (which, because
we're grokking Interface "classes", was a little bit involved) and I'm
working on the grokker now. This should not take long, but then I need
to deprecate grok.Skin and grok.IGrokLayer and write some docs on how to
"properly" do layers+skins as well.

All in all, realistically, I think it will be somewhere at the end of
this week that I can finish this up.


BTW, I'm happy to volunteer to do the actual release 0.14. I would be
nice though if someone is available to talk to during the release :)


regards,
jw

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

[Jan-Wijbrand Kolman-3]

Martijn Faassen wrote:
> Hi there,
>
> A while ago I wrote a wishlist for improvements in Grok 0.14. We've had
> some discussion then, and some more development, so let's turn this into
> a TODO list:
snip
> Anything else to put on the list? I think we should get 0.14 out of the
> door sometime in september, and the WSGI stuff is already quite
> ambitious, but if we have people willing to do the work we can certainly
> consider more.

Ideally I would've started talking/thinking about pagelets-in-grok.
Since you're aiming for september, I still have the faint hope I can do
something about it, but I cannot promise.


regards,
jw

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

[Sylvain Viollon]

Hello,

On Mon, 28 Jul 2008 22:39:05 +0100
Martin Aspeli <optilude@...> wrote:


> I can't really contribute, but I just wanted to say that this makes
> me really, really excited. :)
>
> I think 0.14 sounds like the release where I would seriously consider
> Grok for a project, and grokcore.view sounds like something Plone
> badly needs. I'll buy anyone who works on it a beer at the Plone
> conference if Grok-like views work by the time I give my talk. :)
>

   This work now in Silva, Grok-like views. You have almost nothing to
do, just put some conventions for your application/framework saying you
have to build your templates like that. Forms works quite well, with
formlib. I should try to use z3c.form instead.

   I am building a demo extension, if you are interested:

   https://svn.infrae.com/silva.app.blog/trunk

   Thanks to Godefroid and Lennart for grokcore.views.

   Sylvain,


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

[Martijn Faassen-2]

Hi there,

Philipp von Weitershausen wrote:
[snip]
>> Anything else to put on the list?
>
> Model-based security.

I deliberately didn't put it on the list, as 0.14 will be challenging
enough without it. It'd like to get the WSGI stuff in there finally, and
that's a huge enough new feature without piling on this.

Anyway, just a meme correction: Grok *does* have model-based security
and always has. We shouldn't go around saying Grok doesn't have it. It
doesn't have model-based security *checks*, but it's perfectly possible
to assign someone or a group a permission or role on a model.

What would be a smaller project is someone implementing a simpler API
for security assignments as we discussed at the sprint.

Another hot topic on our wishlist for a long time is some user
management screens.

And then there's the grokui.* work of course. :)

Regards,

Martijn

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

[Philipp von Weitershausen]

Martijn Faassen wrote:

> Hi there,
>
> Philipp von Weitershausen wrote:
> [snip]
>>> Anything else to put on the list?
>>
>> Model-based security.
>
> I deliberately didn't put it on the list, as 0.14 will be challenging
> enough without it. It'd like to get the WSGI stuff in there finally, and
> that's a huge enough new feature without piling on this.
>
> Anyway, just a meme correction: Grok *does* have model-based security
> and always has. We shouldn't go around saying Grok doesn't have it. It
> doesn't have model-based security *checks*, but it's perfectly possible
> to assign someone or a group a permission or role on a model.

Not wanting to get into a terminology discussion, but I'd call these
"model-based grants". This is a feature of Grok's default security
policy, zope.securitypolicy. By model-based security I meant
attribute-level protections on models.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Philipp von Weitershausen wrote:

> Martijn Faassen wrote:
>> Hi there,
>>
>> Philipp von Weitershausen wrote:
>> [snip]
>>>> Anything else to put on the list?
>>>
>>> Model-based security.
>>
>> I deliberately didn't put it on the list, as 0.14 will be challenging
>> enough without it. It'd like to get the WSGI stuff in there finally,
>> and that's a huge enough new feature without piling on this.
>>
>> Anyway, just a meme correction: Grok *does* have model-based security
>> and always has. We shouldn't go around saying Grok doesn't have it. It
>> doesn't have model-based security *checks*, but it's perfectly
>> possible to assign someone or a group a permission or role on a model.
>
> Not wanting to get into a terminology discussion, but I'd call these
> "model-based grants". This is a feature of Grok's default security
> policy, zope.securitypolicy. By model-based security I meant
> attribute-level protections on models.

I'm talking about marketing here. I'd prefer to call the model based
grants "model based security", or "model-level permissions". This is
for the reason that if you talk to someone who has no idea that security
proxies even exist (most Python programmers out there), "Grok needs
model-based security" means to him that Grok has no model-based grants
yet. But Grok/Zope 3 actually has a very powerful system for this,
probably more powerful than all competing web frameworks. We should be
careful to emphasize Grok's powerful security model and not accidentally
give people the impression that it doesn't.

Regards,

Martijn

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

[Philipp von Weitershausen]

Martijn Faassen wrote:

> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>>> Hi there,
>>>
>>> Philipp von Weitershausen wrote:
>>> [snip]
>>>>> Anything else to put on the list?
>>>>
>>>> Model-based security.
>>>
>>> I deliberately didn't put it on the list, as 0.14 will be challenging
>>> enough without it. It'd like to get the WSGI stuff in there finally,
>>> and that's a huge enough new feature without piling on this.
>>>
>>> Anyway, just a meme correction: Grok *does* have model-based security
>>> and always has. We shouldn't go around saying Grok doesn't have it.
>>> It doesn't have model-based security *checks*, but it's perfectly
>>> possible to assign someone or a group a permission or role on a model.
>>
>> Not wanting to get into a terminology discussion, but I'd call these
>> "model-based grants". This is a feature of Grok's default security
>> policy, zope.securitypolicy. By model-based security I meant
>> attribute-level protections on models.
>
> I'm talking about marketing here. I'd prefer to call the model based
> grants "model based security", or "model-level permissions". This is for
> the reason that if you talk to someone who has no idea that security
> proxies even exist (most Python programmers out there), "Grok needs
> model-based security" means to him that Grok has no model-based grants
> yet. But Grok/Zope 3 actually has a very powerful system for this,
> probably more powerful than all competing web frameworks. We should be
> careful to emphasize Grok's powerful security model and not accidentally
> give people the impression that it doesn't.

Good points. Let's call the todo list item "Protecting models with
permissions" then.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Leonardo Rochael Almeida]

Hi,

On Wed, Jul 30, 2008 at 11:04, Philipp von Weitershausen
<philipp@...> wrote:

>> Philipp von Weitershausen wrote:
>>>
>>> [...]
>>> Not wanting to get into a terminology discussion, but I'd call these
>>> "model-based grants". This is a feature of Grok's default security policy,
>>> zope.securitypolicy. By model-based security I meant attribute-level
>>> protections on models.
>
> [...] Let's call the todo list item "Protecting models with
> permissions" then.

Why not "Protecting model members with permissions"?

obnoxiously-painting-other-people's-bykesheds-ly yours, Leo
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli]

Sylvain Viollon wrote:

> Hello,
>
> On Mon, 28 Jul 2008 22:39:05 +0100
> Martin Aspeli <optilude@...> wrote:
>
>
>> I can't really contribute, but I just wanted to say that this makes
>> me really, really excited. :)
>>
>> I think 0.14 sounds like the release where I would seriously consider
>> Grok for a project, and grokcore.view sounds like something Plone
>> badly needs. I'll buy anyone who works on it a beer at the Plone
>> conference if Grok-like views work by the time I give my talk. :)
>>
>
>    This work now in Silva, Grok-like views. You have almost nothing to
> do, just put some conventions for your application/framework saying you
> have to build your templates like that. Forms works quite well, with
> formlib. I should try to use z3c.form instead.

That's quite exciting!

>    I am building a demo extension, if you are interested:
>
>    https://svn.infrae.com/silva.app.blog/trunk
>
>    Thanks to Godefroid and Lennart for grokcore.views.

Mmmm.... is there any documentation on how to use this in plain Zope 2
(or Plone)? I'm getting confused by Silva stuff. ;-)

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@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Peter Bengtsson]

>
> Good points. Let's call the todo list item "Protecting models with
> permissions" then.

+1



--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Robert Gravina]

On 31/07/2008, at 8:14 AM, Martin Aspeli wrote:

> Sylvain Viollon wrote:
>> Hello,
>> On Mon, 28 Jul 2008 22:39:05 +0100
>> Martin Aspeli <optilude@...> wrote:
>>> I can't really contribute, but I just wanted to say that this makes
>>> me really, really excited. :)
>>>
>>> I think 0.14 sounds like the release where I would seriously  
>>> consider Grok for a project, and grokcore.view sounds like  
>>> something Plone
>>> badly needs. I'll buy anyone who works on it a beer at the Plone
>>> conference if Grok-like views work by the time I give my talk. :)
>>>
>>   This work now in Silva, Grok-like views. You have almost nothing to
>> do, just put some conventions for your application/framework saying  
>> you
>> have to build your templates like that. Forms works quite well, with
>> formlib. I should try to use z3c.form instead.
>
> That's quite exciting!
>

Indeed it is!

ZCML is dead! Long live the Grok!

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

[Jan Ulrich Hasecke-3]

Hi all,

the following is no answer to Roberts statement, I am quite sure that  
he does not meant it the way I understood it. It is addressed to the  
whole Grok community.

Am 31.07.2008 um 03:23 schrieb Robert Gravina:
> ZCML is dead! Long live the Grok!


I am more and more uneasy about these statements, though only about  
the first part. ;-)

If you get an application from someone else, you only have to look  
into the ZCML-files and you will soon understand the architecture of  
the application. The redundancy which violates the DRY-law, seems to  
me helpful if you read the application.

Writing ZCML sucks, but it sucks if you do it with vim, emacs or  
whatever editor you like. If we had a ZCML-aware IDE, it would be  
possible to build a valid ZCML-file with a few mouse clicks.

If you take the ZCML-files as a blueprint of your application, it  
seems to me a clean tool to master really big an complex  
applications. I cannot foster this with my own experience, but I've  
heard people say that ZCML saved their lives.

And from a marketing point of view these statements are really bad.  
How shall I solicit Zope, if more and more people tell me that the  
tool that hold all these components together sucks? How shall I  
convey trust to the public, if the Zope guys start to build up a new  
framework every five years?

Let Grok smash ZCML, it is nice to have more than one way to build  
web applications, but don't curse ZCML.

juh

--
DZUG e.V. (Deutschsprachige Zope User Group)
http://www.zope.de



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

[Robert Gravina]

On 31/07/2008, at 3:57 PM, Jan Ulrich Hasecke wrote:

> Hi all,
>
> the following is no answer to Roberts statement, I am quite sure  
> that he does not meant it the way I understood it. It is addressed  
> to the whole Grok community.
>
> Am 31.07.2008 um 03:23 schrieb Robert Gravina:
>> ZCML is dead! Long live the Grok!
>

I do appoligize for creating a stir with this. I didn't mean that ZCML  
is useless - in fact, I'm quite new to Zope3 so I shouldn't even be  
making statements like this... However, I don't enjoy writing ZCML (it  
does take *time* and duplicates what I've already stated in my code).  
If grokkers can handle 80% of the cases where convention could be used  
to register my adapters, utilities, views, templates etc. I think  
that's a good thing. I'm not sure if this means that this can't be  
configured by other users of the code.. is this the case?

Being able to override configuration is very powerful... perhaps I  
should learn a bit more about ZCML and the motivations behind it  
before declaring it dead :) I'll go dust off my copy of Weitershausen  
and spend some quality time with it I think :)


I'd really like to know more, so I'll ask a few questions here :

> If you get an application from someone else, you only have to look  
> into the ZCML-files and you will soon understand the architecture of  
> the application. The redundancy which violates the DRY-law, seems to  
> me helpful if you read the application.

Can't this be done be reading the source? If I look at interfaces.py,  
I can see the interfaces, if I look at the class I can see what it  
implements and adapts. With good API documentation, this is really  
easy (the Twisted people use a zope.interface aware documentation  
generator, have a look at their API docs. I've noticed the Grok admin  
does something similar too on the fly).


> Writing ZCML sucks, but it sucks if you do it with vim, emacs or  
> whatever editor you like. If we had a ZCML-aware IDE, i would be  
> possible to build a valid ZCML-file with a few mouse clicks.

Although I speak from total inexpereince here, many people criticise  
Java (and Java coders) for this... do we really want to rely on IDEs  
like Eclipse to generate code for us, or is this effort better spent  
in simplifying the process?

> If you take the ZCML-files as a blueprint of your application, it  
> seems to me a clean tool to master really big an complex  
> applications. I cannot foster this with my own experience, but I've  
> heard people say that ZCML saved their lives.

I can believe this, but I wonder if ZopeCA-aware API docs can't help  
here?

> And from a marketing point of view these statements are really bad.  
> How shall I solicit Zope, if more and more people tell me that the  
> tool that hold all these components together sucks? How shall I  
> convey trust to the public, if the Zope guys start to build up a new  
> framework every five years?

You are right, and it was foolish of me to make them.

Having said that, I think that Grok makes rapid web development  
possible in Zope 3 without skimping on quality.

> Let Grok smash ZCML, it is nice to have more than one way to build  
> web applications, but don't curse ZCML.

Indeed it is - but let's not have too many ways to do the same thing.  
(This is slightly offtopic but...) I'm developing in Plone right now,  
and I would prefer if there wasn't a Zope2 *and* a Zope3 way of doing  
just about everything. It's a real issue for me because it's very very  
hard to convince other programmers working alongside me, who are  
productive in doing things one way, to switch to another way  
regardless of the technical superiority or elegance of the Zope3  
approach.

Robert

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

[Peter Bengtsson]

I hate ZCML but I appreciate your point about understanding an
application by reading it but in Zope3 projects the ZCML gets quite
hairy and long quite quickly and it looses it value. If you need a
overview of the app, perhaps we can have a script or something that
inspects the files and the files content and from that works out a,
for example, ascii tree of how classes, interfaces and templates are
connected.

2008/7/31 Jan Ulrich Hasecke <juhasecke@...>:

> Hi all,
>
> the following is no answer to Roberts statement, I am quite sure that he
> does not meant it the way I understood it. It is addressed to the whole Grok
> community.
>
> Am 31.07.2008 um 03:23 schrieb Robert Gravina:
>>
>> ZCML is dead! Long live the Grok!
>
>
> I am more and more uneasy about these statements, though only about the
> first part. ;-)
>
> If you get an application from someone else, you only have to look into the
> ZCML-files and you will soon understand the architecture of the application.
> The redundancy which violates the DRY-law, seems to me helpful if you read
> the application.
>
> Writing ZCML sucks, but it sucks if you do it with vim, emacs or whatever
> editor you like. If we had a ZCML-aware IDE, it would be possible to build a
> valid ZCML-file with a few mouse clicks.
>
> If you take the ZCML-files as a blueprint of your application, it seems to
> me a clean tool to master really big an complex applications. I cannot
> foster this with my own experience, but I've heard people say that ZCML
> saved their lives.
>
> And from a marketing point of view these statements are really bad. How
> shall I solicit Zope, if more and more people tell me that the tool that
> hold all these components together sucks? How shall I convey trust to the
> public, if the Zope guys start to build up a new framework every five years?
>
> Let Grok smash ZCML, it is nice to have more than one way to build web
> applications, but don't curse ZCML.
>
> juh
>
> --
> DZUG e.V. (Deutschsprachige Zope User Group)
> http://www.zope.de
>
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev
>

--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev