[Grok-dev] Re: 0.14 todo list
Philipp von Weitershausen
philipp at weitershausen.de
Mon Jul 28 19:21:17 EDT 2008
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:
> * 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,
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?
> 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.
More information about the Grok-dev