Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 9
its good for specific application deployments, as intimately tied to the appserver its bad, since it dictates deployment requirements to have a xul capable client, ie. non standard, defacto or otherwise. -kapil On Tue, 06 Dec 2005 07:26:30 -0800, Fabrice Monaco [EMAIL PROTECTED] wrote: For the backend (manage) this isn't problem. i have just one suggestion FireFox+xul+Zope is good ? -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED] Sent: mardi 6 décembre 2005 16:07 To: [EMAIL PROTECTED] Cc: zope3-dev@zope.org; Fabrice Monaco Subject: Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 9 Stephan Richter wrote: On Tuesday 06 December 2005 09:44, Fabrice Monaco wrote: Why not XUL? Because it sucks and is browser-specific. Be careful, or you'll have Paul in tears ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/hazmat%40objectrealms.net -- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] xml import / export in z2 z3
fwiw, we're working on doing this in plone land, utilizing the non standard, fast, incremental, validating XmlReader interface from libxml and pluggable namespace handlers. the xmlreader iface is very SAX like. http://svn.plone.org/view/archetypes/Marshall/branches/k_vertigo-pluggable-ns/ -k On Wed, 07 Dec 2005 06:33:46 -0800, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Martijn Faassen wrote: Andreas Jung wrote: I'm about to write an xml importer for importing simple data (properties, dictionaries). Exporting is easy, importing is trickier because a parser is required. Is there any prefered framework for doing such things in zope3 (zope2)? Sax or DOM...it depends on the usecase and the algorithmic approach you take. Sax is fast but you have to build your own datastructures, DOM is slow, takes a lot of memory but it gives you a tree to perform any fancy operation on it.. DOM is also not particularly Pythonic (neither is SAX, but it is relatively simple at least). You could also look into ElementTree (or lxml, which implements that API too). ElementTree (though not yet lxml) also introduces iterparse, which is a kind of streaming version of the ElementTree API. ElementTree's API is a much nicer way to work with XML from Python than DOM. Also it's more lightweight than even MiniDOM. Regards, Martijn thanks for the info Martijn, I'm going to look at it. I've done some work with ElementTree for CPSIO, and I haven't found it very easy to use because of all the extra namespace URI, and xpath stuff used for the tree navigation (xpath_findall, ..) which seem to get in the way. Also it could be that I find the DOM approach easier since I'm used to it in javascript already. the question is also about being able to reuse parts of the export/import code of CMFSetup / GenericSetup and possibly simplify the zope2 - zope3 migration of existing applications. best /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.datetimewidget branch for zope2?
hi folks, i was just curious if there were any objections to starting a branch of zc.datetimewidget thats compatible with zope2, ie. doesn't depend on z3 request locales and zc.resourcelibrary. first cut at a diff attached which works, w/ zope 2.9 and presumbly 2.10, still needs some work for i18n correctness, but having a useable datetime widget is really helpful to z3/five adoption in z2. cheers, kapil zc.datetimewidget-z2.diff Description: Binary data ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zc.datetimewidget branch for zope2?
On Sat, 25 Nov 2006 10:03:55 -0600, Rocky Burt [EMAIL PROTECTED] wrote: On Fri, 2006-24-11 at 19:19 -0600, Kapil Thangavelu wrote: i was just curious if there were any objections to starting a branch of zc.datetimewidget thats compatible with zope2, ie. doesn't depend on z3 request locales and zc.resourcelibrary. first cut at a diff attached which works, w/ zope 2.9 and presumbly 2.10, still needs some work for i18n correctness, but having a useable datetime widget is really helpful to z3/five adoption in z2. Personally I would prefer to see the bits that zc.resourcelibrary uses that don't work on zope2 abstracted out as adapters/utilities and see a five.datetimewidget that provides zope2 adatpers/utilities that make zc.resourcelibrary work. Any chance of that working out ? probably not, afaics. the inner mechanics of zc.resourcelibrary aren't easily ported to z2 till z2 uses z3 publisher (at least delegation to browserrequest factories) at which point there is no need for porting it as outside of this core functionality/integration there isn't much to zc.resourcelibrary, sans adapter delegation within z2 publisher for request/response its a non starter afaics without evil monkies. as regards zc.datetimewidget, without the resourcelibrary stuff, any use requires manual inclusion of all referenced resources, which is a serious caveat, but at least useable. the i18n/locale dependencies on the request in zc.datetimewidget could be abstracted out via adapters, but which are also obsolete if z2 could delegate to z3 publisher.request/response. -kapil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SOAP support?
On Thu, 08 Feb 2007 14:31:19 -0500, Jeff Shell [EMAIL PROTECTED] wrote: On 1/7/07, Andreas Jung [EMAIL PROTECTED] wrote: Hi, I am actually looking at options for bringing SOAP support into Zope 2. Is there some SOAP infrastructure available in Zope 3 (or some add-ons) and might be re-used in a reasonable way? snip The S Stands for Simple is definitely a great read. It's terrifying because it's true. (At the same time, I can see the appeal of SOAP in the heavyweight compiled commercial crap tools business - exposing a ColdFusion Component as a web service is as easy as adding ``?wsdl`` to the URL, and I was able to attach the web service to a table in Flash 8 Professional and witness data being returned, and I don't know or use Flash (or ColdFusion) at all. Ugh. Shame it's such a crap system. Viva AJAX with JSON! Viva View-Source! Viva good old fashioned GET and POST HTTP requests that don't have additional traversal steps buried in a body that one could never type by hand!) some additional good reads, iona chief engineer - REST Eye for the SOAP Guy http://dsonline.computer.org/portal/pages/dsonline/2007/01/w1tow.xml gartner vp - Web Services based on SOAP and WSDL are Web in name only. In fact, they are a hostile overlay of the Web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade. protocols and formats such as RSS, Atom, Microformats, and now GData that are the best examples of how to enable one software agent to interact with another (aka A2A integration). http://www.w3.org/2007/01/wos-papers/gall cheers, kapil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
On Mon, 12 Mar 2007 11:48:24 -0400, Godefroid Chapelle [EMAIL PROTECTED] wrote: Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) dcworkflow simple to use, well known, needs extension via custom guards and triggers to accomodate alot of workflow customization (send email, route to manager, etc.) zope3.wfmc.. abstract, potentially powerful, but imo, needs quite a bit of code to make anything non trivial functional. alphaflow.. i like the best as an architecture (ignoring AT implementation), i think that investing time rewriting it on z3 concepts would be time well spent, it has flexibility, a library for common actions, supports organizational workflows much better, and is model complete in terms of constructs to model conceptual workflows. openflow.. nothing to say. depending on your timeline.. of the two worth investigating, i would recommend alphaflow and z3.wfmc two cents, -kapil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope3 and zope.conf without the zodb
I've been using zope3 as a wsgi app, without a zodb. it bypasses the zodb publishing traversal via replacement of the published application, all of which can be managed in zcml. One issue I've run into is configuring an app through zope.conf forces you to have an open zodb, because of the required attribute in zope.app.appsetup schema.xml Allowing zope3 usage without a zodb attached, is basically a one line fix here. Would there be any objections to removing it? cheers, kapil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
