RE: FileUploadManager

2006-10-07 Thread Geert Josten
 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/*':

   map:match pattern=xml-upload-continue/*
 map:call continuation={1} /
   /map:match

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: Cannot get JSPReader/JSPGenerator to work

2006-10-07 Thread Laurent Perez

If you want to use JSPs AND Cocoon, you really might have a look on
Cocoon 2.2 as it easies the integration. Cocoon 2.1 uses it's own
environment abstraction.


I'm using JSPs an Cocoon 2.2, but I still don't understand if I did
the right integration : basically, my usecase requires custom JSP
tags to be able to retrieve XML from sitemap patterns. Under 2.1, I
wrote an integration method starting up a CocoonBean instance and use
resolveURI() on it, but it was quite ugly, so since I was already
using Spring, I switched to 2.2 and what I did was to add a setter for
a SourceResolver in my base custom tag class and then dependency
inject it via my applicationContext.xml in spring/ folder (my base
custom tag class uses a @Configurable to let the injections work).

The wiring works, all my custom tags can use the injected resolver,
but I HAD to enable the Cocoon JSPReader (map:match pattern=**.jsp,
map:read src(...) type=jsp) to deliver my jsps, otherwise the called
resolver would throw an exception saying it requires an Environment
setup in order to work.

So, it looks like I'm still using a 2.2 environment abstraction, but
your post confuses me : would the block:/ protocol ease my integration
?

thanks,
laurent

--
a href=http://in-pocket.blogspot.com;http://in-pocket.blogspot.com
- Mobile world, technology and more/a

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]