You won't need to make all the action mappings have to be the same type.
You can use the <action className=""> attribute to change the type of
one particular action mapping. (I think, haven't done it myself)
<action>
className The fully qualified Java class name of the ActionMapping
subclass to use for this action mapping object. Defaults
to
the type specified by the enclosing <action-mappings>
element or to "org.apache.struts.action.ActionMapping"
if
not specified.
["org.apache.struts.action.ActionMapping"]
-----Original Message-----
From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 3:40 PM
To: Struts Developers List
Subject: Re: On Martin Cooper's DownloadAction...
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" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]
> Sent: Tuesday, September 21, 2004 2:24 PM
> To: [EMAIL PROTECTED]
> 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: [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]
>
>
---------------------------------------------------------------------
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]
