struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti (MLists)" <fzli...@omnytex.com>
Subject Re: On Martin Cooper's DownloadAction...
Date Tue, 21 Sep 2004 19:40:16 GMT
You guys are frankly delving into some things I haven't been exposed to
before... I'm doing some reading right now and I THINK I get what your
saying...

(1) Extend ActionMapping and have accessors and mutators for all the
"extra" attributes needed (whatever they may actually be, still open for
debate)

(2) In Struts-config, I would have someting like this:

<action-mappings
type="org.apache.struts.action.StandardStreamDownloadMapping">
 <action path="/test"
type="org.apache.struts.action.StandardSreamDownloaderAction">
  <set-property property="streamInfoType"
value="org.apcahe.struts.DatabaseStreamInfo">
  <set-property property="dbTable" value="whatever1" />
  <set-property property="dbField" value="whatever1" />
  <set-property property="dbQuery" value="whatever1" />
 </action>
</acton-mappings>

(Any other Actions aside from the download types should still work, but it
would be nice if you could define some Actions as using this Mapping and
others using the usual Mapping... <action-mappings> is a single element
max. though, right?  I suppose I could just go look at the DTD... I'm so
lazy :) )

(3) Implement Martin's class such that it instantiates the StreamInfo
named in the mapping, nothing needs to actually change in his code then,
just need to implement the getStreamInfo() method as his comments
indicate.

Did I get that right?  As I said, there's a couple of new concepts in here
for me (like I didn't know you could specify a different Mapping class,
and I don't think I knew about the <set-property> elements either), so did
I get close?  Assuming so, this makes sense to me, and I'd be happy to go
off and write the implementations if everyone agrees it's the right
approach.

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

On Tue, September 21, 2004 3:19 pm, Niall Pemberton said:
> +1
>
> We have have graph generating actions using JFreeChart and pdf generating
> actions using iText  and none of them use any of the attributes that your
> blob action has - so leaving that abstract is a good idea IMO.
>
> Niall
>
> ----- Original Message -----
> From: "Deadman, Hal" <Hal.Deadman@Tallan.com>
> To: "Struts Developers List" <dev@struts.apache.org>
> Sent: Tuesday, September 21, 2004 8:05 PM
> Subject: RE: On Martin Cooper's DownloadAction...
>
>
> Rather than adding lots of new attributes to the existing action mapping
> element, maybe you should add your properties to an ActionConfig
> sub-class and use nested set-property elements to configure your
> download action mapping. Then your download action implementation could
> be used with older versions of struts.
>
> I haven't played with with set-property but I think you would reference
> your new ActionConfig or ActionMapping sub-class with the <action
> className=""> attribute and then use nested <set-property property=""
> value=""/> elements for each property that needs to be set for a
> particular impl.
>
> <!ELEMENT action (icon?, display-name?, description?, set-property*,
> exception*, forward*)>
>
> You should probably leave Martin's class as is and add your new impl
> along with a new config class that has all the attributes your action
> impl needs. That would leave Martin's class available for use by people
> that have some other means of getting the stream.
>
> -----Original Message-----
> From: Frank W. Zammetti (MLists) [mailto:fzlists@omnytex.com]
> Sent: Tuesday, September 21, 2004 2:24 PM
> To: dev@struts.apache.org
> Subject: On Martin Cooper's DownloadAction...
>
> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message