[Zope-dev] Designs for zope2.zope.org available - Feedback welcome
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I happy to be able to present three different Designs for the upcoming Zope 2 microsite. All designs were developed by Alma Ong of Clearnoodle.com. Find the designs here http://zope2.zopyx.de/designs and please leave some comment until May 25th 2009. After that we will review the comments and make the final choice. We are: Robert Rottermann (Redcor) Gerhard Hug (Redcor) Alma Ong (Clearnoodle) Andreas Jung (ZOPYX) Alan Runyan (Enfold) Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknpfdwACgkQCJIWIbr9KYwypwCbBnsQ2bXFhrljWmjsfHTojUmZ bTsAoOXhofQJnUDDqzivTku88sYzJ2ZT =QoJU -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, On Fri, 17 Apr 2009 13:09:05 +0200 Fabio Tranchitella kob...@kobold.it wrote: To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. ZCA will be improved by ZTK, so I don't worry. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. For me, my main purpose is maintaing the ZMI as an application server on ZTK, because I find it still useful for maintenance/configuration on the spot for example. But making Zope3(though it is still ambiguous for me)/ZTK user- friendly sounds a very nice idea. I could imagine a lot of packages might makes beginners shrink a bit, although we already have nice books. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZF] Designs for zope2.zope.org available - Feedback welcome
On 4/18/09 3:14 AM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I happy to be able to present three different Designs for the upcoming Zope 2 microsite. All designs were developed by Alma Ong of Clearnoodle.com. Find the designs here http://zope2.zopyx.de/designs and please leave some comment until May 25th 2009. I tried to leave a comment on the design page but I can't register and anonymous commenting is disabled. Anyway, all of these designs are just fantastic. I don't have a clear preference. Thanks for the work Andreas and Alma! - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZF] Designs for zope2.zope.org available - Feedback welcome
Hi, [snip] Find the designs here http://zope2.zopyx.de/designs and please leave some comment until May 25th 2009. Very nice work. I have a preference for HomePage2.jpg or HomePage3.jpg. I tried to leave a comment on the design page but I can't register and anonymous commenting is disabled. Same problem. [snip] Kind regards, Ben. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZF] Designs for zope2.zope.org available - Feedback welcome
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.04.2009 9:27 Uhr, Chris McDonough wrote: On 4/18/09 3:14 AM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I happy to be able to present three different Designs for the upcoming Zope 2 microsite. All designs were developed by Alma Ong of Clearnoodle.com. Find the designs here http://zope2.zopyx.de/designs and please leave some comment until May 25th 2009. I tried to leave a comment on the design page but I can't register and anonymous commenting is disabled. Anonymous commenting is enabled...but...stupid Plone (or stupid me). You can login as comment/comment in order to leave comment (dirty workaround...no time for fixing this right now). Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknpg00ACgkQCJIWIbr9KYwuPwCffzz0cgn+52wUa1nFmWMlo7oF HNMAn2oSHrvklWXssksHqYTzZ7VCDq64 =1t9m -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi,
On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote:
Hi.
Uli Fouquet wrote:
As Grok is now approaching the 1.0 release we (i.e. some Grok developers
and me) want to have a 'compliant' way to offer paster-based serving of
Grok instances.
I'd love to have the same for Plone, but failed to find any canonical
definition of compliant the same way you did.
Here's a short (probably incomplete) list of some 'full-stack'
paster-capable 'frameworks' and how they invoke paster from the
commandline (please correct/extend if I am wrong/incomplete here):
===
Framework Ini-file locationPaster call
===
grokproject parts/etc/ bin/paster serve \
parts/etc/deploy.ini
repoze.bfg project root paster serve MyProject.ini
turbogears2 project root paster serve development.ini
pylons project root paster serve development.ini
zopeproject etc/bin/paster serve \
etc/deploy.ini
z3c.r.paster parts/app/bin/app
I'll add the current Plone 4 way:
Plone parts/instance/etc bin/instance-fg
where instance-fg is a wrapper that calls:
bin/paster serve parts/instance/etc/paste.ini
Some motivators for me, as I saw some of those variants around and some
input with my experience from the buildout business:
- As a Unix-Lover, I do appreciate starting services having a SYSV style
call, which means: (somecommand) start/stop/restart/...
Thus no calls that require me to remember a config file location and
pass it on.
This also means that (somecommand) needs to be configurable as I might
want to deploy multiple buildouts into the same machine having the
deployment options create the service scripts in /etc/init.d and thus
they can't all be called instance. Having it named myproject seems
better to me.
- Also, I do like my autocomplete to leave me with full command name
completions, thus: (somecommand)-ctl
(somecommand)-debug doesn't work well for me: I always have to start
typing again to complete the command *and* give a parameter.
(Remember that I want parameters so I have SYSV compatible init
commands right away)
- In a buildout environment, the use of .in files breaks the flexibility
that the various buildout mechanism deliver to us: extends, variable
inclusion, etc. have to be built again and again and again in the
recipes. We started out with zope3instance recipes that did that but
finally moved away from this.
- Do not make me check in generated things.
- If you'd like people that know things like paster to pick up our
environment easily, I think, that: make it obvious where the
deploy.ini Co went and as they are generated files, leave a visible
note at the beginning of the file, that states something like:
# NOTE: This file is generated by foo.recipe.paster, it will be
# overwritten. Please apply changes to your buildout configuration
# (located in XXX) instead of changing this file.
Another option I considered was the way zopeproject does it. Except that
I still have to give a path to an instance home in a zope.conf file,
which either needs to be filled in by buildout or otherwise '..' needs
to be handled correctly for the etc/ case.
If your buildout does the right thing, then you should be able to
abstract that complication away leaving only
- a reference to a configuration file
- maybe a working directory change
Christian
--
Christian Theune · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development
signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Designs for zope2.zope.org available - Feedback welcome
Andreas Jung wrote: Find the designs here http://zope2.zopyx.de/designs In order of preference: 1 3 2 cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] force the language for a particular template: solution
On Sat, Apr 18, 2009 at 12:34:19AM +0100, Chris Withers wrote: Hanno Schlichting wrote: Or attach a marker interface to the request and register a different IUserPreferredLanguages adapter for it. This won't quite work as I still need to get the language I'm forcing from somewhere. However, I realised I already had a custom IUserPreferredLanguages adapter on this project (to get the language from the user object, not the browser) so I added a bit of code in there. The simplest version of this would be: from zope.publisher.browser import BrowserLanguages class Languages(BrowserLanguages): def getPreferredLanguages(self): force = getattr(self.request,'_force_language',None) if force: return [force] return super(Languages, self).getPreferredLanguages() Then this zcml: adapter for=zope.publisher.interfaces.http.IHTTPRequest provides=zope.i18n.interfaces.IUserPreferredLanguages factory=.languages.Languages / ...and then you can do the following in a view: def __call__(self): def1 = self.template(self) self.request._force_language = 'de' Does this work? IIRC Zope 3 request objects use __slots__ and therefore cannot have any extra attributes imposed upon them from the outside. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Martijn Faassen wrote: You're right of course, I apologize for going that way. I have little excuse for that. You've taken a lot of heat in this thread. I hope that doesn't bother you too much, because I think you're an extremely valuable team member. This kind of discussion is hard, but it is an important part of any mature project. I find it rather encouraging that so many people are participating in this thread. Clearly, the Zope project has many dedicated contributors. I don't know how valuable my opinion about all of this is, but I'll suggest it in case it's useful. In my mind, I've been thinking of Zope Toolkit as the subset of Zope 3 that has well-managed dependencies. Zope 3 already has good code and excellent test coverage, but what's controversial about it is the mad package dependency graph as you reach inside zope.app. Given that definition, Zope Toolkit will start relatively small, since much of Zope 3 does not yet qualify. However, as people refine packages, the packages will be reconsidered for inclusion in the Zope Toolkit, and the Zope Toolkit will hopefully grow into something similar to what we currently know as Zope 3. Zope 3 can't die; people are relying on it and maintaining it. The maintainers are doing a rather good job too, IMHO. The checkins list has been active lately. We don't have to create any more Zope 3 tarballs, but we should keep up the KGS. The Zope Toolkit will be the subset that's good for building applications, web sites, and frameworks. Zope 3 will be designed only for building applications and web sites. I'll be able to recommend Zope Toolkit to friends without hesitation. They will be able to learn the ZTK in small steps because the dependency graph will be comprehensible. It will never be necessary to learn all of ZTK to be productive. Many will start with the ZTK and eventually realize they only need a small subset of ZTK. They will be happy when they discover how easy it is to use a subset of ZTK. Zope 3 is the thing I'll still recommend to people who decide they want to drink all of Zope in at once. Some people have good reasons to want that, after all. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi there, Christian Theune wrote: On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote: Hi. Sorry Hanno, your posting got lost on the way to my mailreader. I noticed you replied when reading Theuni's posting. Uli Fouquet wrote: As Grok is now approaching the 1.0 release we (i.e. some Grok developers and me) want to have a 'compliant' way to offer paster-based serving of Grok instances. I'd love to have the same for Plone, but failed to find any canonical definition of compliant the same way you did. Glad to hear that others have the same problems :) Here's a short (probably incomplete) list of some 'full-stack' paster-capable 'frameworks' and how they invoke paster from the commandline (please correct/extend if I am wrong/incomplete here): === Framework Ini-file locationPaster call === grokproject parts/etc/ bin/paster serve \ parts/etc/deploy.ini repoze.bfg project root paster serve MyProject.ini turbogears2 project root paster serve development.ini pylons project root paster serve development.ini zopeproject etc/bin/paster serve \ etc/deploy.ini z3c.r.paster parts/app/bin/app I'll add the current Plone 4 way: Plone parts/instance/etc bin/instance-fg where instance-fg is a wrapper that calls: bin/paster serve parts/instance/etc/paste.ini We thought about this as well. Some motivators for me, as I saw some of those variants around and some input with my experience from the buildout business: - As a Unix-Lover, I do appreciate starting services having a SYSV style call, which means: (somecommand) start/stop/restart/... Thus no calls that require me to remember a config file location and pass it on. This also means that (somecommand) needs to be configurable as I might want to deploy multiple buildouts into the same machine having the deployment options create the service scripts in /etc/init.d and thus they can't all be called instance. Having it named myproject seems better to me. I see. I am not sure, everybody has this requirement, but we should keep it in mind. The question here is: how do you name your commands then? Do you opt for (somecommand) --debug or similar in that case? - Also, I do like my autocomplete to leave me with full command name completions, thus: (somecommand)-ctl (somecommand)-debug doesn't work well for me: I always have to start typing again to complete the command *and* give a parameter. (Remember that I want parameters so I have SYSV compatible init commands right away) - In a buildout environment, the use of .in files breaks the flexibility that the various buildout mechanism deliver to us: extends, variable inclusion, etc. have to be built again and again and again in the recipes. We started out with zope3instance recipes that did that but finally moved away from this. Interesting. This, at least with Grok, can become a serious problem. We currently have five different configuration files generated by `grokproject`. Admitted, that one might skip one (`debug.ini`), we are left with four, which require three different configuration grammars: zope.conf, zdaemon.conf: ZConf grammar deploy.ini: ConfigParser grammar site.zcml: ZCML but this is a different topic. Some of those files (namely the .ini files) meanwhile have grown large defining loggers and all that. Putting them into buildout.cfg makes it nearly unreadable. It becomes even difficult to check, which part of the configuration you're currently watching. People with more advanced setups might run into even greater trouble. So, the pros and cons of external vs. buildout.cfg-embedded config files might read like this (for embedded configs): * pros: - supports all buildout mechanisms (namely: var interpolation and extend) - all configs in one file (you know where to look for them) * cons: - harder to read - confusing syntax (mix of at least three grammars) - impossible to split permissions on parts of the config With external configs it's the opposite picture. Can you tell more about the problems with zope3instance? - Do not make me check in generated things. Of course. As with buildout we _will_ have generated files (opposite to most other frameworks). This means that we cannot put flat ini files in the project/instance root (as they won't be flat files but generated ones). - If you'd like people that know things like paster to pick up our environment easily, I think, that: make it obvious where the deploy.ini Co went and as they are generated files, leave a visible note at the beginning
Re: [Zope-dev] Defining Zope 3.
On Thursday 16 April 2009, Tres Seaver wrote: I would rather that we stop pushing the Zope 3 brand now, I would rather keep the name Zope 3. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, I just start working on maintaining ZMI and make it optional package. For now, it is easy to participate, just porting zope.app.* (I already list up targets as directories in zmi.core) and make sure that existing tests succeeds. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
