Re: RFC: BLOBAction and Struts Bloat

2004-09-21 Thread Vic
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)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: RFC: BLOBAction and Struts Bloat

2004-09-21 Thread Matthias Wessendorf
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

2004-09-21 Thread Michael McGrady
I will be interested to read your thoughts, Craig.  I am more than 
elated to see that you are going to be actively involved with the 
discussions on the 2.0 architecture.  Part of my concern has been the 
seeming absence of a visionary and thoughtful voice in this process.  
With Ted's departure and the worry about your being spread too thin, I 
thought we might have to rely on Vic's steadying influence or just to 
poke fun at the present "management" until they got serious.  ;-)

Michael McGrady
Craig McClanahan wrote:
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]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: RFC: BLOBAction and Struts Bloat

2004-09-21 Thread Craig McClanahan
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

2004-09-21 Thread Frank W. Zammetti (MLists)
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  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  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

2004-09-20 Thread Martin Cooper
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 and Struts Bloat

2004-09-20 Thread bryan
I've got a good example, check out springworkflow ( sourceforge )
and it's chaining system.

http://www.competities.com/springworkflow/chaining.html

Chaining is quite frankly a pain with the existing model.

The (struts) design needs to be parred down in order to support 
development according to more complex business requirement models.

--b






On Mon, 20 Sep 2004 16:37:07 +0200, bryan <[EMAIL PROTECTED]> wrote:
> 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 somethi

Re: RFC: BLOBAction and Struts Bloat

2004-09-20 Thread bryan
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 and Struts Bloat

2004-09-20 Thread Frank W. Zammetti (MLists)
Geez, leave it to me to instigate a major overhaul in the structure of a
well-known project by making an innocent offering :)

(I always was a trouble-maker)

Not that I actually have a say or anything, but I think there is a lot of
logic in what Michael says.  The obvious (to me anyway) difficulty is in
determing where the separation really should take place.  The
DispatchAction example, in my eyes, is pretty clear-cut and I agree with
Michael.  But will it always be that easy to decide?  I would suspect not.

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

On Mon, September 20, 2004 9:31 am, Michael McGrady said:
> 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 and Struts Bloat

2004-09-20 Thread Michael McGrady
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]


[Fwd: Re: RFC: BLOBAction]

2004-09-20 Thread Frank W. Zammetti (MLists)
> 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

2004-09-20 Thread Frank W. Zammetti (MLists)

-- 
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  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:



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]



Re: RFC: BLOBAction

2004-09-20 Thread Craig McClanahan
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]



Re: RFC: BLOBAction

2004-09-20 Thread Reinhard Nägele
Frank,
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:

   * Struts is database-independent. People don't necessarily use plain
 JDBC.
   * 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...
   * I don't like JDBC in Actions. What about separating controller
 from business logic and database access?
   * Your approach is not very flexible. You may not always want to
 read the data completely into memory before writing it to the
 response.
   * BTW, it's a good idea to call response.reset() and, if possible,
 to set the content length before writing to the OutputStream.
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.

Reinhard
Frank W. Zammetti (MLists) 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
submit to you all for comments and, perhaps eventually, inclusion in
Struts as a built-in Action like ForwardAction and the like.
Consider this proof-of-concept code, quality-wise... You can read my
rather verbose comments on this, but in short... Right now it works by
accepting a bunch of parameters submitted with the request.  This I feel
is NOT the right approach.  I was hoping that Struts would read in unknown
attributes for  mappings from struts-config.xml, but that does not
seem to be the case.  I believe most, if not all, of these parameters
should become attributes of the action mappings themselves, but this is
one of the things I'm looking for feedback on.
I am using this code (essentially this code... this is more generic
though) in a production app here at work, so I know it works (aside from
my tests here on this particular code which of course work).  I'm sure
it's not ready as-is, but I don't think it's too bad either.
I look forward to any comments you may have (first and foremost: is this
even worth it?  I think it is, but I may be wrong on even that basic
point!)
 


/*
* 
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
*   "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Struts", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* 
*
* This software consists of voluntary contributions made by many
* individuals on

Re: RFC: BLOBAction

2004-09-17 Thread bryan
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]