| *** gintas has quit IRC | 00:03 | |
| *** J1m has quit IRC | 00:04 | |
| *** ChanServ sets mode: +o hazmat | 00:06 | |
| *** srichter has quit IRC | 00:35 | |
| *** deo has quit IRC | 00:50 | |
| *** bskahan has quit IRC | 00:55 | |
| *** srichter has joined #zope3-dev | 01:03 | |
| *** ChanServ sets mode: +o srichter | 01:03 | |
| *** PalmTree has quit IRC | 01:19 | |
| *** zmogelis has joined #zope3-dev | 02:36 | |
| *** zmogelis__ has quit IRC | 02:37 | |
| *** zmogelis has quit IRC | 02:39 | |
| *** benji_york has quit IRC | 02:52 | |
| *** Damascus- has joined #zope3-dev | 03:03 | |
| Damascus- | hmmm. http://irclogs.espnow.net/zope3/ not showing up | 03:04 |
|---|---|---|
| *** foom has joined #zope3-dev | 03:07 | |
| *** foom has left #zope3-dev | 03:09 | |
| *** bskahan has joined #zope3-dev | 04:38 | |
| *** bradb has quit IRC | 04:40 | |
| *** Damascus- has quit IRC | 04:44 | |
| *** d2m has quit IRC | 04:46 | |
| *** bskahan has quit IRC | 06:04 | |
| *** RaFromBRC has quit IRC | 06:30 | |
| *** mooded has quit IRC | 06:38 | |
| *** sashav has quit IRC | 08:13 | |
| *** tav has quit IRC | 08:32 | |
| *** BjornT has quit IRC | 08:32 | |
| *** jack-e|away has quit IRC | 08:32 | |
| *** jan_s has quit IRC | 08:32 | |
| *** rabidbt has quit IRC | 08:32 | |
| *** Damascene has quit IRC | 08:32 | |
| *** __gotcha has quit IRC | 08:32 | |
| *** jan_s has joined #zope3-dev | 08:32 | |
| *** tav has joined #zope3-dev | 08:32 | |
| *** BjornT has joined #zope3-dev | 08:32 | |
| *** __gotcha has joined #zope3-dev | 08:32 | |
| *** Damascene has joined #zope3-dev | 08:32 | |
| *** jack-e|away has joined #zope3-dev | 08:32 | |
| *** rabidbt has joined #zope3-dev | 08:32 | |
| *** hazmat has quit IRC | 09:55 | |
| *** zagy has joined #zope3-dev | 11:20 | |
| *** jan_s has quit IRC | 11:34 | |
| *** RaFromBRC has joined #zope3-dev | 11:39 | |
| *** sashav_ has joined #zope3-dev | 11:43 | |
| *** sashav_ has quit IRC | 11:52 | |
| *** d2m has joined #zope3-dev | 11:58 | |
| *** sashav has joined #zope3-dev | 12:29 | |
| *** Theuni has joined #zope3-dev | 13:19 | |
| *** mooded has joined #zope3-dev | 13:22 | |
| *** projekt01 has joined #zope3-dev | 14:04 | |
| *** jhauser has joined #zope3-dev | 15:17 | |
| *** sashav has quit IRC | 16:43 | |
| projekt01 | Janko; did you see my mail about Ifile? | 16:52 |
| *** sashav has joined #zope3-dev | 16:52 | |
| jhauser | yes | 16:55 |
| jhauser | but the problem suddenly rises | 16:56 |
| jhauser | di I understand one of the problems right, that you want different content types regarding the mime-type of the uploaded file? | 16:57 |
| jhauser | projekt01 I would defer this to the work of adapters | 16:58 |
| *** sashav_ has joined #zope3-dev | 16:58 | |
| jhauser | in this regard I also would not like to include an editing window for text content | 16:58 |
| jhauser | at least not in the first try | 16:59 |
| *** sashav|wshop has joined #zope3-dev | 16:59 | |
| projekt01 | Ok | 17:02 |
| jhauser | projekt01 is the contenttype file working right in regards of memory consumption and storing of data? | 17:03 |
| projekt01 | Where is responsible for the mime-type? | 17:03 |
| projekt01 | The filename of the object or the upload? | 17:03 |
| projekt01 | Yes the File is working correct, it seams that the File uses FileChink for bigger uploads | 17:04 |
| jhauser | the filename of the uploaded file is an property of the upload object | 17:04 |
| projekt01 | Correct, you speak about your implementation and not like the File of Zope3? | 17:05 |
| jhauser | it can be used as a name | 17:05 |
| jhauser | I think we need to differentiate between a schema field file and a file content object | 17:05 |
| jhauser | a schema field say that file-like data is stored under the given fieldname at the object which implements the schema | 17:06 |
| jhauser | the fieldname has nothing to do with the filename of the uploaded object | 17:06 |
| projekt01 | Ok, if I understand we can have a file called word.doc and the upload is a test.txt file | 17:07 |
| projekt01 | How can we handle this? | 17:07 |
| jhauser | no | 17:07 |
| jhauser | you think in terms of content object | 17:08 |
| projekt01 | Yes | 17:08 |
| jhauser | ok | 17:08 |
| jhauser | so if we add a file content object (cobj) it should have an upload form field in the addform | 17:09 |
| projekt01 | Ok | 17:09 |
| projekt01 | The object declares the filename e.g. word.doc | 17:09 |
| jhauser | the file content object would need to implement a schema with a file schema field | 17:09 |
| jhauser | in the addform the user can give the new cobj a name or use the name of the uploaded file as a default name | 17:10 |
| jhauser | ah I see the problem | 17:11 |
| projekt01 | Yup... | 17:11 |
| projekt01 | The first step is add the object with a name | 17:12 |
| projekt01 | It could be word.doc | 17:12 |
| jhauser | the current cobj file holds the data directly in a chunked data structure, same with mime type and filename | 17:12 |
| projekt01 | Which says something about the mime-type | 17:12 |
| jhauser | but the mime-type is only an attribute, which can be changed, if a new file is uploaded | 17:13 |
| projekt01 | Stop | 17:13 |
| projekt01 | Here we get into trouble | 17:13 |
| projekt01 | The filename says something about the mime-type | 17:14 |
| projekt01 | And the upload can be different | 17:14 |
| jhauser | eh perhaps to the user, but not to the system | 17:14 |
| projekt01 | Ok | 17:14 |
| projekt01 | Perhaps we have to prevent uploading different mime-types if we have a filename | 17:15 |
| jhauser | a filename wich says something about the mimetpye | 17:15 |
| projekt01 | I think it's important not to ignore the filename | 17:15 |
| jhauser | I can name my file 'dada' | 17:15 |
| projekt01 | Yes, but should we ignore the normal pattern for windows? | 17:16 |
| *** sashav_ has quit IRC | 17:16 | |
| jhauser | ok, this would mean we implement something like an filename extension handler | 17:16 |
| jhauser | but this is way beyond the scope of a file schema field :-) | 17:17 |
| jhauser | it is actually a policy of the cobj | 17:17 |
| projekt01 | Ok | 17:17 |
| jhauser | and let me end the problem i mentioned above | 17:17 |
| projekt01 | Ok | 17:18 |
| jhauser | the current file cobj IS the file | 17:18 |
| jhauser | with the file schema field the file is stored as an object at the cobj | 17:18 |
| jhauser | so also other content objects like for example email can have a file field, where the attachment is stored | 17:19 |
| jhauser | this means that we need to introduce a new file content object or change the current if we implement a file schema field | 17:20 |
| jhauser | correct? | 17:20 |
| projekt01 | The file content object is the file | 17:20 |
| projekt01 | Your solution ends in a file container like object | 17:21 |
| jhauser | yes | 17:21 |
| projekt01 | Where we can have more then one file as a kid of childs | 17:21 |
| jhauser | yes | 17:21 |
| projekt01 | This needs special upload forms which can handle multi file upload | 17:21 |
| jhauser | and we could also have different file content objects | 17:22 |
| projekt01 | I thin k this is a special use case and content type implementation | 17:22 |
| jhauser | a wordfile cobj for example with special methods to present word metadata | 17:22 |
| jhauser | that's all not the business of the file schema field | 17:22 |
| *** sashav|wshop has quit IRC | 17:23 | |
| *** sashav has quit IRC | 17:23 | |
| projekt01 | Ok, but the File right now needs some refactoring | 17:24 |
| projekt01 | You speak about another implementation of a content type right now | 17:24 |
| jhauser | sure, but I do not now where the current file cobj does get it's data from | 17:24 |
| jhauser | now/know | 17:24 |
| projekt01 | You describe a logic construct of a content type which can handle extended information for files | 17:25 |
| jhauser | yes | 17:26 |
| projekt01 | Ok | 17:26 |
| *** Jim7J1AJH has quit IRC | 17:26 | |
| projekt01 | The file itself is just a upload | 17:26 |
| projekt01 | Like we have in FileChunk right now? | 17:26 |
| projekt01 | What do you think about to enhance this base File implementation first? | 17:27 |
| jhauser | no, the current file cobj implementation would be used as the basis for the field object | 17:27 |
| jhauser | an arbitrary object, which hold internally the chunked data structure and also the attributes filename and mime-type | 17:28 |
| jhauser | cobj -> schemafilefield -> chunked_data | 17:29 |
| projekt01 | We have already a FileChunk object in Zope3, but it's just used for bigger uploads | 17:29 |
| projekt01 | Should we enhance this FileChunk class and add this subinformation there? | 17:29 |
| jhauser | yes would be possible | 17:30 |
| projekt01 | Ok, I understand, that's the base work what I tried to describe before | 17:30 |
| projekt01 | Later we can add sepcial content type File objects which acts like we need | 17:30 |
| jhauser | ah one think wich speaks against filechunk as a basis, that the serving of chunked data is not done there | 17:32 |
| jhauser | think/thing | 17:32 |
| projekt01 | What do you mean with not done there? | 17:33 |
| jhauser | if we want a field, which can also be used at other content objects a basis serving method needs to be in the field implementation | 17:33 |
| jhauser | if you compare FileChunk with the _setdata method of File than you see the actuall work, which needs to be done in the file schema field | 17:35 |
| jhauser | also if you look at the index_html implementation of zope2 file you see how much trickery is needed to serve the data | 17:35 |
| jhauser | ah ok, but this can be done by the display widget or some display widget | 17:36 |
| jhauser | perhaps, not sure about this | 17:36 |
| jhauser | but problem of handling of large data is the main reason, why there are so many different implementations in the zope2 world | 17:37 |
| *** tav_ has joined #zope3-dev | 17:37 | |
| projekt01 | Can we define a schema for this, I'm not sure if I understand this right? | 17:38 |
| jhauser | can't we simply use file as the basis? | 17:39 |
| jhauser | there is nothing in there, what is specific for a contentobject, except the IFileContentMarker | 17:40 |
| projekt01 | Ok, I think you will use something like a hook object which stores additional data like mime-types for the upload | 17:41 |
| projekt01 | Correct? | 17:42 |
| jhauser | that was the problem I mentioned in the mail and we discussed once here | 17:42 |
| jhauser | a file is not a single field, but also has the information filename, size, mime type | 17:43 |
| jhauser | my thinking is, and I also think the result of the discussion was, that this information is stored in the object, which is the file schema field | 17:44 |
| jhauser | to use this information one would call an adapter on the schema field, which extracts the information | 17:44 |
| jhauser | similar to imageinfo | 17:44 |
| projekt01 | Yes that's right | 17:45 |
| projekt01 | Let's se if this is correct: | 17:45 |
| projekt01 | class FileUploadField(IField): | 17:45 |
| projekt01 | """File upload Field handles additional info""" | 17:45 |
| projekt01 | class IFile(Interface): | 17:45 |
| projekt01 | data = FileUploadField... | 17:45 |
| projekt01 | class File(object): | 17:45 |
| projekt01 | def __init__(self, data): | 17:45 |
| projekt01 | self.data = FileUpload(data) | 17:45 |
| projekt01 | class FileUpload(object): | 17:45 |
| projekt01 | """The file upload""" | 17:45 |
| projekt01 | 17:46 | |
| projekt01 | def mimeType(self) | 17:46 |
| projekt01 | Perhaps we need another place for defining the schema where we don't loose the formating | 17:46 |
| jhauser | yes although FileUpload would be implemented like the current file | 17:47 |
| projekt01 | And uses the FileChunk if needed for to store the data (upload), right? | 17:47 |
| jhauser | FileUpload(Persistent) ... | 17:47 |
| projekt01 | sure | 17:48 |
| jhauser | yes like the current file | 17:48 |
| jhauser | File class | 17:48 |
| jhauser | ok | 17:48 |
| projekt01 | Let's use the branch for defining the schema | 17:48 |
| jhauser | sure | 17:49 |
| *** tav has quit IRC | 17:49 | |
| jhauser | in schema or somewhere in file | 17:49 |
| jhauser | I would suggest schema | 17:49 |
| projekt01 | Let's directly change the File, Ifile etc. and add a FileUpload class | 17:51 |
| jhauser | hm but later you want to do a | 17:52 |
| projekt01 | Make the File work with the sub object FileUpload | 17:52 |
| jhauser | from zope.schema import FileUploadfField | 17:52 |
| jhauser | ah ok | 17:52 |
| projekt01 | And the FileUpload should use the FileChunk if needed | 17:52 |
| jhauser | yes and I would not call it Upload | 17:53 |
| projekt01 | Of corse we have to add the IFile field | 17:53 |
| projekt01 | And later we can add the widgets | 17:53 |
| jhauser | because the upload is only defined through the widget, it can also be created from reading from the filesystem or so | 17:54 |
| projekt01 | What do you think about IFile and IFileData | 17:54 |
| projekt01 | And IFileDataWidget | 17:55 |
| jhauser | yes although Jim mentioned Mime something | 17:55 |
| projekt01 | Or IFileUploadWidget | 17:55 |
| jhauser | IMImeField/MimeField | 17:56 |
| projekt01 | I think mime is just one part of it | 17:56 |
| jhauser | ok | 17:56 |
| projekt01 | What do we have to store exactly on this file upload object? | 17:56 |
| projekt01 | Mime-type | 17:57 |
| projekt01 | and | 17:57 |
| jhauser | size | 17:57 |
| jhauser | it is costly to always use getSize | 17:57 |
| jhauser | and after upload it does not change | 17:57 |
| jhauser | the original filename | 17:57 |
| jhauser | that's it I think | 17:58 |
| projekt01 | Hm, yes but where do you need the size of the file upload object? | 17:58 |
| projekt01 | What's about the filename? | 17:58 |
| projekt01 | Of the upload | 17:58 |
| jhauser | yes the original filename of the upload needs to be stored | 17:59 |
| jhauser | the size is needed always | 17:59 |
| projekt01 | Let's see we store the filename, mime-type, the data itself and pehaps the size | 17:59 |
| jhauser | to present it, to be used in the widget, if the file is served | 17:59 |
| jhauser | yes | 18:00 |
| projekt01 | Should we really call this IMime | 18:00 |
| jhauser | no let's start with FileData | 18:00 |
| jhauser | we can rename it later | 18:00 |
| projekt01 | Let's define Imime and inherit IFileData form Imime, and let define more sub interfaces if need more | 18:02 |
| projekt01 | A little bit overhead but simply and clear | 18:02 |
| jhauser | nice | 18:04 |
| jhauser | are you typing, or should I do it? | 18:05 |
| projekt01 | This way we can support a IMime adapter which returns the mime-type, otherwise we have to define the adapter to IFileData | 18:05 |
| jhauser | yes this is nice | 18:05 |
| projekt01 | Can you start, I have to leave now, I will start tonight | 18:06 |
| projekt01 | Can we split the work in differnet parts? | 18:06 |
| jhauser | I probably need help for the tests | 18:06 |
| jhauser | I will take a look at the current file tests | 18:07 |
| projekt01 | I can start at the end and implement the widget and adapters | 18:07 |
| jhauser | ok | 18:07 |
| projekt01 | Test are ot the problem, I can add it if you implement something | 18:07 |
| projekt01 | ot/not | 18:07 |
| projekt01 | I also can start adding adapters for IMime etc | 18:08 |
| jhauser | nice, I need to learn it nevertheless | 18:08 |
| jhauser | Ok I concentrate at the file field for the moment | 18:08 |
| jhauser | do you have time pressure for the usage of this? | 18:08 |
| projekt01 | Yes | 18:08 |
| jhauser | :-) ok | 18:09 |
| projekt01 | But I think I work next week with Dominik Huber and this | 18:09 |
| projekt01 | So I think we can finish this next week | 18:09 |
| jhauser | ok we should have something in the next days | 18:10 |
| projekt01 | I hope the impact for BBB is not to big | 18:10 |
| jhauser | what is BBB? | 18:10 |
| projekt01 | If we are finish, I like to add i18n support too | 18:10 |
| projekt01 | BBB = backward compatiblity or how do you call this | 18:11 |
| jhauser | the tests should show this | 18:11 |
| jhauser | ok let's start, see you later or tomorrow | 18:12 |
| projekt01 | Yup | 18:12 |
| projekt01 | Are on IRC tomorrow? | 18:12 |
| projekt01 | Write a mail if you have questions or if I need to implement something | 18:12 |
| jhauser | sure | 18:13 |
| projekt01 | Otherwise I start with adapters and widgets | 18:13 |
| projekt01 | See you tomorrow or deep I the night... | 18:15 |
| *** mooded has quit IRC | 18:28 | |
| *** mgedmin has joined #zope3-dev | 18:38 | |
| *** RaFromBRC has quit IRC | 19:36 | |
| *** __gotcha_ has joined #zope3-dev | 19:56 | |
| *** __gotcha has quit IRC | 19:57 | |
| *** hazmat has joined #zope3-dev | 19:59 | |
| *** zagy has joined #zope3-dev | 20:00 | |
| *** tvon has quit IRC | 20:03 | |
| *** zagy has quit IRC | 20:03 | |
| *** testMM has joined #zope3-dev | 20:32 | |
| *** RaFromBRC has joined #zope3-dev | 20:33 | |
| *** RaFromBRC has quit IRC | 20:49 | |
| *** testMM has left #zope3-dev | 20:50 | |
| *** hazmat has left #zope3-dev | 21:14 | |
| *** PalmTree has joined #zope3-dev | 21:30 | |
| *** mooded has joined #zope3-dev | 21:30 | |
| *** tvon has joined #zope3-dev | 22:31 | |
| *** mooded has quit IRC | 22:39 | |
| *** tvon has quit IRC | 22:53 | |
| *** PalmTree has quit IRC | 22:54 | |
| *** mgedmin has quit IRC | 23:18 | |
| *** mgedmin has joined #zope3-dev | 23:26 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!