Paul Crabtree wrote:
...
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.
Ok, looked into this. I think it's because the actual string you use to invoke this source in the sitemap is configurable (in cocoon.xconf) and so you don't want to assume it is "part:". For instance I may find it more logical to call this "upload:" (in fact I do) and you just need a way to return that information at runtime.
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.
I think that's the best you can do now. Someone better with our history with CocoonComponentMangager and Environment may correct me but I don't see how to get the ObjectModel. I don't think you can do a setup() there but I could be wrong.
...
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.
Haven't been able to dig back through this cast issue. I think it will not work and the wiki is just misleading but I am going on a way back vague memory here.
Ok, hope to see that show up in Bugzilla soon!
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
case
of action) or some other form (request attribute??) for use in your
src.
These feel kind of hacky and it would be better to create a source handler for uploads. This probably would be pretty simple if you
want
to pursue it. I think I hinted at this with someone else recently.
I
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
