- Zope-Dev - Zope lists

ZClass question
by Lalo Martins 13 Oct '99

13 Oct '99

If I created a ZClass ``foo'', and I want some default rendering when someone uses ``<dtml-var fooobj>'' (where ``fooobj'' is a ``foo'' object), what method should I add to the ``foo'' ZClass? I suggest that this answer be added to the ZClass documentation in ZDG. []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org

1 0

Re: [Zope-dev] Multiformatted Interface (was Re:
by Rik Hoekstra 13 Oct '99

13 Oct '99

> (I moved this thread to zope-dev) Woops. I accidentally sent my reply to the Zope list. Here it is again. > > Toby Dickenson wrote: > > > > On Mon, 11 Oct 1999 15:06:50 -0700, you wrote: > > > > >I'm creating a brand new ZClass (called "PDFClass"). It's my first ZClass. > > >I've just added the Common Instance Property Sheet (called "PDFProperties"). > > >Now I'm trying to add properties to that property sheet. I added one > > >"string" property OK, but now when I add the "date" property "pub_date", I > > >get this error: > > > > > > Invalid Date-Time String > > > > Are you planning to extract properties from PDF files? That's a task > > on my to-do list too. > > Let's start a discussion on this before any code gets written, I've been > thinking alot about document formats lately. > > I'm working on a model and elaboration of what I call MFI, Multi-Format > Interface, which will be a component of the Portal Toolkit and possible > a future core feature of Zope. Basicly, this consolidates all of the > document types, DTML, XML, PDF, what-have you, into a subclassable > interface that allows you to define pluggable format types. That is a very good idea. Should it be able to guess what the document format is or will you have to indicate that by hand? > This way, > indestead of making a whole new type of object (PDFDocument, whatever) > you make a new plug-in format for MFI that all Documents can then select > as their format type. This is much more flexible, extendable, and > 'philosophically' correct than the current method. As an example, an > HTML formatter could be made (that extracts meta-information from a > document and perhaps builds a DOM tree if it's parsable well enough), a > PDF formatter (can DOM be put on PDF?) I doubt it. The structured documents and the page oriented markup seem to be rather different philosophies of representing a text document. Turning PDF documents into html is no easy business either. But then, some sectioning of even a pdf document (and even of Word documents - sometimes :-) _is_ possible. Calling that a DOM is stretching the DOM concept a bit too much I think. > a structured text (stx) > formatter (we are elaborating a DOM interface for Stx). The > possiblities are endless, and it means that all of these document types > in the add list can be reduced to one selection. > > This is a pretty light description, but there are many other benefits > I'm formalizing into a document right now. What are you thoughts? > What all documents do/could/should have (natively or added) are document properties (preferably conforming to the Dublin Core, for standardization). These should be extracted using DOM or COM (for Word documents) or via a PDF parser for PDF documents or whatever and added to the propertysheet. Or/and propertysheets could be filled by hand through the Zope Management interface. I take it that your proposal also leads to inclusion of documents in catalogs for fielded and fulltext searches? Yes, please? However, won't this be conceptually difficult beyond full text searches? The level of access of the documents are so diverse. Compare the structured DOM access to XML documents to the (basically) mere word level access to pdf (and even html) documents. Oh well, just my own preoccupations I guess. An very good idea Michel. Rik _______________________________________________ Zope maillist - Zope(a)zope.org http://www.zope.org/mailman/listinfo/zope (Related lists - please, no cross posts or HTML encoding! To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce For developer-specific issues, zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev )

1 0

Re: [Zope] Can't add "date" property to new ZClass
by Michel Pelletier 13 Oct '99

13 Oct '99

(I moved this thread to zope-dev) Toby Dickenson wrote: > > On Mon, 11 Oct 1999 15:06:50 -0700, you wrote: > > >I'm creating a brand new ZClass (called "PDFClass"). It's my first ZClass. > >I've just added the Common Instance Property Sheet (called "PDFProperties"). > >Now I'm trying to add properties to that property sheet. I added one > >"string" property OK, but now when I add the "date" property "pub_date", I > >get this error: > > > > Invalid Date-Time String > > Are you planning to extract properties from PDF files? That's a task > on my to-do list too. Let's start a discussion on this before any code gets written, I've been thinking alot about document formats lately. I'm working on a model and elaboration of what I call MFI, Multi-Format Interface, which will be a component of the Portal Toolkit and possible a future core feature of Zope. Basicly, this consolidates all of the document types, DTML, XML, PDF, what-have you, into a subclassable interface that allows you to define pluggable format types. This way, indestead of making a whole new type of object (PDFDocument, whatever) you make a new plug-in format for MFI that all Documents can then select as their format type. This is much more flexible, extendable, and 'philosophically' correct than the current method. As an example, an HTML formatter could be made (that extracts meta-information from a document and perhaps builds a DOM tree if it's parsable well enough), a PDF formatter (can DOM be put on PDF?) a structured text (stx) formatter (we are elaborating a DOM interface for Stx). The possiblities are endless, and it means that all of these document types in the add list can be reduced to one selection. This is a pretty light description, but there are many other benefits I'm formalizing into a document right now. What are you thoughts? -Michel

2 2

Re: [Zope-dev] Another zope suggestion
by Christopher Petrilli 13 Oct '99

13 Oct '99

> Would it be possible to have a Zope feature to change the Python path > from Zope? Could you elaborate on what problem you are trying to solve? THis sounds awfully scary and frightening to me :-) Chirs -- Chris Petrilli

2 1

Re: [Zope-dev] any ADO planned suppor t??
by Brian Lloyd 13 Oct '99

13 Oct '99

> ... are there plans for ADO support from Zope in the future?? > > > > Darn, As much as I want to build with Zope, I move fast and > > furiosly with > > .ASP, > > hope that ADO is considered..... There are no plans to support ADO in the way I believe you are thinking of it (e.g., using ADO objects in the way you would from an .asp page). Zope takes a fairly fundamentally different approach to things like data access than ASP. A core design goal of Zope is to provide a structured object environment that encourages the separation of content and logic rather. In Zope, rather than having a bunch of templates that contain content, code, database queries and possibly sensitive db login information all mixed up together, you effective build an object oriented interface to your data. For example, lets say a simple app just gets employee info from a back end db. In Zope, you might: o create a folder 'MyApp' o add a db connection to the folder o add an SQLMethod that uses that connection called 'GetEmployees', using a query that gets all employees o add a report ('report.html') that acts as the UI for the app. What you have done, in effect, is created an "object" ("MyApp") with a "method" ("GetEmployees") which your content managers can call (in report.html) without knowing or caring about SQL, databases, etc. The dtml in the report can be pretty simple: <ol> <dtml-in GetEmployees> <li><dtml-var name> ... </dtml-in> </ol> The important point is that from a Zope development point of view, it really doesn't make much difference what db you are using - you would approach the app building process in the same basic way. You don't have to know or care about the api of the specific database in use - if you have a Zope DA for that db, you can treat it like any other. Hopefully this explains our point of view on why exposing a specific api (even a fairly decent one like ADO) for use directly in DTML a la ASP is unlikely. That said, it would probably be quite trivial for someone to implement an ADO-based DA for Zope - though I don't think that's the question you were asking... Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

Unauthorized problem
by Gilles lavaux 13 Oct '99

13 Oct '99

Hello, Moving stuffs from zope1 to zope2 I got an unauthorized problem: I do a search with the ZopeFind method in folder where I have a lot of rights. I use a 'formatResult' method with the code bellow. The problem appear when I try to acess properties (the title) of the documents I found. If I am manager it works. giving ALL possible rights to my user doesn't solve the problem. I try to read the document properties (title) with a <dtml-with "sequence-key"> <dtml-var title> </dtml-with> yesterday I had problem using images inside the 'tree' tag, today problem accessing object properties inside the 'with' tag. Is there more problems/rules with the tags in zope2 than in zope1 or is it just me? The code from my findFormat is bellow, thanks for any info:  Search result from :  <blockquote>   Found  candidate(s)        <a href="/ShowDoc?doc_id=&curr_dir=&REFRESH=YES&VIEW=DOC"> </a>  <a href="/"> </a>  TEST:  THIS IS THE PROBLEM:    ''  etc.... Gilles Lavaux

1 0

Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 12 Oct '99

12 Oct '99

> Question for Christopher Petrilli: because the patches from the Oracle > DA are so small, does merging the mxODBC and Oracle DAs into one code > base seem feasible? No, mostly because both are on the cusp of going somewhere else. We will most likely be undertaking a ground-up rewrite of the ODBC driver based purely on the X/Open CLI spec (which is part of SLQ99), which will also be used to talk to DB2. This will not use a DB-API compatible interface for various reasons. Eventually the DCOracle adapter will undergo a similar transition. We need things that the DB-API doesn't provide, nor perhaps should it. We have already had great success with a Sybase adapter done this way (eventually to be released). Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

3 3

Re: [Zope-dev] Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 12 Oct '99

12 Oct '99

>> We are abandoning the use of DB-API interfaces for our own use simply >> because they have proven to be of little value in getting things running. > > Why is that ? The DB API is intended to be of general use, how can Zope > be so much different ? > >> In addition, their behavioral assumptions are sometimes quite incompatible >> with Zope requirements. Jim Fulton can better speak to this. We're now >> doing a more "thin shim" approach, and not going anywhere near the DB-API or >> SWIG. > > Oh well, then I guess you're on your own. I would have rather liked > to see more native DB-API style interfaces appear than incompatible > thin layer new ones. It's a combination of paradigm matching as well as the fact that DCOracle generates a HUGE number of support requests that we simply don't have the energy to deal with. Now, having said that, the design we use (which is a thin shim of C with 99% in Python) is entirely usable for writing a DB-API layer on TOP of, we simply have no value in that right now. This doesn't mean that some enterprising individual couldn't write one and support it themselves. > ODBC is not really all that bad -- at least not always. It gives you > database flexibility and portability that no other standard has achieved > over the years, not even the later ones pushed by MS. We see X/Open CLI as the interesting target, rather than ODBC. ODBC is a derivative now, as opposed to the source. And for our needs, X/Open CLI provides everything except BLOB support. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

2 1

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by M.-A. Lemburg 12 Oct '99

12 Oct '99

Christopher Petrilli wrote: > > > Christopher Petrilli wrote: > >> > >> BTW, I didn't mean to imply that what you've done isn't useful, it's simply > >> incompatible with the direction we're taking. This is somewhat discussed in > >> my roadmap. If you'd like to maintain the interface that you're talking > >> about, then that'd be excellent. > > > > In what way is it incompatible ? mxODBC is DB API compliant in most parts > > and has lots of useful extensions such as the ODBC catalog functions. The > > interface itself is thread safe and thread friendly. Of course, whether > > a certain ODBC driver is depends on the driver. > > We are abandoning the use of DB-API interfaces for our own use simply > because they have proven to be of little value in getting things running. Why is that ? The DB API is intended to be of general use, how can Zope be so much different ? > In addition, their behavioral assumptions are sometimes quite incompatible > with Zope requirements. Jim Fulton can better speak to this. We're now > doing a more "thin shim" approach, and not going anywhere near the DB-API or > SWIG. Oh well, then I guess you're on your own. I would have rather liked to see more native DB-API style interfaces appear than incompatible thin layer new ones. > > FYI, mxODBC currently works with these database drivers/managers: > > Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - > > Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - > > Linux unixODBC Driver Manager - EasySoft ODBC Bridge - > > OpenLink ODBC drivers - Intersolv ODBC drivers > > + virtually any database supported by one of the listed ODBC > > managers. > > The issue is more that in many cases (Oracle for example) ODBC is enormously > slower than the native drivers. we've had people comment that it's > something around an order of magnitude. Also, Oracle's ODBC drivers leak > like the proverbial sieve. The problem with Oracle is that the connection times are exorbitant. Once you are connected the performance is much better. Also there are several different drivers out there: the original one by Oracle, the one by MS included in their free ODBC driver kit, ones by OpenLink and InterSolv. ODBC is not really all that bad -- at least not always. It gives you database flexibility and portability that no other standard has achieved over the years, not even the later ones pushed by MS. > Therefore we plan to target native interfaces, > rather than glued on top constructs. Only on Windows is ODBC any form of > gain. Now, if X/Open CLI is the native interface (as with DB2), then this > will be fine... we just plan to talk to native interfaces. FYI, Solid also uses ODBC as native interface. (BTW, I finally got the combo IBM DB2 / mxODBC to link without core dumps. Now I'll have to dive into configuring the DB2 database...) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 80 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 12 Oct '99

12 Oct '99

> On Tue, 12 Oct 1999, Christopher Petrilli wrote: > >> We are abandoning the use of DB-API interfaces for our own use simply >> because they have proven to be of little value in getting things running. >> In addition, their behavioral assumptions are sometimes quite incompatible >> with Zope requirements. Jim Fulton can better speak to this. We're now >> doing a more "thin shim" approach, and not going anywhere near the DB-API or >> SWIG. > > I guess I did "the right thing" on MySQLdb: Create a native interface > (_mysql) with a Python DB API wrapper (MySQLdb). It turned out to be very > easy to convert the old ZMySQLDA (using MySQLmodule-1.4) to use _mysql, > and MySQLmodule and _mysql are quite dissimilar. > > It might be worth pointing out (not to AMK or MAL, they know this) that > Solid's native interface is ODBC. We realize this, but SOLID has been repositioned as an embedded solution, and since we have no customers who us it, it's been pushed out to the general populace. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0