Re: FileUploadManager
On 06.10.2006 19:34, Steven D. Majewski wrote:
I started with trying the upload: pseudo protocol, and I'm combining
that with using flowscript, because I need to add a bunch of
conditional processing todecide whether to accept the upload file
( and where to put it. )
I'm also using flowscript. And I present the result of the pipeline to
the user as well before it gets finally stored in database, so it is a
quite similar use case. I only do not publish documents. The data of the
uploaded file gets put into a form.
function displayimport(form, requestData) {
var objectType = requestData.getObjectType();
form.showForm("internal-display-import-" + objectType);
if (form.submitId == 'cancel') {
// back to list view
cocoon.sendPage('display-list-' + objectType);
} else {
// transform uploaded file into DOM
var pipelineUtil =
cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
var doc = pipelineUtil.processToDOM("internal-import-" +
objectType, null);
cocoon.disposeObject(pipelineUtil);
// prepare the request to display the DOM data
var requestData = getRequestData();
requestData.setResultObject(doc);
requestData.setObjectType("legalcase-import");
requestData.setViewType("list");
setRequestData(requestData);
displayRequestData();
}
}
(Sorry, my JavaScript code is not object-oriented, what makes it a bit
ugly. The code is three years old, so forgive me please ;) )
displayRequestData() finally shows a form containing the data of the
file. The actual uploaded file is no longer needed and I don't care for it.
The pipeline snippet I posted in my last mail was the one matching on
"internal-import-*".
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: FileUploadManager
> What I need to add is to:
>protect the upload form with auth-manager;
>add some session logic to figure out where the file goes;
>display the page first -- ask if it's OK to publish
> if OK, move to where it belongs and display again, giving the
final published URL for doc.
I think continuations can help you here. I recall suggesting using
sendPageAndWait, which basically means using continuations. I'll try
give some more details on how to implement this.
What you need is a confirmation form. Or perhaps adding a confirm button
below the preview of the document would suffice. Lets call the match you
use for that 'confirm-xml-upload' (might be your 'xml-upload-doc'
match). I'll leave the implementation of that match to you. Next to this
you will need to be able to reenter your flow function once the user has
confirmed or declined the upload. For this you can add a match with for
instance this pattern 'xml-upload-continue/*':
The {1} is a so-called continuation-id. Make sure to retrieve it from
the context when generating the confirmation page and append it to the
action of the form (or the confirm/decline url).
I imagine that the actual confirmation is a parameter named 'confirmed'
having the value 'true' or 'false'. You can pick something of your own
taste if you like, just using this to explain the last part: flowscript
changes..
You need to extend your upload function. Change the cocoon.sendPage line
into cocoon.sendPageAndWait('confirm-xml-upload', {}); Once the user
enters the xml-upload-continue/* match, this function is reactivated and
continued at the sendPageAndWait position, using the continuation id! (I
am still amazed that the Cocoon developers made this work :) Yes, there
can be lots of continuations running simultaniously, so the
continuation-id is very important.
Once execution has been continued, you have access to the second request
object, which should contain the confirmation parameter. Read it and
decide to delete the upload or move it to a permanent location. Your
function would become something like:
function upload() {
var docsrc = cocoon.request.getParameter( "pubxml");
// make a copy of uploaded file to tmp ...
if ( FileHelper.fileExists( docsrc ) ) {
var doc = java.io.File( docsrc );
FileHelper.copy( doc, java.io.File (
cocoon.parameters.temp_dir, doc.getName() ));
}
cocoon.sendPageAndWait( 'confirm-xml-upload' , {} );
var confirmed = (cocoon.request.getParameter("confirmed") ==
"true");
if (confirmed)
// move the uploaded file to perminant location ...
FileHelper.copy(
java.io.File ( cocoon.parameters.temp_dir, doc.getName()
),
java.io.File ( cocoon.parameters.uploads_dir,
doc.getName() )
);
cocoon.sendPage( 'show-doc' , {} );
} else {
FileHelper.delete(
java.io.File ( cocoon.parameters.temp_dir, doc.getName()
)
};
cocoon.sendPage ( 'upload-cancelled', {} );
}
}
Few additional recommendations:
- About authentication: you could reroute the initial upload request
through a flow function that will either show an 'authorization denied'
message if not cleared or the upload form if cleared. But make sure to
recheck the authorization at the actual upload!
- About pipelines: it is not necessary to put each match in a different
pipeline. :-) Usually you put cachable and noncachable matches together,
but keep in mind that they are tested against the url's from top to
bottom and the first match is executed.
- I would recommend to base your xml-upload-xml and xml-upload-doc
matches on the temp dir, not on upload protocol. That makes them
accessible after a continue as well. :-)
- You can define global variable in a sitemap and refer to them like
{global:nameofvar}. Shouldn't be difficult to found out about how to
define them on the cocoon website.
Kind regards,
Geert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
I also found the examples on the Wiki both helpful and confusing.
I started with trying the upload: pseudo protocol, and I'm combining
that with
using flowscript, because I need to add a bunch of conditional
processing to
decide whether to accept the upload file ( and where to put it. )
I'm in the middle of that right now -- I'll try to post a recipe when
I'm finished,
but since this topic has come up now, I'll post what I have so far:
In my sitemap I have:
The upload form in upload.jx has (among other things):
id="UPLOAD_FORM" name="UPLOAD_FORM" >
On my first attempt, the action was directed to the xml-upload-doc pipe.
Now it's directed to the flowscript, which at the moment, just
copies the
file from the upload directory to another temp directory so that it
will still
exist after the pipeline completes, and calls the xml-upload-doc page
to display styled output.
importClass( Packages.org.apache.commons.transaction.util.FileHelper );
function upload() {
var docsrc = cocoon.request.getParameter( "pubxml");
// make a copy of uploaded file to tmp ...
if ( FileHelper.fileExists( docsrc ) ) {
var doc = java.io.File( docsrc );
FileHelper.copy( doc, java.io.File
( cocoon.parameters.temp_dir, doc.getName() ));
}
cocoon.sendPage( 'xml-upload-doc' , {} );
}
What I need to add is to:
protect the upload form with auth-manager;
add some session logic to figure out where the file goes;
display the page first -- ask if it's OK to publish
if OK, move to where it belongs and display again, giving
the final published URL for doc.
( I know the document is removed from the upload directory when the
pipeline is complete.
I'm not quite sure, in the presence of flowscript continuations w/
sendPageAndWait, how
long the file will remain. I'm guessing it will be safer to move it
to my own temp space first. )
[ This is with Cocoon 2.1.9 BTW ]
-- Steve Majewski / UVA Alderman Library
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
On 06.10.2006 09:17, Richard Light wrote: It's a wiki. It's simply a collection of pages. Its biggest problem is mostly to find the correct information. And it's about the wiki user to link those pages as they need them. I.e. a wiki lives from the participation of its users. I assume the Wiki uses Cocoon ... ? No, it is not. It's a central Apache wiki, not only used for Cocoon. It's based on MoinMoin. Another one is though: http://cocoon.zones.apache.org/daisy/. It's not used for wikifying information, it's for writing our official documentation. The many links on the start page might a bit confusing. There is one already: http://wiki.apache.org/cocoon/FileUploadsWithCocoon2.1 I have added a link from this page to the one I found. Ok, thanks. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
In message <[EMAIL PROTECTED]>, Joerg Heinicke <[EMAIL PROTECTED]> writes It's a wiki. It's simply a collection of pages. Its biggest problem is mostly to find the correct information. And it's about the wiki user to link those pages as they need them. I.e. a wiki lives from the participation of its users. I assume the Wiki uses Cocoon ... ? If so, some sort of "site map" capability would be a useful addition. That's what I'm doing with my own application, using a Topic Map to create a self-organising hierarchy of pages within the site. To comeback to the wiki issue: Maybe somebody can set up an upload in Cocoon overview page with linking to all the different techniques. There is one already: http://wiki.apache.org/cocoon/FileUploadsWithCocoon2.1 I have added a link from this page to the one I found. Richard -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
On 04.10.2006 15:41, Richard Light wrote: Just to report back: I have now got file uploading working, but only because I found this resource through a search of the Wiki: http://wiki.apache.org/cocoon/RecipeUploadUsingAction This code compiled and ran first time. Thanks for reporting back. Shouldn't this page be linked to from the general upload pages? It's a wiki. It's simply a collection of pages. Its biggest problem is mostly to find the correct information. And it's about the wiki user to link those pages as they need them. I.e. a wiki lives from the participation of its users. I never did have any luck with the Flow technique described in http://wiki.apache.org/cocoon/FileUploadsWithFlow because, I think, of a class loading error which prevented Cocoon from initializing itself. Are other Cocoon users happily using the Flow technique for uploads? When I implemented an upload in 2004 I used the upload:// pseudo protocol. But I have not done it lately and I don't know if it is better or worse than the other solution. It probably won't work for all cases as I process the uploaded file directly in the pipeline: "file" is the name of the field in the form. The rest is some Chaperon stuff converting CSV file (Excel output) to some XML. To comeback to the wiki issue: Maybe somebody can set up an upload in Cocoon overview page with linking to all the different techniques. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
Just to report back: I have now got file uploading working, but only because I found this resource through a search of the Wiki: http://wiki.apache.org/cocoon/RecipeUploadUsingAction This code compiled and ran first time. Shouldn't this page be linked to from the general upload pages? I never did have any luck with the Flow technique described in http://wiki.apache.org/cocoon/FileUploadsWithFlow because, I think, of a class loading error which prevented Cocoon from initializing itself. Are other Cocoon users happily using the Flow technique for uploads? Richard Light In message <[EMAIL PROTECTED]>, Richard Light <[EMAIL PROTECTED]> writes Hi, Does anyone have any thoughts on this problem? I've spent the whole day not getting any further with it, although I now understand a bit better how Cocoon works. The problem is definitely in the second half of the Wiki "how to" description (setting up a FileUploadManager): http://wiki.apache.org/cocoon/FileUploadsWithFlow I have faithfully carried out steps 1-5, and this certainly has an effect, but when I re-start Cocoon I get an initialisation error as outlined below, whatever page I try to access. Interestingly, the error message is the same whether or not I have copied the cocoon-upload jar into the WEB-INF\lib directory. (Does this suggest it is looking in the wrong place for it? If so, what setting controls this?) Thanks, Richard Light -Original message- Subject: FileUploadManager To: users@cocoon.apache.org From:Richard Light <[EMAIL PROTECTED]> Date:Fri, 29 Sep 2006 17:57:09 +0100 In message <[EMAIL PROTECTED]>, Joerg Heinicke <[EMAIL PROTECTED]> writes On 20.09.2006 17:11, Richard Light wrote: After much trial and error, I was able to get it at least start (I haven't tried actually uploading any files yet!) by altering the user.xroles file provided on the Wiki page. I changed the shorthand attribute in the element from "upload_manager" to "upload-manager", and the loading problem went away. Strange but true! I think the @shorthand must only match the entry (element name) in the cocoon.xconf. So the wiki entry looks ok for me. Are you sure, you only changed it in the roles file? Now that I have 2.1.9 installed, I'm coming back to this issue. You're quite right: the user.xroles @shorthand simply needs to match the element name in cocoon.xconf. However ... what I am finding is that if they _do_ match, I get an initialization problem: - Message: org.apache.cocoon.components.upload.FileUploadManagerImpl Description: org.apache.avalon.framework.configuration.ConfigurationException: Could not get class Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet - The file cocoon-uploads.jar (which contains the definition of the FileUploadManagerImpl class) is sitting in the directory WEB-INF\lib, but Cocoon is clearly failing to find it. Do I need to declare it somewhere else, e.g. in the sitemap? Richard -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] -End of original message from Richard Light- -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
Hi, Does anyone have any thoughts on this problem? I've spent the whole day not getting any further with it, although I now understand a bit better how Cocoon works. The problem is definitely in the second half of the Wiki "how to" description (setting up a FileUploadManager): http://wiki.apache.org/cocoon/FileUploadsWithFlow I have faithfully carried out steps 1-5, and this certainly has an effect, but when I re-start Cocoon I get an initialisation error as outlined below, whatever page I try to access. Interestingly, the error message is the same whether or not I have copied the cocoon-upload jar into the WEB-INF\lib directory. (Does this suggest it is looking in the wrong place for it? If so, what setting controls this?) Thanks, Richard Light --- Begin Message --- In message <[EMAIL PROTECTED]>, Joerg Heinicke <[EMAIL PROTECTED]> writes On 20.09.2006 17:11, Richard Light wrote: After much trial and error, I was able to get it at least start (I haven't tried actually uploading any files yet!) by altering the user.xroles file provided on the Wiki page. I changed the shorthand attribute in the element from "upload_manager" to "upload-manager", and the loading problem went away. Strange but true! I think the @shorthand must only match the entry (element name) in the cocoon.xconf. So the wiki entry looks ok for me. Are you sure, you only changed it in the roles file? Now that I have 2.1.9 installed, I'm coming back to this issue. You're quite right: the user.xroles @shorthand simply needs to match the element name in cocoon.xconf. However ... what I am finding is that if they _do_ match, I get an initialization problem: - Message: org.apache.cocoon.components.upload.FileUploadManagerImpl Description: org.apache.avalon.framework.configuration.ConfigurationException: Could not get class Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet - The file cocoon-uploads.jar (which contains the definition of the FileUploadManagerImpl class) is sitting in the directory WEB-INF\lib, but Cocoon is clearly failing to find it. Do I need to declare it somewhere else, e.g. in the sitemap? Richard -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] --- End Message --- -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
In message <[EMAIL PROTECTED]>, Joerg Heinicke <[EMAIL PROTECTED]> writes On 20.09.2006 17:11, Richard Light wrote: After much trial and error, I was able to get it at least start (I haven't tried actually uploading any files yet!) by altering the user.xroles file provided on the Wiki page. I changed the shorthand attribute in the element from "upload_manager" to "upload-manager", and the loading problem went away. Strange but true! I think the @shorthand must only match the entry (element name) in the cocoon.xconf. So the wiki entry looks ok for me. Are you sure, you only changed it in the roles file? Now that I have 2.1.9 installed, I'm coming back to this issue. You're quite right: the user.xroles @shorthand simply needs to match the element name in cocoon.xconf. However ... what I am finding is that if they _do_ match, I get an initialization problem: - Message: org.apache.cocoon.components.upload.FileUploadManagerImpl Description: org.apache.avalon.framework.configuration.ConfigurationException: Could not get class Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet - The file cocoon-uploads.jar (which contains the definition of the FileUploadManagerImpl class) is sitting in the directory WEB-INF\lib, but Cocoon is clearly failing to find it. Do I need to declare it somewhere else, e.g. in the sitemap? Richard -- Richard Light SGML/XML and Museum Information Consultancy [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUploadManager
On 20.09.2006 17:11, Richard Light wrote: After much trial and error, I was able to get it at least start (I haven't tried actually uploading any files yet!) by altering the user.xroles file provided on the Wiki page. I changed the shorthand attribute in the element from "upload_manager" to "upload-manager", and the loading problem went away. Strange but true! I think the @shorthand must only match the entry (element name) in the cocoon.xconf. So the wiki entry looks ok for me. Are you sure, you only changed it in the roles file? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
