gmane.comp.web.zope.grok.devel

Re: a Grok 1.0 release plan

Wichert Akkerman — 2008-12-01T23:04:27

I'm not sure of those media would appreciate a list of their contacts being kept in a public location. Wichert.

Re: About plugged templates... bug or coming soonfeature??

Santiago Videla — 2008-12-01T20:40:21

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

Re: About plugged templates... bug or coming soonfeature??

Lennart Regebro — 2008-12-01T19:18:52

Possibly, or there is a bug. Which is impossible to say unless I can check out your code. Do you have it somewhere?

Re: megrok.genshi

Lennart Regebro — 2008-12-01T19:16:53

Me.

Re: Problems serving iepngfix.htc for transparent PNG inIE6

Sebastian Ware — 2008-12-01T19:05:46

I gave up on trying to serve iepngfix.htc. Using this solution instead: http://www.komodomedia.com/blog/2007/11/css-png-image-fix-for-ie Mvh Sebastian 1 dec 2008 kl. 19.27 skrev Sebastian Ware:

Re: Problems serving iepngfix.htc for transparent PNG inIE6

Sebastian Ware — 2008-12-01T18:27:46

Thanks, but I am still struggling. Don't know how to affect the content type served from the static folder. If anyone has ha complete recipe for this problem it would be great. PNG-transparency is kind of important stuff... Mvh Sebastian 1 dec 2008 kl. 18.22 skrev Leonardo Rochael Almeida:

About plugged templates... bug or coming soon feature??

Santiago Videla — 2008-12-01T18:03:25

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

Re: Problems serving iepngfix.htc for transparent PNG inIE6

Leonardo Rochael Almeida — 2008-12-01T17:22:25

I believe the solution to your problem goes through the following tidbit I found while reading the instructions for [1]: "you may have a MIME type problem. You must ensure your server is sending the correct MIME type of "text/x-component" for .HTC files". [1] http://www.twinhelix.com/css/iepngfix/ Cheers, Leo On Mon, Dec 1, 2008 at 14:38, Sebastian Ware urbantalk.se> wrote:

Problems serving iepngfix.htc for transparent PNG in IE6

Sebastian Ware — 2008-12-01T16:38:13

I need to use the PNG-transparency fix which involves using a .htc file that is executed by IE5.5&6. I want to place iepngfix.htc in the static folder in order to avoid having to create a specific rewrite rule for nginx. However, I have been trying to get this to work and it seems as though Grok won't deliver the .htc-file out of the static folder in a way that works with IE. Question: 1 Has anyone succesfully used the iepngfix.htc solution with Grok? 2 How did you do it? Mvh Sebastian

Re: a Grok 1.0 release plan

Jan Ulrich Hasecke — 2008-12-01T13:32:55

Am 01.12.2008 um 14:20 schrieb Martijn Faassen: Maybe something, we can export as excel. juh

Re: a Grok 1.0 release plan

Martijn Faassen — 2008-12-01T13:20:08

Hey, Jan Ulrich Hasecke wrote: Great! We don't have such a list yet. Would a document on grok.zope.org with a list of addresses and such be a good start? Regards, Martijn

Re: a Grok 1.0 release plan

Jan Ulrich Hasecke — 2008-12-01T11:41:48

Hi all! Am 28.11.2008 um 17:08 schrieb Martijn Faassen: I can do the press release, at least writing the draft. Is there any international distribution list? The DZUG e.V. is maintaining a german distribution list but we have no list for international press releases. It would be nice if we had at least an online maintained list of email addresses for the most important media. juh

Re: a Grok 1.0 release plan

Martijn Faassen — 2008-12-01T09:37:46

Great! Note that Michael Haubenwallner, who did the WSGI work with Grokproject, already modified the documentation for grokproject. It'd be very good if you could review what's there. Michael said he'd update the Grok tutorial with the new instructions concerning how you start up Zope with paster (I think it also needs a sidebar on the soon-to-be-old way using zopectl). He hasn't gotten around to it yet though, so perhaps you can take a look at that. What would be really nice if someone would write the following two new documents for grok.zope.org: * a document that runs through the main paster commandline features * a document that describes how you can use WSGI components with a Grok application. I think there are two use cases - the optional WSGI components you can plug in by editing paster's ini file, and the 'baked-in' WSGI components that the application requires to function. The latter may not be proper pure WSGI components but they *are* popular, so we should have a canonical way of including them in our apps. Regards, Martijn

Re: a Grok 1.0 release plan

Todd — 2008-12-01T08:29:20

Hi Martijn, I'd like to get involved in this one: bug manager. I'm hoping someone will step up who watches the mailing list, irc, and makes sure we have bug reports in launchpad, and then shepherds the developers to actually do something about the bugs so we can close them. Todd Matsumoto

Re: megrok.genshi

Martijn Faassen — 2008-12-01T08:19:54

Hi there, I haven't seen any checkins with the fixes for Grok 0.14 in the megrok.genshi project - what's the holdup? Regards, Martijn

Re: a Grok 1.0 release plan

Jan-Wijbrand Kolman — 2008-11-30T18:25:33

Yes! Sylvain is waiting for feedback. I plan to have a look tomorrow and report back to him. This needs more attention, hopefully we can pair on this for a couple of hours? In principle yes, however I hope faassen and I can find a moment together before that date to pair on the template-inheritance-stuff. Sure, I'd be happy to do that! regards, jw

