Re: RFC: BLOBAction
You know Martin, I was all set to reply with two or three points that I THOUGHT were valid against this, but as I started writing them up (I think three or four messages began and aborted!) I decided what you've done I actually DO like! :) The one comment that remains is this... The approach I was trying to take with my code was, if you make the assumption that the parameters I was passing got added as action attributes as I intended, was a declarative one. I wanted to have one generic Action that would, just with some entries in a configuration file, allow for serving objects from the file system or a database. My feeling is that Struts is already largely declarative in nature, so why not stick with that model? The code you've written certainly doesn't preclude that, but it doesn't address it either. So, maybe I can suggest a little bit of a hybrid approach... What I'm thinking is what if we still added some or all of the parameters my code uses to the action mappings (mostly optional of course)... One new attribute would also be a StreamInfo implementation class name which would be instantiated in the Action... The class gets instantiated in your getStreamInfo() method of the Action, then everything proceeds as you've done. Doing this, we would have the ability to, for instance, have a DatabaseStreamInfo class that knows how to read the database-relevant attributes from the ActionMapping and return the input stream. Likewise for serving from the file system. I guess what I'm actually get at is a generic implementation of your abstract DownloadAction that can work based on Action mapping attributes, but someone could of course still implement their own version as well. What are your thoughts about that? -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, September 21, 2004 1:51 am, Martin Cooper said: I'd been thinking about something in between. How about an Action that does all the drudge work, but leaves the details to the implementor? Something, perhaps, like this: http://www.apache.org/~martinc/struts/DownloadAction.java This provides easy solutions for downloading files from the file system, resources from a web app, or a completely custom solution, if you don't like either of those. -- Martin Cooper On Mon, 20 Sep 2004, Craig McClanahan wrote: On Mon, 20 Sep 2004 09:57:00 +0200, Reinhard Nägele [EMAIL PROTECTED] wrote: Streaming files back to the reponse is really nothing special, and it's not exactly a Struts-specific thing. A simple Booch utitlity class would serve the purpose. I agree with Reinhard's reasons that something this specific to particular data access mechanisms might not be appropriate as a part of the core framework. That being said, questions about downloading binary data come up often enough that something like this would make a dandy example application. Reinhard Craig - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction and Struts Bloat
Thanks for your comments, Michael. If you've been following the dev list lately, you've seen some beginning discussions on a Struts 2.0 rearchitecting that would indeed leverage everything we've all learned in the four years since Struts was first created. I have some specific proposals to make in this regard, which I'll be sharing when I return from an extended trip next week. That being said, one of the factors that has made Struts so popular is a commitment to take care of existing users. It would be somewhat irresponsible for us to completely stopping development of the Struts 1.x architecture, or just doing bug fixes. Therefore, we need to do a 1.3 release in the interim time period, focused on a small number of changes, such as: * Changing base API platform to Servlet 2.3 and JSP 1.2, so Struts apps can count on things like filters and event listeners. * Refactoring the RequestProcessor class to use Commons Chain (based on the code in the contrib/struts-chain) that supports the 1.2 request processing lifecycle semantics, but is more easily customized than the current architecture. You'll also be able to use the Chain paradigm for your own business logic if you like. * Provide a second request processor implementation chain that operates in a portlet (JSR-168) environment. * Split the Struts monolithic release into separate releases of the core framework, the tag libraries, the examples, and so on. This will help us accelerate the turnaround of releases. In the near future, you'll also see the initial release candidate of the Struts-Faces integration library (packaged separately from the rest of Struts) that allows JavaServer Faces to be used with Struts 1.1 or 1.2 based applications, including the use of the Tiles Framework and the Validator Framework. Note that I do *not* see any of the developers interested in continuing the development of the Struts HTML tag libraries, as other view tier choices (like JSF) are becoming available. Craig PS: With regards to migrating to SVN (commented on in one of the replies), doing both 1.3 and 2.0 together on SVN will be vastly more productive than using CVS for 1.3 and SVN for 2.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFC: BLOBAction and Struts Bloat
Craig, In the near future, you'll also see the initial release candidate of the Struts-Faces integration library (packaged separately from the rest of Struts) that allows JavaServer Faces to be used with Struts 1.1 or 1.2 based applications, including the use of the Tiles Framework and the Validator Framework. will the Struts-Faces integration library be a subproject of Apache Struts? Like http://struts.apache.org/struts-faces for instance? Or what are your plans on it? Note that I do *not* see any of the developers interested in continuing the development of the Struts HTML tag libraries, as other view tier choices (like JSF) are becoming available. Btw. like Michael, I am interessted in your proposals on Struts 2.0 too :) Matthias Craig PS: With regards to migrating to SVN (commented on in one of the replies), doing both 1.3 and 2.0 together on SVN will be vastly more productive than using CVS for 1.3 and SVN for 2.0. - 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]
Re: RFC: BLOBAction and Struts Bloat
Matthias Wessendorf wrote: Craig, Btw. like Michael, I am interessted in your proposals on Struts 2.0 too :) Checkout this: http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-chain .V -- Please post on Rich Internet Applications User Interface (RiA/SoA) http://www.portalvu.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com I don't really like your approach and don't want to see such an Action added to a Framework like Struts. Here's a few comments why: A big part of the reason I posted this was to see if this was something people thought should be included, so I very much welcome your opinion and thank you for it. * Struts is database-independent. People don't necessarily use plain JDBC. Fair point, but that was the reason I wrote it to work from a database as well as the file system. While the production app I use this in does work from a database, that's obviously not always the way it's done in every case. In addition, although I didn't put this in the comments, but I speficially broke out the getDBConnection() method so that a developer could override it to handle whatever method of DB access they use. True enough, that doesn't remove the JDBC code from the rest of the Action. * You are getting anything you need for accessing your DB from the request, including SQL, username, password, i. e. it would probably have to be included plain text in some JSP. Bad thing... Yes, true, but as my comments stated, I did it this way because I couldn't do it the way I wanted on my own, which is to have most, if not all, of the parameters as attributes of the action tag. I'd still like to keep the ability to use what comes with the request because then you could do things like have a single ImageServerAction that just accepts the query portion with the request with the rest coming from the Action mapping for instance, you could do: img src=/myapp/ImageServerAction.ma?clientid=123 That way, maybe the user can select a client to work with, just insert the ID in the JSP code and your all set with a dynamic logo maybe (this example is exactly what I do in my production app). * I don't like JDBC in Actions. What about separating controller from business logic and database access? I agree in general 100%. However, I wouldn't consider something like this to be business logic per se, and therefore JDBC in the Action is less offensive to me than it otherwise would be. * Your approach is not very flexible. You may not always want to read the data completely into memory before writing it to the response. Yep, someone else pointed this out to me. I hadn't considered that. If for no other reason than performance and server resource utilization, I need to refactor the code to stream the BLOB object. * BTW, it's a good idea to call response.reset() and, if possible, to set the content length before writing to the OutputStream. The content-length was an oversight on my part... My production code DOES do that, but when I re-wrote it to post here I neglected to add that line. My bad, as the young folk say :) Streaming files back to the reponse is really nothing special, and it's not exactly a Struts-specific thing. A simple Booch utitlity class would serve the purpose. I don't argue that. My only point with this was that since this is a common enough activity that many Struts users do, it might be a good candidate for being built-in to Struts, at least to deal with the 95% of cases that it can deal with in a generic way. My response to Craig's comments tie in with this discussion as well, he raises an interesting possibility... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: RFC: BLOBAction]
I agree with Reinhard's reasons that something this specific to particular data access mechanisms might not be appropriate as a part of the core framework. That being said, questions about downloading binary data come up often enough that something like this would make a dandy example application. In that case, maybe I should spend today just using this as the basis for a sample app. I still think that it's a common enough thing that having it built-in to Struts, assuming it's generic enough to handle 95% of the cases that come up, would be a good thing. But I posted this precisely to get opinions on whether people agree with that or not, so if the concensus is that no, it doesn't belong in the core, I'd be just as happy to contribute a sample app (I've had fun using Struts and it has served me well, so anything I cna contribute back would make me happy). Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction and Struts Bloat
There are some things that I certainly agree with michael on and this is one of them. I think ( and i'm not alone in thinking this ) that struts needs a complete overhaul. At present the only reason I use it is because all the existing tooling supports it. eg m7 nitrox, WSAD, MyEclipse etc etc etc If the spring tooling was as mature as this I would use it instead. The project has a reputation for inflexibility, complexity and a lot of unnecessary inheritance. These are all hangovers from EJB with it's multiple interfaces and fixed inheritance approach with the associated difficulties of testing, slow development cycle etc. Struts has done a superb job in the past otherwise it wouldn't be so popular and there is a fantastic pool of talent in the struts development team but it does seem like you are loosing mind-share. If this were not the case there wouldn't be so many copy cat web MVC frameworks springing up. Perhaps it is time for an overhaul of struts. Rather than moving your codebase to subversion perhaps you should leave your 1.* development on CVS and start a completely new attempt for your 2.* series on a fresh server. I do think that struts is a great product and I am a big fan of it's tag libs and the MVC approach in general but I do think that it may be time for a rethink Everything is going POJO, attributes are the way forward. 1.5 will mean that collections are no longer unknown bundles of objects. A lot of people also want AOP features like declaritive behaviour and easier testing. People also want things to be more flexible and have shorter development cycles. I've been a developer for 6 years now. Programmed in about 5 languages and still I find the slowest part of the development cycle is handling the presentation layer with it's multiple reloads etc. I mean i could write a desktop application now with remoting to do the same job quicker than i could write the web interface. That doesn't seem to be the promise offered when people first started developing web applications. And I remember that far back. One thing that I am certainly not suggesting and I want to make this clear is that I am not suggesting that anyone fork the codebase. There is certainly too much clutter surrounding the project at present. It's better if you make it easier to do the difficult stuff rather than vice versa and having everything but the kitchen sink thrown in there doesn't make it any easier. --b approach On Mon, 20 Sep 2004 06:31:24 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Open source and painting are connected in someways. The biggest mistake of the amateur painter is to keep adding colors when the painting is done. The result is always that murky, dark, ugly, look. Likewise, open source, filled with people with egos, sometimes does not know when something is done, finished, damed good and certainly good enough. I have a real concern that Struts is going to continue to be bloated with what are not Struts, not part of the framework, but what are instead really very useful uses of Struts. DispatchAction and its progeny are just one example of this. I would suggest that such offerings would better be managed in a separate application called something like Struts Patterns or Struts Best Practices. Perhaps such classes could be released as classes and either maintained (or preferrably not) independent of Struts? I would hope that by the term bloat I don't convey that such classes are not wonderful ideas and their authors are stellar citizens. It just seems to me that a framework ought to be maintained as a FRAMEWORK and that allowing USES OF THE FRAMEWORK to become part of the framework is a groundwater mistake. Generally, I think it might be better if the actions package were distributed outside Struts proper. As a framework, there comes a time when something like Struts is done, and we need to move on to other things except diligent maintainence and creating clever uses. My present predeliction is to save what presently exists, clean it up by jettisoned what is not needed, and to watch for good ideas that might arise in uses. This is just a thought. There needs to be, I think, a clear separation of Struts patterns or clever uses of Struts and Struts itself. I would suggest that something formal be instituted. Thanks for your ears/eyes on this. Michael McGrady - 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]
Re: RFC: BLOBAction
I'd been thinking about something in between. How about an Action that does all the drudge work, but leaves the details to the implementor? Something, perhaps, like this: http://www.apache.org/~martinc/struts/DownloadAction.java This provides easy solutions for downloading files from the file system, resources from a web app, or a completely custom solution, if you don't like either of those. -- Martin Cooper On Mon, 20 Sep 2004, Craig McClanahan wrote: On Mon, 20 Sep 2004 09:57:00 +0200, Reinhard Nägele [EMAIL PROTECTED] wrote: Streaming files back to the reponse is really nothing special, and it's not exactly a Struts-specific thing. A simple Booch utitlity class would serve the purpose. I agree with Reinhard's reasons that something this specific to particular data access mechanisms might not be appropriate as a part of the core framework. That being said, questions about downloading binary data come up often enough that something like this would make a dandy example application. Reinhard Craig - 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]
Re: RFC: BLOBAction
Ok, I'm not knocking jdbc but for me using hibernate this is what my
action class looks like
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
Long id = new Long(request.getParameter(imageId));
PropertyImage image = (PropertyImage) this.getPropertyImageService()
.getImage(id);
//session.save(propertyImage);
OutputStream outputStream = response.getOutputStream();
response.setContentType(image/jpeg);
outputStream.write(image.getData());
outputStream.flush();
outputStream.close();
//END NEW
return null;
}
I know I'm hung up on hibernate but I cant help it.
--b
On Fri, 17 Sep 2004 11:06:45 -0400 (EDT), Frank W. Zammetti (MLists)
[EMAIL PROTECTED] wrote:
One of the things I see asked very frequently on the Users mailing list is
how to return PDF's and other BLOB fields from a database (or from a file
system). People either have trouble figuring out how to do it and require
help, or have trouble making it work.
Please find attached source for a new Action called BLOBAction that I
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
