On Martin Cooper's DownloadAction...

["Frank W. Zammetti (MLists)" <fz...@omnytex.com>]

Since the thread I originally started with regard to a BLOB download
Action kind of veered off into a different territory, I was hoping
starting a new thread could the discussion get back on topic.  I have a
bit of a vested interest in this now because I started the discussion and
I hate leaving anything undone, so...

The code posted earlier today by Martin Cooper strikes me as a good
approach, better than my own on the whole.  As per my comments in the
previous thread, I'd like to incorporate some of what I did with my
suggested Action however...

Basically, the premise I'm proceeding from is that a large part of Struts
is declarative, I.e., done through config files.  My goal with the Action
I wrote was to continue in that vein.  Although the code I posted got all
it's parameters from the request object for demonstration purposes, I had
always intended them being moved to the Action mappings in struts-config.

Taking Martin's code, I believe this is possible.  The benefit would be to
yield two things... one is the abstract base class itself as Martin wrote
it, which can be extended as required.  Two, we would also get a concrete
implementation that can use the Action attributes from the config file,
thereby allowing developers to declaratively use the download capabilities
without having to write any code.  To me, this is a good thing (tm), and
is frankly in keeping with the whole idea of Struts saving time and
effort.

The way I envision it is an attribute added to the Action mapping that
names the StreamInfo class instance, call it "streamInfoType".  This might
be FileStreamInfo, or DatabaseStreamInfo, etc.  Note that this is IN
ADDITION to the type attribute, but when present the type would always be
the concrete implementation of the DownloadAction (call it the Struts
"srandard" DownloadAction implementation).  If the type was a custom
DownloadAction class, then it may or may not make use of any
streamInfoType attribute that is present, completely up to the developer
at that point.  The "standard" action would then instantiate the correct
StreamInfo class as named by the streamInfoType attribute and make use of
it, setting the attributes in it from the ActionMapping (or overriden by
request, see below) as appropriate for the known StreamInfo type.  For a
download from the file system I would think "filePath" would be it.  For
database downloads, they might be "tableName", "tableField", "tableQuery",
like my original Action had.  I think we'd need to debate what else should
or should not be included in that list though.

In addition, for maximum flexibility, allowing these values to be
overriden by corresponding values in the request should be allowed for.

In short, I believe that persuing this whole idea is a worth-wild exercise
because downloading of BLOB-types is such a common activity I really do
think it belongs in Struts.  I know there will be some debate about the
best way to accomplish it, but as is the case with most things in Struts,
there are numerous ways to accomplish any goal.  Providing developers with
at least one solution built-in that might suffice for 90% of the cases
seems like exactly the thought process that's been used all along
developing the framework.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: On Martin Cooper's DownloadAction...

[Craig McClanahan <cr...@gmail.com>]

While I continue to believe in this functionality as a demonstration
webapp, the underlying problem is that Struts enforces a distinction
between Action and ActionMapping that continually confuses users. 
That's something that I want to fix in Struts2, along the lines of
what WebWork does (configuration parameters in the metadata affect the
"action" instance itself, not a separate configuration object).

Craig



On Wed, 22 Sep 2004 10:20:01 -0400 (EDT), Frank W. Zammetti (MLists)
<fz...@omnytex.com> wrote:
> 
> > The way I envision it is that the app will have a file system-based
> > download by default, and will also have in place the capability to
> > download from a user-defined database if the user wants to, but the app
> > would in no way, by default, require a database.  Probably something as
> > simple as having the required parameters passed via request from a JSP,
> > for demonstration purposes, should suffice.  Does that sound reasonable to
> > you Martin?
> 
> Actually, I take a small part of this back... Since we're talking about
> this sample app using the custom action mappings as well, what I was
> originall thinking was an action apping for file downloads and another for
> database downloads.  The one for database downloads would contain all the
> required attributes in the mapping.
> 
> The point that this doesn't change though, which I think is the central
> point, is that the app doesn't require a database, not by default anyway.
> If a user wanted to see that in action, only then would they have to
> change the config file and make use of whatever database they want.  In my
> view, this is a fair compromise of giving a full, useful example, while
> still not adding and dependencies.  Your thoughts?
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: On Martin Cooper's DownloadAction...

["Frank W. Zammetti (MLists)" <fz...@omnytex.com>]

> The way I envision it is that the app will have a file system-based
> download by default, and will also have in place the capability to
> download from a user-defined database if the user wants to, but the app
> would in no way, by default, require a database.  Probably something as
> simple as having the required parameters passed via request from a JSP,
> for demonstration purposes, should suffice.  Does that sound reasonable to
> you Martin?

Actually, I take a small part of this back... Since we're talking about
this sample app using the custom action mappings as well, what I was
originall thinking was an action apping for file downloads and another for
database downloads.  The one for database downloads would contain all the
required attributes in the mapping.

The point that this doesn't change though, which I think is the central
point, is that the app doesn't require a database, not by default anyway. 
If a user wanted to see that in action, only then would they have to
change the config file and make use of whatever database they want.  In my
view, this is a fair compromise of giving a full, useful example, while
still not adding and dependencies.  Your thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: On Martin Cooper's DownloadAction...

[Martin Cooper <mf...@gmail.com>]

Wow, I didn't expect my quick little abstract class to generate quite
this much discussion! ;-) But since my name is now in the Subject
line, I guess I should say something...

My thinking was that the class I put up for perusal was about as much
as I think we should add to Struts itself, in the 'actions' package.
In fact, I swithered on whether or not to include the concrete
implementations of StreamInfo, rather than only the interface, but
finally decided that, without those, it was perhaps a little *too*
abstract. And I didn't just commit it because I wanted to hear from
people as to whether or not it would be useful.

One or more extensions of DownloadAction, as being discussed in this
thread, would be more suitable for an example app, as Craig has
suggested. I agree with Joe that it would be great to have an example
that includes custom action mappings, and would encourage going down
that path. They *are* a powerful mechanism, as I know from personal
experience, and they're not that hard to use once you get the idea.

One area where I'm less comfortable with an example is introducing a
database to the mix. We've gone to some length to avoid that in the
past - for example with the original example app - and I'm not too
comfortable with changing that now. The less we have to depend on,
specifically with respect to additional setup, the more accessable our
example applications will be to the majority of Struts developers.

--
Martin Cooper


On Tue, 21 Sep 2004 14:23:45 -0400 (EDT), Frank W. Zammetti (MLists)
<fz...@omnytex.com> wrote:
> Since the thread I originally started with regard to a BLOB download
> Action kind of veered off into a different territory, I was hoping
> starting a new thread could the discussion get back on topic.  I have a
> bit of a vested interest in this now because I started the discussion and
> I hate leaving anything undone, so...
> 
> The code posted earlier today by Martin Cooper strikes me as a good
> approach, better than my own on the whole.  As per my comments in the
> previous thread, I'd like to incorporate some of what I did with my
> suggested Action however...
> 
> Basically, the premise I'm proceeding from is that a large part of Struts
> is declarative, I.e., done through config files.  My goal with the Action
> I wrote was to continue in that vein.  Although the code I posted got all
> it's parameters from the request object for demonstration purposes, I had
> always intended them being moved to the Action mappings in struts-config.
> 
> Taking Martin's code, I believe this is possible.  The benefit would be to
> yield two things... one is the abstract base class itself as Martin wrote
> it, which can be extended as required.  Two, we would also get a concrete
> implementation that can use the Action attributes from the config file,
> thereby allowing developers to declaratively use the download capabilities
> without having to write any code.  To me, this is a good thing (tm), and
> is frankly in keeping with the whole idea of Struts saving time and
> effort.
> 
> The way I envision it is an attribute added to the Action mapping that
> names the StreamInfo class instance, call it "streamInfoType".  This might
> be FileStreamInfo, or DatabaseStreamInfo, etc.  Note that this is IN
> ADDITION to the type attribute, but when present the type would always be
> the concrete implementation of the DownloadAction (call it the Struts
> "srandard" DownloadAction implementation).  If the type was a custom
> DownloadAction class, then it may or may not make use of any
> streamInfoType attribute that is present, completely up to the developer
> at that point.  The "standard" action would then instantiate the correct
> StreamInfo class as named by the streamInfoType attribute and make use of
> it, setting the attributes in it from the ActionMapping (or overriden by
> request, see below) as appropriate for the known StreamInfo type.  For a
> download from the file system I would think "filePath" would be it.  For
> database downloads, they might be "tableName", "tableField", "tableQuery",
> like my original Action had.  I think we'd need to debate what else should
> or should not be included in that list though.
> 
> In addition, for maximum flexibility, allowing these values to be
> overriden by corresponding values in the request should be allowed for.
> 
> In short, I believe that persuing this whole idea is a worth-wild exercise
> because downloading of BLOB-types is such a common activity I really do
> think it belongs in Struts.  I know there will be some debate about the
> best way to accomplish it, but as is the case with most things in Struts,
> there are numerous ways to accomplish any goal.  Providing developers with
> at least one solution built-in that might suffice for 90% of the cases
> seems like exactly the thought process that's been used all along
> developing the framework.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org