LOL. Next question,
When I first upload the file using the ERAttachmentUpload component the result is what I'd expect it to be i.e. an object of my entity and an object of erattachment are created and the file is stored per the configuration. However, if I then update my entity and upload a new file I get a behavior I didn't expect. This time a new entity of type ERAttachment is created and the old one is now left dangling in the database without any reference to it. The file(s) on the system are also untouched. Does this mean I have a problem in the model or is that the expected behavior and I need to add some logic to complete the clean up? Thanks, Johnny On Feb 16, 2010, at 1:23 PM, Mike Schrag wrote: > i would assume that "later" is an unbounded value. i'm not actively working > on it ... > > On Feb 16, 2010, at 6:11 PM, Johnny Miller wrote: > >> Sorry, hit the reply instead of reply all... >> >> OK, so if you want the thumbnailing functionality you need to layer it on >> yourself. In the docs it states "Later versions will support generating >> thumbnails in addition to the original image." >> >> Is this in the "works" or should I just assume that it's low in the priority >> stack and go with my own solution? >> >> Best, >> >> Johnny >> >> >> On Feb 16, 2010, at 12:41 PM, Mike Schrag wrote: >> >>> keep questions on the list, please >>> >>> if you set the scale factor on the attachment upload, it will scale it >>> permanently. if you set the scale on the viewer, it will just do html >>> scaling (and send the full sized version) -- it does _not_ thumbnail it on >>> the fly. >>> >>> ms >>> >>> On Feb 16, 2010, at 5:13 PM, Johnny Miller wrote: >>> >>>> OK, it's sinking in slowly :p >>>> >>>> I think everything is set up on the database and model side correctly. >>>> >>>> Sorry to inundate you with questions but... >>>> >>>> An overview question. Once the original is stored can I use >>>> ERAttachmentViewer to create scaled versions of the original? If it is >>>> scaling does it create a permanent copy of the scaled version? Or does it >>>> create a new scaled image every time it is requested? >>>> >>>> Thanks again, >>>> >>>> Johnny >>>> >>>> >>>> >>>> On Feb 16, 2010, at 11:46 AM, Mike Schrag wrote: >>>> >>>>> the only thing ERAttachment needs is the original two tables (primary one >>>>> and the one for blob data). on your side, you would need the foreign key >>>>> id ... you can extend ERAttachmentMigration to do that. >>>>> >>>>> ms >>>>> >>>>> On Feb 16, 2010, at 4:35 PM, Johnny Miller wrote: >>>>> >>>>>> WOW. That's really a new paradigm from the way I've been doing things. >>>>>> >>>>>> So, to get started I'm going to keep things simple and just use the >>>>>> to-one attachment. >>>>>> >>>>>> I'm also using the file system storage type with the web server directly >>>>>> serving the files. >>>>>> >>>>>> In that set up will anything be created in the database when I migrate >>>>>> on start up? Right now, I'm not seeing anything besides the _dbupdater >>>>>> table. >>>>>> >>>>>> Thanks again, >>>>>> >>>>>> Johnny >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Feb 16, 2010, at 11:22 AM, Mike Schrag wrote: >>>>>> >>>>>>> whether you choose a to-one or a many-to-many depends on whether you >>>>>>> want one attachment or many ... if you have company.logo it's a to-one >>>>>>> to attachment, with no inverse relationship. if it's gallery.photos >>>>>>> then it's a many-to-many with no inverse relationship from attachment. >>>>>>> >>>>>>> On Feb 16, 2010, at 4:13 PM, Johnny Miller wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've been using ERAttachment's image processor but on a new project >>>>>>>> I'm going to try out using the entire framework i.e. all the automagic >>>>>>>> file handling wonderment. >>>>>>>> >>>>>>>> A question on modeling the attachments. >>>>>>>> >>>>>>>> When you create the relationship between the entities' key and >>>>>>>> ERAttachment is that an optional one-to-one relationship or is it an >>>>>>>> optional one-to-many from your model to erattachment? >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> >>>>>>>> Johnny >>>>>>>> >>>>>>>> >>>>>>>> Johnny Miller >>>>>>>> Kahalawai Media Corp >>>>>>>> http://www.kahalawai.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>>>>>> >>>>>>>> This email sent to msch...@mdimension.com >>>>>>> >>>>>>> >>>>>> >>>>>> Johnny Miller >>>>>> Kahalawai Media Corp >>>>>> http://www.kahalawai.com >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> Johnny Miller >>>> Kahalawai Media Corp >>>> http://www.kahalawai.com >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/jlmiller%40kahalawai.com >>> >>> This email sent to jlmil...@kahalawai.com >> >> Johnny Miller >> Kahalawai Media Corp >> http://www.kahalawai.com >> >> >> > Johnny Miller Kahalawai Media Corp http://www.kahalawai.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
