[Framework-Team] Re: Plone 4 - holidays are over :)
Hanno Schlichting wrote: 1.8 (2008-04-05) Added console command to the instance script, which is equivalent to fg but does not implicitly turn on debug mode but respects the zope.conf setting. [hannosch] One month later we changed it not to fork a process internally, so this is what we've been using for supervisord configurations for years. I've updated http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/creating-a-buildout-for-your-project to reflect the availability of this command: Running: bin/instance console is equivalent to bin/instance fg, but does not implicitly turn on debug mode but respects the debug-mode setting in buildout.cfg. This can be useful to run Zope in non-development mode with daemon-control programs like supervisord. I hope it's ok. :) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 - holidays are over :)
2010/1/6 Alex Clark acl...@aclark.net: On 2010-01-05, Martin Aspeli optilude+li...@gmail.com wrote: Hanno Schlichting wrote: A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. Eh, how do you guys start an instance without the forced debug mode of fg? You don't use start for that, do you? I guess I never do that. :) Since when have we had that? Since we use buildout or to be more precise, April 2008. Let me quote the PyPi page: 1.8 (2008-04-05) Added console command to the instance script, which is equivalent to fg but does not implicitly turn on debug mode but respects the zope.conf setting. [hannosch] One month later we changed it not to fork a process internally, so this is what we've been using for supervisord configurations for years. Heh, good. :) I've been using a lower level script (run.py or something, deep inside Zope) in supervisord that I guess does the same thing. So are they the same or not? If so, then we can stop feeling like idiots for missing 'bin/instance console' and continuing to use runzope ;-) I'm getting the impression 'bin/instance console' is just a convenience. Since plone.recipe.zope2instance puts the egg paths in the instance zope.conf, parts/instance/bin/runzope should be equivalent I think. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] incorrect URL for repoze.xmliter?
I just tried running the Plone 4 coredev buildout ( http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter= svn svn+ssh:// rep...@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter= svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 Nate ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: incorrect URL for repoze.xmliter?
Nate Aune wrote: I just tried running the Plone 4 coredev buildout (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter= svn svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk http://rep...@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter= svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 This happens because you don't have commit privileges in the repoze svn. Leaving it with the public URL is better, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 - holidays are over :)
On Wed, Jan 6, 2010 at 1:52 PM, Laurence Rowe l...@lrowe.co.uk wrote: 2010/1/6 Alex Clark acl...@aclark.net: So are they the same or not? If so, then we can stop feeling like idiots for missing 'bin/instance console' and continuing to use runzope ;-) I'm getting the impression 'bin/instance console' is just a convenience. In the end both of them prepare an OS environment and execute Zope2/Startup/run.py. The main difference is that bin/instance is easier to type and is a Python script. sh parts/instance/runzope is a Unix shell script, so it's not available on all platforms. And in the zope2instance version used for Plone 4 runzope does no longer exist. Since plone.recipe.zope2instance puts the egg paths in the instance zope.conf, parts/instance/bin/runzope should be equivalent I think. Not quite. The recipe used to construct a Python path and put it into runzope ;-) But luckily we don't have to do that anymore, as buildout takes care of all that script generation stuff and constructing the right sys.path for us. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 - holidays are over :)
Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. Steve On Mon, Jan 4, 2010 at 11:42 AM, Hanno Schlichting ha...@hannosch.euwrote: Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: ... JS dialogs #9805, #9806, #9921, #9693, #9957, #9964, #9977 All of these essentially mean that an operation done in a pop-up doesn't redirect and reload a new page. So any kind of feedback (positive, reconfirmation and failures) is lost. The other problem is that the original page (shown in the background of the dialog) might show information that is changing as a result of the dialog action. For example publishing an object in a dialog, needs to refresh the page, as its workflow state needs to be reflected, the item might now show up in the navigation tree, a calendar or any other type of portlet. It's a bit sad to see these problems, as we have already encountered all of them, when first applying AJAX/KSS in the early Plone 3 stages. We ended up reverting to a non-AJAX UI for most things, as almost all of our UI actions can have arbitrary effects. I'm afraid that we need to re-evaluate all actions that use the new dialogs and discuss them. We haven't had a PLIP review of the individual dialogs. I think we have missed to pass on the hard earned knowledge learned from the early Plone 3.0 days, but luckily it's not too late. ...__ _ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 - holidays are over :)
On Jan 6, 2010, at 2:02 PM, Steve McMahon wrote: Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. Steve Thanks for the update, Steve. Let me know if there's anything I can do to help. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: incorrect URL for repoze.xmliter?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Nate Aune wrote: I just tried running the Plone 4 coredev buildout (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter= svn svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk http://rep...@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter= svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 This happens because you don't have commit privileges in the repoze svn. Leaving it with the public URL is better, though. Why depend on SVN checkouts, rather than working to get the package released? Martin, you are the last one to touch it, looks like. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktE8N8ACgkQ+gerLs4ltQ5MigCdEgyuq5kEJfdVXNPix/SqiR9n TpIAoKrtxuqbdMGmg3UhJXUWWGVX2S+X =Hyv/ -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: incorrect URL for repoze.xmliter?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Nate Aune wrote: I just tried running the Plone 4 coredev buildout (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter= svn svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk http://rep...@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter= svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 This happens because you don't have commit privileges in the repoze svn. Leaving it with the public URL is better, though. Why depend on SVN checkouts, rather than working to get the package released? Martin, you are the last one to touch it, looks like. There is nothing in proper Plone that depends on this. experimental/deco.cfg is only really to be used by the Deco developers and is pretty rough still. A release would be good, it just isn't the top of the list. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
