[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sun Apr 20 11:00:00 2008 UTC to Mon Apr 21 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Apr 20 20:59:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009435.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 20 21:00:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009436.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 20 21:02:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009437.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 20 21:03:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009438.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 20 21:05:03 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009439.html ___ 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] Let's fix the damned website
Admittedly I ignored this, as these kinds of calls has gone out for years, and nothing happens. But this time it looks like it actually *will* happen, which is great. So here is my 2 centimes: On Sat, Apr 5, 2008 at 5:52 PM, Martin Aspeli [EMAIL PROTECTED] wrote: The rumours are true. :) An effort has been going on for a while to improve the zope.org experience and thereby help make Zope more accessible to new users. Yay! - A great design by Oliver Ruhm, paid for by Lovely Systems - A Plone 3 site hosted by Lovely Systems - A skin for this site by Denis Mishunoff - A skeleton content structure - A plan for going forward Yay! - Projects gives an explanation of how the different Zope projects fit together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a subfolder that contains a standard structure: A front page that explains the project in more detail, Get (downloads), Taste (as above, but for a particular project) and Learn. The Learn section should contain relevant, up-to-date documentation. No! Each project should have it's own site. Like Grok has today. The Projects page which explains what they are and how they fit together is fine, but the different subparts will necessarily have to be maintained by slightly different people with slightly different requirements. We can set up rules so that both zope.org/Projects/grok and grok.zope.org point to the same physical place, but it is extremely important that we do not, once again, try to make a monolithic zope.org. Microsites, microsites, microsites! - Foundation links to the Foundation site for now. If the Foundation website maintainers want to move into this site in the future, they are of course more than welcome to. See above. Grok has its own home page, though I think we should keep referring to it where it makes sense. Which is always. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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] Let's fix the damned website
Lennart Regebro a écrit : Microsites, microsites, microsites! If there are lots of people wanting to set up a bunch of microsites, I agree it would be better to have them. However, the site is needed for a long time and it's been six month since the new project started and we have just a design and a few paragraphs of contents. So let's just build a first nice zope.org with subfolders explaining the different projects because it's important to have just *something*. At least. If we take the ZODB as an example, I have started writing a small introductory text in the /projects/zodb page (and an image). The goal of this page is not to be the main place for zodb activity but just to introduce the zodb as a part of the zope project and how it can be used with zope. This does not prevent from having a zodb.zope.org site and linking to it... if someone ever begins to build one. Christophe - Foundation links to the Foundation site for now. If the Foundation website maintainers want to move into this site in the future, they are of course more than welcome to. See above. Grok has its own home page, though I think we should keep referring to it where it makes sense. Which is always. ___ 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 )
[Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
Baiju M wrote: Paul Carduner wrote: Log message for revision 85449: creating a branch to see what I can do about extjs integration. Is Paul Carduner paying attention to this thread? He's still continuing to check in code that uses ExtJS. Granted we don't *distribute* ExtJS, but we're still writing framework code that uses ExtJS, and this goes against the principle of being able to use things in svn.zope.org under the license constraints of the ZPL. I cc-ed Paul. Regards, Martijn ___ 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.org Redux] Re: [Zope-dev] Let's fix the damned website
On 21 Apr 2008, at 11:53 , Martin Aspeli wrote: - Projects gives an explanation of how the different Zope projects fit together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a subfolder that contains a standard structure: A front page that explains the project in more detail, Get (downloads), Taste (as above, but for a particular project) and Learn. The Learn section should contain relevant, up-to-date documentation. No! Each project should have it's own site. Like Grok has today. The Projects page which explains what they are and how they fit together is fine, but the different subparts will necessarily have to be maintained by slightly different people with slightly different requirements. We can set up rules so that both zope.org/Projects/grok and grok.zope.org point to the same physical place, but it is extremely important that we do not, once again, try to make a monolithic zope.org. Microsites, microsites, microsites! Does it really matter whether a microsite lives in zope.org/projects/zodb or zodb.zope.org? If you look at the projects now, they each have a common set of sections - download, examples, documentation - and will be allowed to evolve independently. They also have the option of having some specific branding (logo, tag-line etc) as required. If anyone steps up and wants to maintain a separate site for one of the projects, then all the better. However, it is hard enough to get contributors as-is, so I'm loth to do anything that increases the maintenance or setup burden in any way until we have at least the basics in place. I agree with Martin. We need to stop the balkanization of Zope-the- brand. Yes, we have many individual projects, but we need a coherent image to the outside world. Microsites was a good idea to get foundation site and the Grok site up and running *before* tackling zope.org, but in the long run, we need coherence. Also, to be honest, I don't find the design of the new Grok website very attractive. And the foundation site is simple enough to be folded back into the main site. ___ 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
On 19 Apr 2008, at 22:39 , Chris McDonough wrote: Philipp von Weitershausen wrote: Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). I'd be slightly happier if everything we (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The one big egg strategy might also let us explain it a little more easier to old- hand Zope2 devs who aren't used to eggs: everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg. Then in a subsequent Zope 2 egg release, we could say oh, now that you're used to eggs, we've moved DateTime out into a separate egg, so on and so forth. Ok, fine by me. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. Which they're not :). We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost meta-egg (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, Zope2 sounds good to me. Well, taking your everything that used to be in the tarball... argument, then this would indeed be the outmost egg, incl. the instance scripts. A nit: I might call the outermost egg zope2 because I have a preference for lowercase egg names and we also already have a *package* named Zope2, and it'd be nice to know where you are at the bash prompt without needing to print the whole path. I have a slight preference for Zope2 because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with Zope2. ___ 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Mon, Apr 21, 2008 at 7:45 AM, Baiju M [EMAIL PROTECTED] wrote: It looks like today they changed their licence to GPL v3 ! I don't know if that exclamation mark is of joy or woe. I vote for woe. -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Philipp von Weitershausen wrote: I'd be slightly happier if everything we (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The one big egg strategy might also let us explain it a little more easier to old-hand Zope2 devs who aren't used to eggs: everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg. Then in a subsequent Zope 2 egg release, we could say oh, now that you're used to eggs, we've moved DateTime out into a separate egg, so on and so forth. Ok, fine by me. Cool. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. Which they're not :). We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost meta-egg (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, Zope2 sounds good to me. Well, taking your everything that used to be in the tarball... argument, then this would indeed be the outmost egg, incl. the instance scripts. True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from stock Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. A nit: I might call the outermost egg zope2 because I have a preference for lowercase egg names and we also already have a *package* named Zope2, and it'd be nice to know where you are at the bash prompt without needing to print the whole path. I have a slight preference for Zope2 because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with Zope2. Alright. I'm excited about this. ;-) - 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 )
[Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Apr 21, 2008 at 7:45 AM, Baiju M [EMAIL PROTECTED] wrote: It looks like today they changed their licence to GPL v3 ! I don't know if that exclamation mark is of joy or woe. I vote for woe. I don't know if woe is necessarily fight: given that we are talking about a component which is served separately from any of our Python code, without even the (debatable) trigger of a Python import to cause our code to be a derived work, the mere aggregation clause is likell to apply to distributing ExtJS with a ZPLed Python library / application. Having an unambiguous FOSS license on the code has to be good news for those who would like to build and distribute such components. ZMySQLDA, for instance, is a ZPLed component which depends on the non-ZPL MySQL client libraries, which doesn't seem to cause problems. We *still* can't put the ExtJS code itself into svn.zope.org, but perhaps we can now allow checking in ZPLed code which uses it. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDMer+gerLs4ltQ4RAoitAKCInTMTm9UtiT3ozR/uNeHjgWk5NgCdH79p 7pKs77KEHSE6/6WCWWNzg6I= =aM4/ -END PGP 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Hi. Chris McDonough wrote: True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from stock Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore. While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO. Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do? Hanno ___ 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Apr 21, 2008, at 12:58 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Apr 21, 2008 at 7:45 AM, Baiju M [EMAIL PROTECTED] wrote: It looks like today they changed their licence to GPL v3 ! I don't know if that exclamation mark is of joy or woe. I vote for woe. I don't know if woe is necessarily fight: given that we are talking about a component which is served separately from any of our Python code, without even the (debatable) trigger of a Python import to cause our code to be a derived work, the mere aggregation clause is likell to apply to distributing ExtJS with a ZPLed Python library / application. We're not just talking about Python code. We're also talking about Javascript code. We'll be providing JS code that runs in the browser with and depends on the Ext code. My library did and Paul's changes did. Reading the GPL3, The language is very broad. It talks about works based on GPL works being GPL. In: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation , the FAQ talks about programs communicating via interprocess communication. In particular: But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. It would be easy, IMO, and useful for a Python framework to generate data structures that are meant to be consumed by Ext. For example, my from framework returns Ext field definitions as JSON. Having an unambiguous FOSS license on the code has to be good news for those who would like to build and distribute such components. I don't find anything about the GPL to be unambiguous unless I read it with the broadest, most paranoid interpretation. ZMySQLDA, for instance, is a ZPLed component which depends on the non-ZPL MySQL client libraries, which doesn't seem to cause problems. Good point. I think we were sloppy here and it probably does cause problems. I think we probably should remove this from the repository. We *still* can't put the ExtJS code itself into svn.zope.org, but perhaps we can now allow checking in ZPLed code which uses it. No, we can't. I am willing to be overridden by the Foundation Board on this. Absent that, consider this an edict. :) Jim -- Jim Fulton Zope Corporation ___ 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Apr 21, 2008, at 12:58 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Apr 21, 2008 at 7:45 AM, Baiju M [EMAIL PROTECTED] wrote: It looks like today they changed their licence to GPL v3 ! I don't know if that exclamation mark is of joy or woe. I vote for woe. I don't know if woe is necessarily fight: given that we are talking about a component which is served separately from any of our Python code, without even the (debatable) trigger of a Python import to cause our code to be a derived work, the mere aggregation clause is likell to apply to distributing ExtJS with a ZPLed Python library / application. We're not just talking about Python code. We're also talking about Javascript code. We'll be providing JS code that runs in the browser with and depends on the Ext code. My library did and Paul's changes did. Reading the GPL3, The language is very broad. It talks about works based on GPL works being GPL. In: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation , the FAQ talks about programs communicating via interprocess communication. In particular: But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. It would be easy, IMO, and useful for a Python framework to generate data structures that are meant to be consumed by Ext. For example, my from framework returns Ext field definitions as JSON. An application returning JSON data structures for consumption by the Ext libraries would hardly be a derived work from Ext: copyright doesn't control that kind of integration, or else we would have to forbid use of Python standard modules which provide interfaces to glibc. The GPL can't control what copyright law does not provide for. In particular, copyright allows regulation of creation and distribution of derived works, but it does *not* allow the copyright holder to make up arbitrary definitions about what makes a given work derived or not: that would be up to the courts. Having an unambiguous FOSS license on the code has to be good news for those who would like to build and distribute such components. I don't find anything about the GPL to be unambiguous unless I read it with the broadest, most paranoid interpretation. Compared with where the licensing was *before* they labeled it GPL3, the clarity is vastly improved. ZMySQLDA, for instance, is a ZPLed component which depends on the non-ZPL MySQL client libraries, which doesn't seem to cause problems. Good point. I think we were sloppy here and it probably does cause problems. I think we probably should remove this from the repository. I disagree. The dependency is clearly on the presence / dynamic linkability of the non-ZPL code, and does not appear to create a derived work at all. We *still* can't put the ExtJS code itself into svn.zope.org, but perhaps we can now allow checking in ZPLed code which uses it. No, we can't. I am willing to be overridden by the Foundation Board on this. Absent that, consider this an edict. :) OK. Nolo contendere. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDSnJ+gerLs4ltQ4RAuzuAJ0X0b7DrNUN3/D5LFRbPqYQn9dbUgCZAcmb WFuGNyc3deRq20PIc9zWceY= =0sTf -END PGP 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 )
[Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
Jim Fulton wrote: [snip] We *still* can't put the ExtJS code itself into svn.zope.org, but perhaps we can now allow checking in ZPLed code which uses it. No, we can't. I am willing to be overridden by the Foundation Board on this. Absent that, consider this an edict. :) Actually we briefly discussed this in a board meeting today, unrelated to this topic. I think the general principle of the repository should be that if you check out something, you can use it under the terms of the ZPL, and it won't pull in something with more restrictive clauses that affect your larger application. I don't think we've codified this principle anywhere yet, so perhaps we should. This is why depending on GPL-ed code should be avoided. Depending on, say, something LGPL-ed or MIT licensed would be fine. Note that I'm not speaking from any particular biased against GPL - I accept that projects use it and it's an appropriate license. Regards, Martijn ___ 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] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Hanno Schlichting wrote: Hi. Chris McDonough wrote: True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from stock Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore. While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO. Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do? repoze.zope2 doesn't use any of the instance-file-creation stuff in Zope. So far we haven't much want to either, because creating instances is pretty easy. Also, because repoze.zope2 depends on PasteScript, we have the opportunity to use paster create to create repoze.zope2 instances. Although we don't yet do that, that might be the natural way for us to go if we did want to use any framework to create instances. But paster create would probably not be a reasonable way to generate instances for plain old Zope, because it would form a dependency on PasteScript, which Zope 2 doesn't currently need otherwise. But with that in mind, I think we would be happiest if there was an egg that could be installed that got all the Zope libs but which didn't subsequently install instance creation / instance management console scripts (back to the zope2libs idea..). Might that also be the case for Plone? - 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 )
[Zope] Re: anyone heard of Zamasing?
Tim Nash wrote: find a way to upload the zexp to the wiki but I don't see how to do You're absolutely right, I forgot we restricted this to authenticated users when junk uploads became a problem. I did the upload and changed the link. Contact me for a wiki.zope.org login so you can do more uploads, or you may prefer to just link to your site. Thanks for sharing this example! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] AJAX / HTML Fragment
I'm writing my website to use AJAX for form posting and displaying content,
and instead of using AJAX to parse XML and then update the DOM, I'm using
Zope to create an HTML fragment and AJAX just writes it to the correct
location on the page. It works really great for what I'm doing, but the only
problem is that I get an error message:
Error: no element found
Source File: http://myzopesite:8080/mywebsite/zz/NewNote
Line: 1
NewNote is the location of the Python script which just posts the content to
a database (it actually execs a stored procedure)...
If I set the zsql query to select 1 as true at the end, that makes the
error go away. That leads me to believe something in the javascript is
wrong, so here's the relevant part of the javascript:
$.post('NewNote',{py_projectid: projectid,py_who: userName,py_note: note},
function()
{ // it saved. update display
$('#theNotes').load('AJX_ListNotes?projectid='+ projectid);
}
It is using jQuery, but I had it setup before as just a plain javascript,
but I still had the same problem. So, why would I get a No element found
on a POST query? Here is the content of the python script. It's as basic as
you can get:
return container.addnote(projectid=py_projectid, who=py_who,
note=py_note)
That is the only thing which expect a return value. If I change that to
this:
container.addnote(projectid=py_projectid, who=py_who, note=py_note)
return 1
I don't get any error messages, but the update display never happens. So,
I'd like to have no error messages, and I'd also like not having to pollute
my zsql queries with stupid things like select 1 as true. Any ideas on how
to accomplish that?
--
Thanks,
Derek Wilson
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] AJAX / HTML Fragment
On Mon, Apr 21, 2008 at 8:17 PM, SpiderX [EMAIL PROTECTED] wrote: I'm writing my website to use AJAX for form posting and displaying content, and instead of using AJAX to parse XML and then update the DOM, I'm using Zope to create an HTML fragment and AJAX just writes it to the correct location on the page. It works really great for what I'm doing, but the only problem is that I get an error message: Error: no element found Source File: http://myzopesite:8080/mywebsite/zz/NewNote Line: 1 Use Firefox and Firebug or LiveHTTPHeaders to see exactly what is going over the wire; you can also use command line tools like curl to recreate the request to debug what is going on on the zope and browser sides. Zope itself has very little to do with Javascript; once it serves the JS all the requests look the same to Zope regardless of how they were generated. -- Martijn Pieters ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: anyone heard of Zamasing?
The tecnique showed by Tim is the same I use at Zope Smart Manager but I prefer prototype and scriptaculous. At this time the most active community is, perhaps, RoR and they use the same libraries And when I use a Zope manage page like the constructor of a product I use ModalBox to show it as a dialog box I like to put in ZSM a drag and drop option to sort the ordered folder objects, to launch the creation dialog and delete object to a trash (I need scriptaculous for things like this) It's amazing what you can do with AJAX! (prototype is the library used) I don't want to program anything else like a desktop program (in fact I believe that the next desktop will be a http server) 2008/4/21, Simon Michael [EMAIL PROTECTED]: Tim Nash wrote: find a way to upload the zexp to the wiki but I don't see how to do You're absolutely right, I forgot we restricted this to authenticated users when junk uploads became a problem. I did the upload and changed the link. Contact me for a wiki.zope.org login so you can do more uploads, or you may prefer to just link to your site. Thanks for sharing this example! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Mis Cosas http://blogs.sistes.net/Garito Zope Smart Manager http://blogs.sistes.net/Garito/670 ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
