[Mav-user] Opt-fop and Content-Disposition header
I started playing with opt-fop for use on an upcoming project and I had a couple comments / questions I would like to ask. First I would like to thank all those involved in producing opt-fop, I think is a very valuable tool. From my quick over of the source I notice that the content type is specified based on the fop render type, however there doesn't seem to be any support for setting a Content-Disposition header. I'm sure there are many cases where the browser will automatically launch an app for the given content type, however for my use I need the browser to prompt the user to save the file with a suggested filename. Currently on browsers that don't have a handler for the supplied content type the file is saved as the name of the command executed, 'friendsPdf.m' in the case of the friendbook-fop example. Is there need by others to do the same thing? If so how should it be handled? I was thinking that we could supply a param to the transform with a filename keyword, or possibly adding an attribute to the transform tag for the filename. What about dynamically producing the filename in the controller; how could this be handled cleanly? -- Mike Moulton [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Work Flow
I thought I'd throw in my 2 cents worth on this workflow issue in relation to Maverick. I have developed a fairly large application under Maverick and have found the maverick.xml file to have grow somewhat unwieldy. I think that with some sort of abstractions added to the maverick.xml features, it could be pared down quite a bit -- some of this might fall under what you're calling workflow. Here's what I mean: 1. All my commands include the following two views: view name=noSession ref=noSession/ view name=systemError ref=systemError/ These two lines are repeated many times through my mav.xml file. It would be nice if when a command were run, that if the view wasn't specified, it would look in some default place. Since putting code in one and only one place is a desirable, then this would help with the understandability and maintenance of the codebase. 2. If I happen to be missing a view, I don't know about it until the program is run and happens across this issue. It would be nice if the controller had an ability to accept a list of views that it needs. We can create this list for each of our controllers -- that's no big deal. Then Maverick could on startup, check that no views are missing from the mav.xml file. Maybe a method like String [] getRequiredViews(). 3. Some sort of namespace convention might also be nice. For example, I have two main areas in my mav.xml file, one area for the main site and another for admin. The admin stuff is intermingled with the main site stuff and it is only through naming conventions that I keep them separate, but it has been the source of a few bugs. I have thought of separating these two areas into two different war files, which would solve the problem, but perhaps there is a structure within mav.xml that can encourage separation also. 4. Regarding workflow in particular, I also have come across cases where I would have liked to remember state as I go through a sequence so I can return to it. For example, it a visitor or guest tries to access a page that requires logging in, I would like to take them to the login workflow, and at the end of that workflow return them to the page they wanted to access in the first place. This would be such a cool and powerful feature. I haven't figured out a way to do this within the current system. Please take these comments within the context they are given: I am a very happy and satisfied Maverick user, and would make the same decision to go with mav today even knowing these limitations! Dan At 07:19 PM 7/18/02 -0400, you wrote: Hello Scott.. I'm going to try to throw a skeleton together so that it can be added to the CVS, so people can help out as they wish. Hopefully early next week (?) there'll be enough for people to follow what's going on and see where they can help. -Roy - Original Message - From: Scott Bechtel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 18, 2002 4:20 PM Subject: [Mav-user] Work Flow Hey guys, I'm very interested in the work flow system since I am ready to create a web site that requires one. If you need any assistance in coding or testing be in touch. Scott Bechtel [EMAIL PROTECTED] www.newconquest.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Work Flow
From: Dan Finkelstein [EMAIL PROTECTED] I thought I'd throw in my 2 cents worth on this workflow issue in relation to Maverick. I have developed a fairly large application under Maverick and have found the maverick.xml file to have grow somewhat unwieldy. I think that with some sort of abstractions added to the maverick.xml features, it could be pared down quite a bit -- some of this might fall under what you're calling workflow. Here's what I mean: 1. All my commands include the following two views: view name=noSession ref=noSession/ view name=systemError ref=systemError/ These two lines are repeated many times through my mav.xml file. It would be nice if when a command were run, that if the view wasn't specified, it would look in some default place. Since putting code in one and only one place is a desirable, then this would help with the understandability and maintenance of the codebase. I agree with you on this, but I don't think it's in the scope of what I'm working on. When I first started using Mav, I figured that since I'm specifying global views with the views tag, then they shouldn't need to be referenced in each command. I believe that something like this would require a patch to the current source, and not an addon, but it would be nice to have. 2. If I happen to be missing a view, I don't know about it until the program is run and happens across this issue. It would be nice if the controller had an ability to accept a list of views that it needs. We can create this list for each of our controllers -- that's no big deal. Then Maverick could on startup, check that no views are missing from the mav.xml file. Maybe a method like String [] getRequiredViews(). I don't follow you on this one. If you're going through the trouble of making a list of views per controller, can't you just check your xml file to make sure that each controller has it's appropriate views? Seems like double work, if I'm understanding you correctly. 3. Some sort of namespace convention might also be nice. For example, I have two main areas in my mav.xml file, one area for the main site and another for admin. The admin stuff is intermingled with the main site stuff and it is only through naming conventions that I keep them separate, but it has been the source of a few bugs. I have thought of separating these two areas into two different war files, which would solve the problem, but perhaps there is a structure within mav.xml that can encourage separation also. So each command would have a name and an optional namespace? I can understand your need for that, but again, that's out of the scope of the project I'm working on. After working on huge projects using Struts, I've gotten very good at creating naming conventions for my commands and views, and grouping them in the XML file. Given Mav's philosophy, adding a namespace might add unnecessary complications. 4. Regarding workflow in particular, I also have come across cases where I would have liked to remember state as I go through a sequence so I can return to it. For example, it a visitor or guest tries to access a page that requires logging in, I would like to take them to the login workflow, and at the end of that workflow return them to the page they wanted to access in the first place. This would be such a cool and powerful feature. I haven't figured out a way to do this within the current system. This is the kind of functionality you'll be able to get (and more!!) with the project I'm working on. A command generates a call to a workflow (in this case, the workflow handles logging in a user) and after that workflow does it's thing, it returns to where it's told. I'm trying to make it as flexible and extendable as possible, so people who have special needs from a workflow can create their own and plug it in. Please take these comments within the context they are given: I am a very happy and satisfied Maverick user, and would make the same decision to go with mav today even knowing these limitations! Dan At 07:19 PM 7/18/02 -0400, you wrote: Hello Scott.. I'm going to try to throw a skeleton together so that it can be added to the CVS, so people can help out as they wish. Hopefully early next week (?) there'll be enough for people to follow what's going on and see where they can help. -Roy - Original Message - From: Scott Bechtel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 18, 2002 4:20 PM Subject: [Mav-user] Work Flow Hey guys, I'm very interested in the work flow system since I am ready to create a web site that requires one. If you need any assistance in coding or testing be in touch. Scott Bechtel [EMAIL PROTECTED] www.newconquest.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven.
Re: [Mav-user] Opt-fop and Content-Disposition header
Hello everyone, I am not very active on this list, but now I start a project implementing Maverick and I would be very pleased if the ideas of Jim could be converted in the next version. How is the priority of several transform types? view name=success type=document path=queryResult.jsp transform type=xslt path=lookAndFeel.xsl/ transform type=fop/ /view Which will the client see, if he requests the page? Sorry for my bad english.. ;-) Regards, Phil --- jim moore [EMAIL PROTECTED] schrieb: Right now it is possible to set the content-dispostion header directly from the controller. You can get the Response from the ControllerContext and then just call response.setHeader() on it. Even when the repsonse is wrapped, the setHeader() calls are passed through to the real underlying response. I think this is pretty straightforward and intuitive, so I don't think there is really a need to change it (though I am open to hearing other thoughts on this). If people still think its worthwhile to have this defined in maverick.xml, I have a couple of ideas. We could add two optional attributes to the fop transform node: filename and content-type. Filename is pretty self-explanatory. Content-type would take either inline (which would be the default) and attachment. Together these two would produce a content-disposition header something like: Content-disposition: attachment; filename=myfile.pdf So you would have a node that looked something like: transform type=fop output=pdf content-type=attachment filename=myfile.pdf/ Even if we add this, I still think the controller should take precedence. Since it runs before the transform, opt-fop could check for the presence of the content-disposition header. It would only set it if it didn't find it. Does this make sense? What are everyone's thoughts? Do you think setting the header from the controller is sufficient, or should we add these params to the transform node? --jim - Original Message - From: Mike Moulton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 4:35 AM Subject: [Mav-user] Opt-fop and Content-Disposition header I started playing with opt-fop for use on an upcoming project and I had a couple comments / questions I would like to ask. First I would like to thank all those involved in producing opt-fop, I think is a very valuable tool. From my quick over of the source I notice that the content type is specified based on the fop render type, however there doesn't seem to be any support for setting a Content-Disposition header. I'm sure there are many cases where the browser will automatically launch an app for the given content type, however for my use I need the browser to prompt the user to save the file with a suggested filename. Currently on browsers that don't have a handler for the supplied content type the file is saved as the name of the command executed, 'friendsPdf.m' in the case of the friendbook-fop example. Is there need by others to do the same thing? If so how should it be handled? I was thinking that we could supply a param to the transform with a filename keyword, or possibly adding an attribute to the transform tag for the filename. What about dynamically producing the filename in the controller; how could this be handled cleanly? -- Mike Moulton [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Opt-fop and Content-Disposition header
- Original Message - From: Philip Meier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 5:28 PM Subject: Re: [Mav-user] Opt-fop and Content-Disposition header Hello everyone, I am not very active on this list, but now I start a project implementing Maverick and I would be very pleased if the ideas of Jim could be converted in the next version. So I guess that's one +1 How is the priority of several transform types? view name=success type=document path=queryResult.jsp transform type=xslt path=lookAndFeel.xsl/ transform type=fop/ /view The priority is strictly linear based on the order in the maverick.xml file. The view will always run first, the the transforms will be run in the order they appear. In this case, the jsp queryResult.jsp will run first. The output of that jsp will be run through the stylesheet lookAndFeel.xsl. Then the output of that transformation will serve as the input for the fop transform. Couple of things to note. Since the result of queryResult.jsp will serve as the input to lookAndFeel.xsl, you need to make sure that queryResult.jsp produces a valid xml document. Then you need to make sure that the input to fop is a valid fo document. The maxTransforms param is excellent for debugging this as you can use it to halt the transform process at a given step. Which will the client see, if he requests the page? The client will see a pdf. Sorry for my bad english.. ;-) No worries. I'm struggling to learn portuguese right now, so I understand how it is. --jim Regards, Phil --- jim moore [EMAIL PROTECTED] schrieb: Right now it is possible to set the content-dispostion header directly from the controller. You can get the Response from the ControllerContext and then just call response.setHeader() on it. Even when the repsonse is wrapped, the setHeader() calls are passed through to the real underlying response. I think this is pretty straightforward and intuitive, so I don't think there is really a need to change it (though I am open to hearing other thoughts on this). If people still think its worthwhile to have this defined in maverick.xml, I have a couple of ideas. We could add two optional attributes to the fop transform node: filename and content-type. Filename is pretty self-explanatory. Content-type would take either inline (which would be the default) and attachment. Together these two would produce a content-disposition header something like: Content-disposition: attachment; filename=myfile.pdf So you would have a node that looked something like: transform type=fop output=pdf content-type=attachment filename=myfile.pdf/ Even if we add this, I still think the controller should take precedence. Since it runs before the transform, opt-fop could check for the presence of the content-disposition header. It would only set it if it didn't find it. Does this make sense? What are everyone's thoughts? Do you think setting the header from the controller is sufficient, or should we add these params to the transform node? --jim - Original Message - From: Mike Moulton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 4:35 AM Subject: [Mav-user] Opt-fop and Content-Disposition header I started playing with opt-fop for use on an upcoming project and I had a couple comments / questions I would like to ask. First I would like to thank all those involved in producing opt-fop, I think is a very valuable tool. From my quick over of the source I notice that the content type is specified based on the fop render type, however there doesn't seem to be any support for setting a Content-Disposition header. I'm sure there are many cases where the browser will automatically launch an app for the given content type, however for my use I need the browser to prompt the user to save the file with a suggested filename. Currently on browsers that don't have a handler for the supplied content type the file is saved as the name of the command executed, 'friendsPdf.m' in the case of the friendbook-fop example. Is there need by others to do the same thing? If so how should it be handled? I was thinking that we could supply a param to the transform with a filename keyword, or possibly adding an attribute to the transform tag for the filename. What about dynamically producing the filename in the controller; how could this be handled cleanly? -- Mike Moulton [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
Re: [Mav-user] Opt-fop and Content-Disposition header
Jim, Thanks for the quick response, I should of realized that I can set the header from my controllers. However this made me think about times when there is no controller present. For cases like these, I think the aformentioned solution of adding the content-type and filename attributes is perfect. I also agree that if the controller sets the content-disposition header then that should take presedent over anything in the mav config. -Mike On 7/22/02 9:04 AM, jim moore [EMAIL PROTECTED] wrote: Right now it is possible to set the content-dispostion header directly from the controller. You can get the Response from the ControllerContext and then just call response.setHeader() on it. Even when the repsonse is wrapped, the setHeader() calls are passed through to the real underlying response. I think this is pretty straightforward and intuitive, so I don't think there is really a need to change it (though I am open to hearing other thoughts on this). If people still think its worthwhile to have this defined in maverick.xml, I have a couple of ideas. We could add two optional attributes to the fop transform node: filename and content-type. Filename is pretty self-explanatory. Content-type would take either inline (which would be the default) and attachment. Together these two would produce a content-disposition header something like: Content-disposition: attachment; filename=myfile.pdf So you would have a node that looked something like: transform type=fop output=pdf content-type=attachment filename=myfile.pdf/ Even if we add this, I still think the controller should take precedence. Since it runs before the transform, opt-fop could check for the presence of the content-disposition header. It would only set it if it didn't find it. Does this make sense? What are everyone's thoughts? Do you think setting the header from the controller is sufficient, or should we add these params to the transform node? --jim --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
RE: [Mav-user] Work Flow
Just a couple comments: In Maverick 1.0, global views were automatically visible from all commands. While this did provide a more terse syntax for the config file, it tended to result in a lot of programming mistakes, both name collisions and forgetting to name views because it looked like there was only one view to be used. There are a couple ways of simplifying the config file though. The first is that you can specify an XSLT transformation which is run against the config file just prior to processing. So you could define commands like this: command name=foo requireSession=true ... /command And have an XSLT that that adds your extra views when the requireSession attribute is found. This is a lot more flexible than building some sort of namespacing facility into Maverick. The other thing you can do to simplify your maverick config file is to split it up into separate individual files. No maverick features are necessary; this can be done by using the ENTITY features of XML parsers. A good explanation for how to do this can be found here: http://www.docbook.org/tdg/en/html/ch01.html#s-entities Dan, if all you're trying to do is remember state so that (for instance) a user can be redirected to the original destination after logging in, this is pretty easy to do - just store the destination in the session attributes. A workflow framework might be nice, but it's pretty easy to do by hand. Jeff Schnitzer [EMAIL PROTECTED] P.S. Today I officially left the fun-filled world of free agency and became a Maxoid! :-) So much for free time! P.P.S. If anyone is in the San Francisco area tomorrow (7/23) night, I'm hosting a dinner party at my new digs in the Mission. Scott will be there too. Email me privately and I'll send details. -Original Message- From: Roy Truelove [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:42 AM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] Work Flow From: Dan Finkelstein [EMAIL PROTECTED] I thought I'd throw in my 2 cents worth on this workflow issue in relation to Maverick. I have developed a fairly large application under Maverick and have found the maverick.xml file to have grow somewhat unwieldy. I think that with some sort of abstractions added to the maverick.xml features, it could be pared down quite a bit -- some of this might fall under what you're calling workflow. Here's what I mean: 1. All my commands include the following two views: view name=noSession ref=noSession/ view name=systemError ref=systemError/ These two lines are repeated many times through my mav.xml file. It would be nice if when a command were run, that if the view wasn't specified, it would look in some default place. Since putting code in one and only one place is a desirable, then this would help with the understandability and maintenance of the codebase. I agree with you on this, but I don't think it's in the scope of what I'm working on. When I first started using Mav, I figured that since I'm specifying global views with the views tag, then they shouldn't need to be referenced in each command. I believe that something like this would require a patch to the current source, and not an addon, but it would be nice to have. 2. If I happen to be missing a view, I don't know about it until the program is run and happens across this issue. It would be nice if the controller had an ability to accept a list of views that it needs. We can create this list for each of our controllers -- that's no big deal. Then Maverick could on startup, check that no views are missing from the mav.xml file. Maybe a method like String [] getRequiredViews(). I don't follow you on this one. If you're going through the trouble of making a list of views per controller, can't you just check your xml file to make sure that each controller has it's appropriate views? Seems like double work, if I'm understanding you correctly. 3. Some sort of namespace convention might also be nice. For example, I have two main areas in my mav.xml file, one area for the main site and another for admin. The admin stuff is intermingled with the main site stuff and it is only through naming conventions that I keep them separate, but it has been the source of a few bugs. I have thought of separating these two areas into two different war files, which would solve the problem, but perhaps there is a structure within mav.xml that can encourage separation also. So each command would have a name and an optional namespace? I can understand your need for that, but again, that's out of the scope of the project I'm working on. After working on huge projects using Struts, I've gotten very good at creating naming conventions for my commands and views, and grouping them in the XML file. Given Mav's philosophy, adding a namespace might add unnecessary complications. 4. Regarding workflow
Re: [Mav-user] Work Flow
Good points. On 2, I've noticed that I end up with lots of controllers, and there are a whole slew of named views which might be called. When I'm writing a controller, it's pretty clear to me which views are actually used, so I could easily enumerate them. On the other hand, trying to go through one controller manually after the fact (let alone 50) and weed out which views are used is error-prone. You know, some views could come from inherited classes or whereever. Without this feature, my tendency is to add in views left, right and center in the hopes of not missing one. I'm just suggesting that each controller has n different exit paths, and ensuring a one-to-one mapping is error-prone. I'll look forward to your workflow system, Dan At 01:41 PM 7/22/02 -0400, you wrote: From: Dan Finkelstein [EMAIL PROTECTED] I thought I'd throw in my 2 cents worth on this workflow issue in relation to Maverick. I have developed a fairly large application under Maverick and have found the maverick.xml file to have grow somewhat unwieldy. I think that with some sort of abstractions added to the maverick.xml features, it could be pared down quite a bit -- some of this might fall under what you're calling workflow. Here's what I mean: 1. All my commands include the following two views: view name=noSession ref=noSession/ view name=systemError ref=systemError/ These two lines are repeated many times through my mav.xml file. It would be nice if when a command were run, that if the view wasn't specified, it would look in some default place. Since putting code in one and only one place is a desirable, then this would help with the understandability and maintenance of the codebase. I agree with you on this, but I don't think it's in the scope of what I'm working on. When I first started using Mav, I figured that since I'm specifying global views with the views tag, then they shouldn't need to be referenced in each command. I believe that something like this would require a patch to the current source, and not an addon, but it would be nice to have. 2. If I happen to be missing a view, I don't know about it until the program is run and happens across this issue. It would be nice if the controller had an ability to accept a list of views that it needs. We can create this list for each of our controllers -- that's no big deal. Then Maverick could on startup, check that no views are missing from the mav.xml file. Maybe a method like String [] getRequiredViews(). I don't follow you on this one. If you're going through the trouble of making a list of views per controller, can't you just check your xml file to make sure that each controller has it's appropriate views? Seems like double work, if I'm understanding you correctly. 3. Some sort of namespace convention might also be nice. For example, I have two main areas in my mav.xml file, one area for the main site and another for admin. The admin stuff is intermingled with the main site stuff and it is only through naming conventions that I keep them separate, but it has been the source of a few bugs. I have thought of separating these two areas into two different war files, which would solve the problem, but perhaps there is a structure within mav.xml that can encourage separation also. So each command would have a name and an optional namespace? I can understand your need for that, but again, that's out of the scope of the project I'm working on. After working on huge projects using Struts, I've gotten very good at creating naming conventions for my commands and views, and grouping them in the XML file. Given Mav's philosophy, adding a namespace might add unnecessary complications. 4. Regarding workflow in particular, I also have come across cases where I would have liked to remember state as I go through a sequence so I can return to it. For example, it a visitor or guest tries to access a page that requires logging in, I would like to take them to the login workflow, and at the end of that workflow return them to the page they wanted to access in the first place. This would be such a cool and powerful feature. I haven't figured out a way to do this within the current system. This is the kind of functionality you'll be able to get (and more!!) with the project I'm working on. A command generates a call to a workflow (in this case, the workflow handles logging in a user) and after that workflow does it's thing, it returns to where it's told. I'm trying to make it as flexible and extendable as possible, so people who have special needs from a workflow can create their own and plug it in. Please take these comments within the context they are given: I am a very happy and satisfied Maverick user, and would make the same decision to go with mav today even knowing these limitations! Dan At 07:19 PM 7/18/02 -0400, you wrote:
