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.
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
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>
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?
2. How should i implement getValidity()? im returning null cos i dont
know what else to do.
3. Im getting the Request like this at the minute.
Map objectModel =
CocoonComponentManager.getCurrentEnvironment().getObjectModel();
Request request = ObjectModelHelper.getRequest(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?
4. And should i consider implementing ModifiableSource as the Part is a
File?
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.
Paul.
----
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]
_____________________________________________________________________
This e-mail has been scanned for viruses by MCI's Internet Managed
Scanning Services - powered by MessageLabs. For further information
visit http://www.mci.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
