Thanks Geoff, that helped a lot.
I went ahead and wrote a PartSource and PartSourceFactory for my needs, something not trivial since i'm not really a Java developer, even less a Cocoon dev.
Excellent! Well, technically you are now both! ;)
It only looks in the request at the minute for the Part (PartOnDisk or PartInMemory) given the request parameter as part of the uri: example: part://request/formField1
Does "at the minute" mean only the current request, not any of the previous? That would be all you can do since previous files may be gone.
How would you see the location finding of the Part work? How can i map all the different locations that the Part can be held? I kind of see it working like this for each of the scopes, would this be flexible?
part://request/<name> part://session/<name> part://application/<name>
Hmmm, unless I'm missing something, the only place a Part can be held is request. If it's somewhere else, it's been moved there by the user and this Source doesn't really apply.
I'd suggest just using: part://formField1
I've also got a few questions about implementing Source:
1. What is the purpose of getScheme() and how should this work in this case?
Don't know this off hand - hopefully someone else can chime in. If not I'll take a look.
2. How should i implement getValidity()? im returning null cos i dont know what else to do.
Just return null. That's for caching which will never make sense in this case. Actually, this is a point for doing what you're doing instead of relying on the toString of the temporary file which would appear cacheable.
3. Im getting the Request like this at the minute.
Map objectModel =
CocoonComponentManager.getCurrentEnvironment().getObjectModel();
Don't know offhand whether that's the right way to get the ObjectModel from within the source. In general, I think you're not supposed to assume you get a CocoonComponentManager but that may be your only choice. I'll check on this.
Request request = ObjectModelHelper.getRequest(objectModel);
This part is right once you have the ObjectModel.
In the Wiki for Uploads with Flow it suggests that you can cast Request to a MultipartHttpServletRequest to check if the form might contain a Part. Ive had no luck this way but just using Request works fine. Is this the correct behaviour?
Well, if request.get() returns an object (not null) and that object is an instance of Part you have what you want. I'll check on the cast to MultipartHttpServletRequest. Stefano wrote that right after a minor refactoring of uploads and it may be misleading. What would be good is a way to get an upload without knowing the name of the formfield. But not necessary at this point.
4. And should i consider implementing ModifiableSource as the Part is a File?
I don't think that's necessary since by design this Source is transient. At the end of the request it's gone. If not, then it would be saved as a file and the normal filesource could be used. Now there could be a use case for modifying it in place for a later stage but I'd not bother now because it's not clear if that would be at all really useful.
I hope these questions all make sense, im amazed what i have works well as it stands. if you or anyone else has any time ill gladly send you my classes for you to have a look over.
Please do send them and please consider contributing them to Cocoon at bugzilla. I'd gladly test and commit them in your name.
Geoff
Geoff Howard wrote:
Wait a minute, IIRC that FilePartGenerator assumed that the file was xml. This really calls for an upload source to isolate the use and nature of the upload. For just your purposes, you may be able to modify
the FilePartGenerator to do what you want but it'd be much more useful to do a source and possibly even less work.
Geoff
Paul Crabtree wrote:
Thanks Geoff. I've come across something called a FilePartGenerator since my post:
http://www.tempeststrings.com/cocoon/apidocs/org/apache/cocoon/generatio
n/FilePartGenerator.html, which, to me, seems to be what i want.
Is there anything like this in 2.1 or anything coming?
That generator was submitted as a patch but was closed because he
forgot
to attach the source. I haven't looked at the code in a while but the
modifications to make that run in 2.1 shouldn't be very big. If
you're
interested in it, have the author of that Generator re-open the patch
at
bugzilla with the attachments. You are also probably free to take it yourself and adopt it. If the original author doesn't want to bother submitting it again and you have his license to do so, you could contribute that generator yourself.
There was a problem with the other part of the code he was donating in
that it introduced a dependency on a project with an incompatible license (though the author granted an exception for the version he
used)
and overlapped heavily with POI which we already have in cvs.
Im not sure using the file:// protocol file give me what i want as the file exists in memory only and im reluctant to save a copy of the file due to me
client
requirements.
It's only in memory if you have autosave-uploads set to false (which
is
no longer the default in 2.1). In 2.1 autosave-uploads does not save the file, permanently - it's automatically deleted at the end of the request. Does that meet your client requirements?
Im kind of getting the whole upload process now and the ways in which Cocoon can handle them, i just see a missing link between that part
and
getting the in-memory file through to a pipeline.
That's where the generator or a source would come in handy.
I read on a mail list somewhere that there is a brand new generator in Bugzilla that will solve this but cant find any more info on this out. anyone come
across
this?
It may have been the same one you found - I'm not aware of any others.
Do you have a link to the archive? Maybe it'd jog my memory.
Geoff
Paul Crabtree wrote:
Hi, i've been using Cocoon 2.1 for a few months now but i've only
just
joined this mailing list so i apologise if this sort of question has been and gone.
Here's what im trying to do:
"Provide a form for users to upload their CSV files. When the user uploads the CSV file Cocoon takes the file and passes it to the text generator and through the chaperon transformers to do a similar
thing
to
what the chaperon CSV sample does now."
I dont think i need to save the file at all but i cant work out how
to
pass it to the text generator, XSP?
Is this possible?
Read the wiki for file-upload handling. If auto-save uploads is set to true, you should be able to use the name of the upload field
(using
input module {request-param:name_of_field}) in the src attribute of the text generator (we have this? isn't it a Chaperon generator?
sorry
for my ignorance). This would be relying on the toString implementation of PartOnDisk, which I think will give you the file location. You may need to use
src="file://{request-param:name_of_field}".
Alternatively, you could also use an action or flow to get the filename in a form that would work (and even save it somewhere permanent) and pass it to the pipeline as a sitemap param (in the
casesrc.of action) or some other form (request attribute??) for use in yourwantThese feel kind of hacky and it would be better to create a source handler for uploads. This probably would be pretty simple if youIto pursue it. I think I hinted at this with someone else recently.don't have time to invest in it now, but could help you or someone else through it.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