Re: a Grok 1.0 release plan

Carlos de la Guardia — 2008-11-30T03:24:46

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

Re: a Grok 1.0 release plan

Martijn Faassen — 2008-11-29T12:43:57

Hey, Brandon Craig Rhodes wrote: One of the problems with docstrings in Zope 3 code is that we tend to place them in interfaces.py. Would you duplicate things? Very long ago in Zope 3 we'd put in a marker that said "see .interfaces.IFoo.bar" for every method, but that's rather ugly and hard to maintain. An automatic introspector can automatically associate the docstring on a method on an interface with the method itself of the class that implements the interface. Whether this happens in practice is another discussion. :) Sure - this is a low-risk enhancement. I'd limit your efforts to grok, grokcore.*, grokui.* and martian - let's not delve into zope.* land. :) We don't have the attitude that docstrings are a bad idea or that code should be clear enough by itself: we have docstrings in interfaces. We also have a lot of doctests that hopefully say something about the code as well. I propose you add docstrings to methods where the method isn't already defined in an interface with a proper docstring there. Consider at each point whether this is actually something that should be added to the interface instead; we might've forgotten some methods or attributes in places. If the method on the interface already has a docstring, I propose you just say: "see ", where is an interface that this class implements (either directly or through a subclass relationship). I think a marker like this is better than nothing at all, as at least that gives a hint to the reader what's going on, and the docstring adder won't then accidentally add a docstring. :) You can also add docstrings to most classes - sometimes the class will implement a single interface that will contain the bulk of the explanation, but that is the general explanation of the interface, and doesn't explain why that particular class is there implementing it. Regards, Martijn

Re: a Grok 1.0 release plan

Brandon Craig Rhodes — 2008-11-29T04:22:33

I note that most of the Grok code that I have seen violates PEP-8 by being almost entirely devoid of docstrings (not to mention comments). I have been thinking about going through and adding some simple docstrings to make it easier for both newcomers to the code, and us old-timers with bad memories. Is this something I should try doing before 1.0? What is the Zope approach toward docstrings - are they frowned upon? From the almost entire lack of them in Zope code, I wondered if they were considered a bad idea, and if the code was supposed to "just be clear enough" that no docstrings were needed to define what things do. But, if it were up to me, I'd like the code to have docstrings, and I'm willing to add them - but can put my efforts elsewhere if everyone else thinks that's a waste. ;-)

Re: a Grok 1.0 release plan

Sylvain Viollon — 2008-11-28T16:17:48

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

a Grok 1.0 release plan

Martijn Faassen — 2008-11-28T16:08:29

Hi there, I think we should consider calling the next release of Grok Grok 1.0. I would like to put us through an alpha and beta phase however, for two reasons: * we have a number of potentially disruptive changes we'd like to get some feedback on before we release. * 1.0 pre-releases for 1.0 are good marketing. We should announce these loudly to get people to think about Grok. The bigger changes I'm aware of are: * new grokproject that uses paster and WSGI. This is done, but needs to be tested heavily. Existing documentation needs to be modified and we need 'best practices' documentation that describe how you'd actually use all the WSGI goodness in your application. This change is by far the biggest one to land in a 1.0 release. Opinions on how to manage this? * grokcore.viewlet extraction - the extraction is done but the core isn't modified yet, correct? Sylvain, what's the status of that work? * refactoring grokcore.view to support improved view inheritance. JW and I have been working on this. I propose the following release plan: monday december 15: Grok 1.0 alpha Features: all of the above. Documentation doesn't need to be ideal yet for WSGI, but basic tutorial and dev notes should have been adjusted. wednesday january 7: Grok 1.0 beta Features: improved documentation, bugfixes based on issue tracker and alpha feedback. wednesday january 21: Grok 1.0rc1 release Features: documentation on grok.zope.org is up to date with 1.0 stuff. This will be identical to the release if we can get away with it. wednesday january 28: Grok 1.0 release Hopefully practically identical to rc1. We will then continue with Grok 1.x development - things that I want to publish soon is megrok.rdb and the hurry.resource javascript/css resource handling framework. We need volunteers in various roles: * release manager. I'm hoping JW will step up again in this role. * documentation release manager: I'd like a separate role where someone prepares the documentation on grok.zope.org and grok/trunk/doc for the release. This would be mostly a documentation editing role. * bug manager. I'm hoping someone will step up who watches the mailing list, irc, and makes sure we have bug reports in launchpad, and then shepherds the developers to actually do something about the bugs so we can close them. * PR lead: It'd be great if we had someone to write press releases and send them to various places. I volunteer in the role of General Nag during the release process to make sure everything stays on track. :) Feedback? Opinions? Changes to the release plan? Some inside information for those who read as far as this: a small group is also going to gather in late january at my place to consider larger low-level changes that I'll dub "Grok 2.0". We'll do our best to see about introducing these changes gradually in Grok 1.x releases instead, though, but the idea is to open up the floor for some radical rethinking of some low-level bits to make the insides of Zope 3 and Grok simpler and easier to understand. Less firmly planned is that we're also hoping to gather in a bigger sprint sometime next year. Regards, Martijn