Re: [Zope] How to Index and search MSWord document in Zope ?
Francois-regis Chalaoux wrote:
What are today the solutions to index and search MSWord document in Zope ?
FR
http://www.zope.org/Members/Kaivo/DocumentLibrary and http://www.zope.org/Members/eric/MSWordDocument -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
I'm a little confused about the Zope design for handling images. If I am uploading an image to my hosted web site why would I want my image file incorporated into the zodb (the data.fs file)? If I don't want to do this --- and I don't because it just feels funky because the zodb isn't a 'real' database -- then what are my alternatives. I guess the fact that zodb is storing everything in one big file makes me extremely nervous. Probably doesn't matter for smaller web sites but if I actually wanted to use this for larger sites it would be a real sticking point. Any advice on this point?
is storing everything in one big file makes me extremely nervous. Probably doesn't matter for smaller web sites but if I actually wanted to use this for larger sites it would be a real sticking point. Any advice on this point?
Most databases store everything in a few large files. Why is one large file worse? ZODB is a real database. It's a real good database. Aside from that, things you can look at are: 1) serving images from a seperate http server that is filesystem based. 2) using the localfs product 3) storing everything in an relational database. (oracle, postgres, mysql)
From: "Steve Drees" <drees@the-bridge.net>
ZODB is a real database. It's a real good database.
I agree...
Aside from that, things you can look at are: 1) serving images from a seperate http server that is filesystem based. 2) using the localfs product 3) storing everything in an relational database. (oracle, postgres, mysql)
Actually, my port of ZPhotoAlbum to CMFPhotoAlbum removes any dependancies for image type, it's just a convenient folder presentation thingie. So your images could even be a mixture of Image, CMFImage, FSImage, EXTImage. Actually, I take it back, you have to modify a couple of lines, where it filters what kind of files it's presenting, but that's easy to do.
I am trying to send e-mail with attachment using following: <dtml-sendmail mailhost="MailHost"> To:<dtml-var to_email> From:<dtml-var email_address> Reply-To:<dtml-var email_address> Subject:<dtml-var subject> <dtml-mime type=text/plain encode=7bit> <dtml-boundary type=application/octet-stream disposition=attachment encode=base64> <dtml-with images> <dtml-var expr="restrictedTraverse(selected_image).read()"> </dtml-with> </dtml-mime> </dtml-sendmail> but I am getting error: Error Type: AttributeError Error Value: read Can anyone help? Vid __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
I found what the problem was. I have to use uuencode (for PDF Document). <dtml-mime type=application/pdf encode=7bit> Attached is the document you requested. <dtml-boundary name=report.pdf type=application/pdf disposition=attachment encode=uuencode filename=report.pdf> <dtml-var expr="restrictedTraverse('report.pdf')"> </dtml-mime> only it gives me '-' instead of file name __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
* Steve Drees <drees@the-bridge.net> [010703 20:38]:
is storing everything in one big file makes me extremely nervous. Probably doesn't matter for smaller web sites but if I actually wanted to use this for larger sites it would be a real sticking point. Any advice on this point?
Most databases store everything in a few large files. Why is one large file worse? ZODB is a real database. It's a real good database.
I just had to chip in and repeat your point again just to emphasise it, since this question comes up so much :-) I would always use the ZODB FileStorage unless there was a very good reason not to. It's fast, supports undos, is easy to back up, and keeps all your application in one place. The only two good reasons, not to do so are: 1) if your OS has a nastily small file size limit (e.g. pre-2.4 Linuxen) 2) If you need to access the same data from elsewhere (e.g. membership data in an LDAP storage) seb
participants (6)
-
Casey Duncan -
Frank McGeough -
marc lindahl -
seb bacon -
Steve Drees -
Vid B