You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Vic Cekvenich <ce...@basebeans.com> on 2003/12/05 00:20:26 UTC
Re: Advantages of Struts?
FAQ #2:
I would say this about Struts:
Sturts is like a kindergarden, we put our boots here, our books here;
thus they allow people to know where to find things on a project.
Presnetation here, Data Layer here;
And also people know generaly what they should be doing:
Once you have a form (html) mock up, you know what the formbean should
be (it mapps). Just get the form bean to CRUD via DAO.
Also a few consider dynambeans a bad practice.
http://sixlegs.com/blog/java/death-to-dynabeans.html
I consier them a not as good as form beans, they are harder to unit test
among other things.
.V
McClung, Brian wrote:
> Robert,
>
> I've gone to the opposite extreme as you. I don't want the action to be
> responsible for where it goes, only for telling users which forward states
> it supports. I've removed the forward from both the Action and the
> struts-config.xml file. The action still returns the forward, but the
> forward is dynamically created based on what the page has passed to the
> action. In my situation I resorted to this because I was using a single
> action to handle multiple applications on the same site. This meant that my
> path would not be the same between each application. Resorting to multiple
> mappings in the configuration file would rapidly get out of control for me
> as some of these applications can be created and removed rather quickly. I
> do have separate pages per application and this is why the page drives the
> actions result.
>
> I know this bends the MVC pattern, but it allows me to concentrate on
> developing actions, form beans, and all the back end business logic, while
> letting the Creative Designers develop pages and GUI workflow.
>
> Is anyone else doing something similar? I posted my DynaAction class that I
> use to do this with a couple of weeks ago. It really surprises me that
> there hasn't been a greater need for something like this in the community.
> I'd be curious to hear how others have solved this problem.
>
> Brian McClung
> Senior Programmer
> Belo Interactive
> 214-977-4083
>
>
> -----Original Message-----
> From: Vic Cekvenich [mailto:cekvenich_vic@basebeans.com]
> Sent: Thursday, December 04, 2003 2:18 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Disadvantages of Struts?
>
>
> I disagree with you as well Robert.
> Having a confgiration nudges you toward design and separation, and
> everyone on the team know where to find things.
>
> In fact, when not doing Web apps, I use HiveMind, just so that I can
> have the structure.
>
> Anyway, there a lot of MVC compeitoris.
>
>
> .V
>
> Robert H. Tran wrote:
>
>>My point was not against configuration altogether, but rather against the
>>current rigid and centralized configuration. There should be options. If
>>there is configurations in a component, it should be self-contained by the
>>component. It is no framework's business. If there is an api in Struts,
>
> this
>
>>can be done nice and easy, as I said with Eclipse.
>>
>>- Robert.
>>
>>----- Original Message -----
>>From: "Martin Cooper" <ma...@apache.org>
>>To: <st...@jakarta.apache.org>
>>Sent: Thursday, December 04, 2003 11:51 AM
>>Subject: Re: Disadvantages of Struts?
>>
>>
>>
>>
>>>"Robert H. Tran" <rh...@hotmail.com> wrote in message
>>>news:BAY8-DAV35wOxFmfnXA00002874@hotmail.com...
>>>
>>>
>>>>I think an action's mapping is a decision by the action itself. Like I
>>>
>>>said
>>>
>>>
>>>>earlier, when an application development finishes, that decision will
>>>
>>>become
>>>
>>>
>>>>static. At that point, when an Action's mapping changes, its code will
>>>
>>>have
>>>
>>>
>>>>to change too (unless the new mapping is kind of a synonym to the old
>>>>mapping, which doesn't bear any shift in the semantics). As such, there
>>
>>is
>>
>>
>>>>almost no point in keeping the decision and the code separate (i.e.
>>
>>making
>>
>>
>>>>the decision's configuration a loose end of the code). Or at least,
>>>>configuration shouldn't be the only way to add or modify an Action.
>>>
>>>I disagree with this almost completely. If actions are written properly,
>>
>>you
>>
>>
>>>should be able to reconfigure the application, to some extent at least, by
>>>changing the config alone and not touching the Java code. This is
>>
>>immensely
>>
>>
>>>useful when an app needs to be customised after the fact, and when the
>>>source code is not available (e.g. by a customer, in their own
>>
>>environment).
>>
>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>
>>>>Even though each Action's configuration may be small, the configurations
>>>
>>>for
>>>
>>>
>>>>all the Actions need to be kept track of and maintained (for integrity).
>>>>That may be a significant but unnecessary side work. To view the
>>
>>mappings,
>>
>>
>>>>there can be a tool to traverse the structure by api calls and display
>>
>>it.
>>
>>
>>>>That can be done after the fact and doesn't have to be before it. In
>>>>addition to that, when the decision (or configuration if any) goes where
>>>
>>>the
>>>
>>>
>>>>code lives, modularity increases.
>>>>
>>>>IMHO,
>>>>
>>>>- Robert.
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: <Jo...@shell.ca>
>>>>To: <st...@jakarta.apache.org>
>>>>Sent: Thursday, December 04, 2003 6:55 AM
>>>>Subject: RE: Disadvantages of Struts?
>>>>
>>>>
>>>>I have to disagree with you on the first point. I find that there is
>>>>just a small amount of necessary configuration required to build an
>>>>Action class (most of my Action configurations have about a half dozen
>>>>lines, even less if there is no associated ActionForm). I'm not really
>>>>sure what you mean by "paddle back and forth between the code and the
>>>>configuration", could you explain?
>>>>
>>>>Thanks.
>>>>
>>>>Robert H. Tran wrote:
>>>>
>>>>
>>>>>I am not sure that is true. Struts seems to lack of an API. IMO, there
>>>>
>>>>are
>>>>
>>>>
>>>>>more required configurations than necessary. Take Action for example,
>>>>
>>>>to
>>>>
>>>>
>>>>>write an Action, one has to paddle back and forth between the code and
>>>>
>>>>the
>>>>
>>>>
>>>>>configuration. It is like an executable having to configure each of
>>>>
>>>>its
>>>>
>>>>
>>>>>dlls. The visibility of the mappings is nice to have but the mappings
>>>>
>>>>can
>>>>
>>>>
>>>>>be generated after the fact as in a debugging view. When the
>>>>
>>>>application is
>>>>
>>>>
>>>>>finished, configurations become static. But since configurations are
>>>>>required, they will be like loose ends of the application. Another
>>>>
>>>>issue:
>>>>
>>>>
>>>>>how can one componentize his code and deploy it in a self-contained
>>>>
>>>>plug-in,
>>>>
>>>>
>>>>>as with Eclipse? Please forgive my novice.
>>>>>
>>>>>- Robert.
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Rick Hightower" <rh...@triveratech.com>
>>>>>To: "'Struts Developers List'" <st...@jakarta.apache.org>
>>>>>Sent: Wednesday, December 03, 2003 6:24 PM
>>>>>Subject: RE: Disadvantages of Struts?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Don't be silly. Struts is perfect.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert H. Tran [mailto:rhtran2000@hotmail.com]
>>>>>>Sent: Wednesday, December 03, 2003 2:10 PM
>>>>>>To: Struts Developers List
>>>>>>Subject: Disadvantages of Struts?
>>>>>>
>>>>>>I just wonder if Struts comes with any significant drawback. I mean
>>>>
>>>>not in
>>>>
>>>>
>>>>>>terms of when to use Struts and when not to use it necessarily, but
>>>>
>>>>more
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>the line of anyone's wishes that it had been better. Any advice is
>>>>
>>>>very
>>>>
>>>>
>>>>>>appreciated.
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--------------------------------------------------------------------------
>>>--
>>>
>>>
>>>>----
>>>>
>>>>
>>>>
>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Advantages of Struts?
Posted by Vic Cekvenich <ce...@basebeans.com>.
Maybe in old days of client server, people used to ship Oracle and MS
SQL drivers for ODBC. Boy, that was not fun, so people learned. Yeah,
OCI and ctlib, good ridance.
In J2EE, the container provides services. (As per any J2EE book).
JNDI, DataSourcePool, Security, etc. etc. So no need to have JDBC
related jars in war file.
Newbies don't use these services, but re-implement a home grown exiotic
and buggy versions. (Sometimes that is good, becuase I used to make
money by just fixing "connection" leaks)
A pro just uses the J2EE services.... that are debuged and working
allready.
They do this for exactly the same reason you said. In order to do less
configuration. If emplyees is removed, and security is LDAP or JDBC
realms or what ever, no impact on the war file.
If the DataSource needs to be changed to have a database fail over, no
need to change the war file, or bother the developers. The unix admin
just changes the xml file. Or deploy war file from stageing to
production, no changes.
You can even change containers from Tomcat to Resin... and not change
the WAR file. The is modular. Any scaling of data source pooling is a
container toonable.
This has nothing to do with Struts, this is J2EE container services. You
do not have to use them, you can write your own security (that tags do
not then see) or your own buggy connection pooling thing from JDBC 1.0.
Sturts is data layer agnostic, that's all. If you go out of the way to
lock it... you can, no sign will pop up, the code will compile.
But you are not on a main road, and not many people will help you
(unless you pay hourly)
If you remvoe a jar file, you need to regression test.
Are you suggesting that the Unix admin un-tars (nzips) the war file to
get to the jar files for some good reason?
Untill you leverage J2EE container services, you will have stability
issues, scalability issues, modular issues, etc. (maybe write your own
socket server? )
I know the fault. People have OLD jdbcs books, where the hello exaple is
how to write a connection pool. This was OK in '95 and '96 when we used
AWT. But things have advanced a bit since then.
Also, you will gain huge producitivity by using a DAO... which all realy
on container services.
But again... this is a J2EE discussion, not Struts. Like if you used
Spring, or WebWork, or Tapestry, or Sofia or ...
Same thing. Use a DAO! Use container services provided for you for free
and working.
If the conatiner does not give you good scallability or is to messed
up... you can pick another (again J2EE options)
.V
Robert H. Tran wrote:
> Point taken. But there is an option to modularize (and scale too), which is
> currently missing. It's like adding (or removing) an employee phone number
> at a firm usually doesn't mean having to update the listing at the phone
> company, especially not by the employee himself going to the phone company
> to do that. Yet the employee's phone can still be found and served up.
> That's the job of the firm. It should be self-contained under the firm's
> management to interface with the phone company through some protocols. Any
> one firm added or removed shouldn't incur changes to the phone company's
> configuration. A more practical example is: I want to remove this one jar
> file that contains one (possibly multiple) independent unit(s) of many
> actions and pages, what entries in Struts's configuration file do I need to
> remove? The other option allows me to just remove the jar file (or a
> corresponding directory) worry-free.
>
> - Robert.
>
> ----- Original Message -----
> From: "Vic Cekvenich" <ce...@basebeans.com>
> To: <st...@jakarta.apache.org>
> Sent: Thursday, December 04, 2003 3:20 PM
> Subject: Re: Advantages of Struts?
>
>
>
>>FAQ #2:
>>
>>I would say this about Struts:
>>
>>Sturts is like a kindergarden, we put our boots here, our books here;
>>thus they allow people to know where to find things on a project.
>>Presnetation here, Data Layer here;
>>And also people know generaly what they should be doing:
>>Once you have a form (html) mock up, you know what the formbean should
>>be (it mapps). Just get the form bean to CRUD via DAO.
>>
>>Also a few consider dynambeans a bad practice.
>>http://sixlegs.com/blog/java/death-to-dynabeans.html
>>I consier them a not as good as form beans, they are harder to unit test
>>among other things.
>>
>>
>>.V
>>
>>McClung, Brian wrote:
>>
>>>Robert,
>>>
>>>I've gone to the opposite extreme as you. I don't want the action to be
>>>responsible for where it goes, only for telling users which forward
>
> states
>
>>>it supports. I've removed the forward from both the Action and the
>>>struts-config.xml file. The action still returns the forward, but the
>>>forward is dynamically created based on what the page has passed to the
>>>action. In my situation I resorted to this because I was using a single
>>>action to handle multiple applications on the same site. This meant
>
> that my
>
>>>path would not be the same between each application. Resorting to
>
> multiple
>
>>>mappings in the configuration file would rapidly get out of control for
>
> me
>
>>>as some of these applications can be created and removed rather quickly.
>
> I
>
>>>do have separate pages per application and this is why the page drives
>
> the
>
>>>actions result.
>>>
>>>I know this bends the MVC pattern, but it allows me to concentrate on
>>>developing actions, form beans, and all the back end business logic,
>
> while
>
>>>letting the Creative Designers develop pages and GUI workflow.
>>>
>>>Is anyone else doing something similar? I posted my DynaAction class
>
> that I
>
>>>use to do this with a couple of weeks ago. It really surprises me that
>>>there hasn't been a greater need for something like this in the
>
> community.
>
>>>I'd be curious to hear how others have solved this problem.
>>>
>>>Brian McClung
>>>Senior Programmer
>>>Belo Interactive
>>>214-977-4083
>>>
>>>
>>>-----Original Message-----
>>>From: Vic Cekvenich [mailto:cekvenich_vic@basebeans.com]
>>>Sent: Thursday, December 04, 2003 2:18 PM
>>>To: struts-user@jakarta.apache.org
>>>Subject: Re: Disadvantages of Struts?
>>>
>>>
>>>I disagree with you as well Robert.
>>>Having a confgiration nudges you toward design and separation, and
>>>everyone on the team know where to find things.
>>>
>>>In fact, when not doing Web apps, I use HiveMind, just so that I can
>>>have the structure.
>>>
>>>Anyway, there a lot of MVC compeitoris.
>>>
>>>
>>>.V
>>>
>>>Robert H. Tran wrote:
>>>
>>>
>>>>My point was not against configuration altogether, but rather against
>
> the
>
>>>>current rigid and centralized configuration. There should be options. If
>>>>there is configurations in a component, it should be self-contained by
>
> the
>
>>>>component. It is no framework's business. If there is an api in Struts,
>>>
>>>this
>>>
>>>
>>>>can be done nice and easy, as I said with Eclipse.
>>>>
>>>>- Robert.
>>>>
>>>>----- Original Message -----
>>>>From: "Martin Cooper" <ma...@apache.org>
>>>>To: <st...@jakarta.apache.org>
>>>>Sent: Thursday, December 04, 2003 11:51 AM
>>>>Subject: Re: Disadvantages of Struts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>"Robert H. Tran" <rh...@hotmail.com> wrote in message
>>>>>news:BAY8-DAV35wOxFmfnXA00002874@hotmail.com...
>>>>>
>>>>>
>>>>>
>>>>>>I think an action's mapping is a decision by the action itself. Like I
>>>>>
>>>>>said
>>>>>
>>>>>
>>>>>
>>>>>>earlier, when an application development finishes, that decision will
>>>>>
>>>>>become
>>>>>
>>>>>
>>>>>
>>>>>>static. At that point, when an Action's mapping changes, its code will
>>>>>
>>>>>have
>>>>>
>>>>>
>>>>>
>>>>>>to change too (unless the new mapping is kind of a synonym to the old
>>>>>>mapping, which doesn't bear any shift in the semantics). As such,
>
> there
>
>>>>is
>>>>
>>>>
>>>>
>>>>>>almost no point in keeping the decision and the code separate (i.e.
>>>>
>>>>making
>>>>
>>>>
>>>>
>>>>>>the decision's configuration a loose end of the code). Or at least,
>>>>>>configuration shouldn't be the only way to add or modify an Action.
>>>>>
>>>>>I disagree with this almost completely. If actions are written
>
> properly,
>
>>>>you
>>>>
>>>>
>>>>
>>>>>should be able to reconfigure the application, to some extent at least,
>
> by
>
>>>>>changing the config alone and not touching the Java code. This is
>>>>
>>>>immensely
>>>>
>>>>
>>>>
>>>>>useful when an app needs to be customised after the fact, and when the
>>>>>source code is not available (e.g. by a customer, in their own
>>>>
>>>>environment).
>>>>
>>>>
>>>>
>>>>>--
>>>>>Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Even though each Action's configuration may be small, the
>
> configurations
>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>all the Actions need to be kept track of and maintained (for
>
> integrity).
>
>>>>>>That may be a significant but unnecessary side work. To view the
>>>>
>>>>mappings,
>>>>
>>>>
>>>>
>>>>>>there can be a tool to traverse the structure by api calls and display
>>>>
>>>>it.
>>>>
>>>>
>>>>
>>>>>>That can be done after the fact and doesn't have to be before it. In
>>>>>>addition to that, when the decision (or configuration if any) goes
>
> where
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>code lives, modularity increases.
>>>>>>
>>>>>>IMHO,
>>>>>>
>>>>>>- Robert.
>>>>>>
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: <Jo...@shell.ca>
>>>>>>To: <st...@jakarta.apache.org>
>>>>>>Sent: Thursday, December 04, 2003 6:55 AM
>>>>>>Subject: RE: Disadvantages of Struts?
>>>>>>
>>>>>>
>>>>>>I have to disagree with you on the first point. I find that there is
>>>>>>just a small amount of necessary configuration required to build an
>>>>>>Action class (most of my Action configurations have about a half dozen
>>>>>>lines, even less if there is no associated ActionForm). I'm not really
>>>>>>sure what you mean by "paddle back and forth between the code and the
>>>>>>configuration", could you explain?
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>Robert H. Tran wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I am not sure that is true. Struts seems to lack of an API. IMO,
>
> there
>
>>>>>>are
>>>>>>
>>>>>>
>>>>>>
>>>>>>>more required configurations than necessary. Take Action for example,
>>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>>write an Action, one has to paddle back and forth between the code
>
> and
>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>configuration. It is like an executable having to configure each of
>>>>>>
>>>>>>its
>>>>>>
>>>>>>
>>>>>>
>>>>>>>dlls. The visibility of the mappings is nice to have but the mappings
>>>>>>
>>>>>>can
>>>>>>
>>>>>>
>>>>>>
>>>>>>>be generated after the fact as in a debugging view. When the
>>>>>>
>>>>>>application is
>>>>>>
>>>>>>
>>>>>>
>>>>>>>finished, configurations become static. But since configurations are
>>>>>>>required, they will be like loose ends of the application. Another
>>>>>>
>>>>>>issue:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>how can one componentize his code and deploy it in a self-contained
>>>>>>
>>>>>>plug-in,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>as with Eclipse? Please forgive my novice.
>>>>>>>
>>>>>>>- Robert.
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "Rick Hightower" <rh...@triveratech.com>
>>>>>>>To: "'Struts Developers List'" <st...@jakarta.apache.org>
>>>>>>>Sent: Wednesday, December 03, 2003 6:24 PM
>>>>>>>Subject: RE: Disadvantages of Struts?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Don't be silly. Struts is perfect.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Robert H. Tran [mailto:rhtran2000@hotmail.com]
>>>>>>>>Sent: Wednesday, December 03, 2003 2:10 PM
>>>>>>>>To: Struts Developers List
>>>>>>>>Subject: Disadvantages of Struts?
>>>>>>>>
>>>>>>>>I just wonder if Struts comes with any significant drawback. I mean
>>>>>>
>>>>>>not in
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>terms of when to use Struts and when not to use it necessarily, but
>>>>>>
>>>>>>more
>>>>>>
>>>>>>
>>>>>>
>>>>>>>in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the line of anyone's wishes that it had been better. Any advice is
>>>>>>
>>>>>>very
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>appreciated.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>-------------------------------------------------------------------------
>
> -
>
>>>>>--
>>>>>
>>>>>
>>>>>
>>>>>>----
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Advantages of Struts?
Posted by "Robert H. Tran" <rh...@hotmail.com>.
Point taken. But there is an option to modularize (and scale too), which is
currently missing. It's like adding (or removing) an employee phone number
at a firm usually doesn't mean having to update the listing at the phone
company, especially not by the employee himself going to the phone company
to do that. Yet the employee's phone can still be found and served up.
That's the job of the firm. It should be self-contained under the firm's
management to interface with the phone company through some protocols. Any
one firm added or removed shouldn't incur changes to the phone company's
configuration. A more practical example is: I want to remove this one jar
file that contains one (possibly multiple) independent unit(s) of many
actions and pages, what entries in Struts's configuration file do I need to
remove? The other option allows me to just remove the jar file (or a
corresponding directory) worry-free.
- Robert.
----- Original Message -----
From: "Vic Cekvenich" <ce...@basebeans.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, December 04, 2003 3:20 PM
Subject: Re: Advantages of Struts?
> FAQ #2:
>
> I would say this about Struts:
>
> Sturts is like a kindergarden, we put our boots here, our books here;
> thus they allow people to know where to find things on a project.
> Presnetation here, Data Layer here;
> And also people know generaly what they should be doing:
> Once you have a form (html) mock up, you know what the formbean should
> be (it mapps). Just get the form bean to CRUD via DAO.
>
> Also a few consider dynambeans a bad practice.
> http://sixlegs.com/blog/java/death-to-dynabeans.html
> I consier them a not as good as form beans, they are harder to unit test
> among other things.
>
>
> .V
>
> McClung, Brian wrote:
> > Robert,
> >
> > I've gone to the opposite extreme as you. I don't want the action to be
> > responsible for where it goes, only for telling users which forward
states
> > it supports. I've removed the forward from both the Action and the
> > struts-config.xml file. The action still returns the forward, but the
> > forward is dynamically created based on what the page has passed to the
> > action. In my situation I resorted to this because I was using a single
> > action to handle multiple applications on the same site. This meant
that my
> > path would not be the same between each application. Resorting to
multiple
> > mappings in the configuration file would rapidly get out of control for
me
> > as some of these applications can be created and removed rather quickly.
I
> > do have separate pages per application and this is why the page drives
the
> > actions result.
> >
> > I know this bends the MVC pattern, but it allows me to concentrate on
> > developing actions, form beans, and all the back end business logic,
while
> > letting the Creative Designers develop pages and GUI workflow.
> >
> > Is anyone else doing something similar? I posted my DynaAction class
that I
> > use to do this with a couple of weeks ago. It really surprises me that
> > there hasn't been a greater need for something like this in the
community.
> > I'd be curious to hear how others have solved this problem.
> >
> > Brian McClung
> > Senior Programmer
> > Belo Interactive
> > 214-977-4083
> >
> >
> > -----Original Message-----
> > From: Vic Cekvenich [mailto:cekvenich_vic@basebeans.com]
> > Sent: Thursday, December 04, 2003 2:18 PM
> > To: struts-user@jakarta.apache.org
> > Subject: Re: Disadvantages of Struts?
> >
> >
> > I disagree with you as well Robert.
> > Having a confgiration nudges you toward design and separation, and
> > everyone on the team know where to find things.
> >
> > In fact, when not doing Web apps, I use HiveMind, just so that I can
> > have the structure.
> >
> > Anyway, there a lot of MVC compeitoris.
> >
> >
> > .V
> >
> > Robert H. Tran wrote:
> >
> >>My point was not against configuration altogether, but rather against
the
> >>current rigid and centralized configuration. There should be options. If
> >>there is configurations in a component, it should be self-contained by
the
> >>component. It is no framework's business. If there is an api in Struts,
> >
> > this
> >
> >>can be done nice and easy, as I said with Eclipse.
> >>
> >>- Robert.
> >>
> >>----- Original Message -----
> >>From: "Martin Cooper" <ma...@apache.org>
> >>To: <st...@jakarta.apache.org>
> >>Sent: Thursday, December 04, 2003 11:51 AM
> >>Subject: Re: Disadvantages of Struts?
> >>
> >>
> >>
> >>
> >>>"Robert H. Tran" <rh...@hotmail.com> wrote in message
> >>>news:BAY8-DAV35wOxFmfnXA00002874@hotmail.com...
> >>>
> >>>
> >>>>I think an action's mapping is a decision by the action itself. Like I
> >>>
> >>>said
> >>>
> >>>
> >>>>earlier, when an application development finishes, that decision will
> >>>
> >>>become
> >>>
> >>>
> >>>>static. At that point, when an Action's mapping changes, its code will
> >>>
> >>>have
> >>>
> >>>
> >>>>to change too (unless the new mapping is kind of a synonym to the old
> >>>>mapping, which doesn't bear any shift in the semantics). As such,
there
> >>
> >>is
> >>
> >>
> >>>>almost no point in keeping the decision and the code separate (i.e.
> >>
> >>making
> >>
> >>
> >>>>the decision's configuration a loose end of the code). Or at least,
> >>>>configuration shouldn't be the only way to add or modify an Action.
> >>>
> >>>I disagree with this almost completely. If actions are written
properly,
> >>
> >>you
> >>
> >>
> >>>should be able to reconfigure the application, to some extent at least,
by
> >>>changing the config alone and not touching the Java code. This is
> >>
> >>immensely
> >>
> >>
> >>>useful when an app needs to be customised after the fact, and when the
> >>>source code is not available (e.g. by a customer, in their own
> >>
> >>environment).
> >>
> >>
> >>>--
> >>>Martin Cooper
> >>>
> >>>
> >>>
> >>>
> >>>>Even though each Action's configuration may be small, the
configurations
> >>>
> >>>for
> >>>
> >>>
> >>>>all the Actions need to be kept track of and maintained (for
integrity).
> >>>>That may be a significant but unnecessary side work. To view the
> >>
> >>mappings,
> >>
> >>
> >>>>there can be a tool to traverse the structure by api calls and display
> >>
> >>it.
> >>
> >>
> >>>>That can be done after the fact and doesn't have to be before it. In
> >>>>addition to that, when the decision (or configuration if any) goes
where
> >>>
> >>>the
> >>>
> >>>
> >>>>code lives, modularity increases.
> >>>>
> >>>>IMHO,
> >>>>
> >>>>- Robert.
> >>>>
> >>>>
> >>>>----- Original Message -----
> >>>>From: <Jo...@shell.ca>
> >>>>To: <st...@jakarta.apache.org>
> >>>>Sent: Thursday, December 04, 2003 6:55 AM
> >>>>Subject: RE: Disadvantages of Struts?
> >>>>
> >>>>
> >>>>I have to disagree with you on the first point. I find that there is
> >>>>just a small amount of necessary configuration required to build an
> >>>>Action class (most of my Action configurations have about a half dozen
> >>>>lines, even less if there is no associated ActionForm). I'm not really
> >>>>sure what you mean by "paddle back and forth between the code and the
> >>>>configuration", could you explain?
> >>>>
> >>>>Thanks.
> >>>>
> >>>>Robert H. Tran wrote:
> >>>>
> >>>>
> >>>>>I am not sure that is true. Struts seems to lack of an API. IMO,
there
> >>>>
> >>>>are
> >>>>
> >>>>
> >>>>>more required configurations than necessary. Take Action for example,
> >>>>
> >>>>to
> >>>>
> >>>>
> >>>>>write an Action, one has to paddle back and forth between the code
and
> >>>>
> >>>>the
> >>>>
> >>>>
> >>>>>configuration. It is like an executable having to configure each of
> >>>>
> >>>>its
> >>>>
> >>>>
> >>>>>dlls. The visibility of the mappings is nice to have but the mappings
> >>>>
> >>>>can
> >>>>
> >>>>
> >>>>>be generated after the fact as in a debugging view. When the
> >>>>
> >>>>application is
> >>>>
> >>>>
> >>>>>finished, configurations become static. But since configurations are
> >>>>>required, they will be like loose ends of the application. Another
> >>>>
> >>>>issue:
> >>>>
> >>>>
> >>>>>how can one componentize his code and deploy it in a self-contained
> >>>>
> >>>>plug-in,
> >>>>
> >>>>
> >>>>>as with Eclipse? Please forgive my novice.
> >>>>>
> >>>>>- Robert.
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Rick Hightower" <rh...@triveratech.com>
> >>>>>To: "'Struts Developers List'" <st...@jakarta.apache.org>
> >>>>>Sent: Wednesday, December 03, 2003 6:24 PM
> >>>>>Subject: RE: Disadvantages of Struts?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Don't be silly. Struts is perfect.
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Robert H. Tran [mailto:rhtran2000@hotmail.com]
> >>>>>>Sent: Wednesday, December 03, 2003 2:10 PM
> >>>>>>To: Struts Developers List
> >>>>>>Subject: Disadvantages of Struts?
> >>>>>>
> >>>>>>I just wonder if Struts comes with any significant drawback. I mean
> >>>>
> >>>>not in
> >>>>
> >>>>
> >>>>>>terms of when to use Struts and when not to use it necessarily, but
> >>>>
> >>>>more
> >>>>
> >>>>
> >>>>>in
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the line of anyone's wishes that it had been better. Any advice is
> >>>>
> >>>>very
> >>>>
> >>>>
> >>>>>>appreciated.
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
>
>>>-------------------------------------------------------------------------
-
> >>>--
> >>>
> >>>
> >>>>----
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>
> >>>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org