You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kent Boogaart <ke...@internode.on.net> on 2005/08/03 03:33:27 UTC
MVC Question
Hi,
I've just read this
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns
/html/DesPageController.asp) MVC overview. They describe the view as
obtaining its data directly from the model. I was under the impression that
the view should obtain / update data only through the controller and should
never directly access the model.
Unless I'm mistaken, this is how struts works. The controller (action)
retrieves data from the model (eg. EJBs) and populates the action form. The
view then just obtains data from the action form.
I guess my question is: is the action form considered part of the model? If
not, what?
Thanks,
Kent
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: MVC Question
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I've been in a position to train people in MVC before, and Struts in
particular, and I've used diagrams to do this... one of the things I've
always done in those diagrams is shown ActionForms straddling the space
between V and C, and DTOs straddling the line between C and M.
I think conceptually, and keeping in mind just the original intent of it,
that that is how is should be viewed... think of ActionForms as the
communications conduit between V and C, and DTOs as the conduit between C
and M. They don't truly belong to any one tier.
Of course, there are other usage patterns for ActionForms, and people
don't always use DTOs at all (I personally have tended to pass generic
Collections between C and M, although I've been moving away from that
thinking gradually). So, as Michael said, this is more an academic point
really... you conceivably could use ActionForms in such a way that they
are pretty obviously part of one tier or another, the flexibility is yours
to use and abuse :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, August 3, 2005 1:00 pm, Michael Jouravlev said:
> On 8/2/05, Kent Boogaart <ke...@internode.on.net> wrote:
>> I guess my question is: is the action form considered part of the model?
>> If
>> not, what?
>
> Does it really matter, what you call it?
>
> Officially action form is not part of the Model. Model is supposed to
> reside in your own code, which you call from form/action/whatever.
>
> On the other hand, some developers aggregate DTOs or even real BOs
> into action form. Does this make action form a part of Model? Don't
> think so, it is just a container at best.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: MVC Question
Posted by Yan Hu <ya...@yahoo.com>.
--- Michael Jouravlev <jm...@gmail.com> wrote:
> On 8/2/05, Kent Boogaart <ke...@internode.on.net> wrote:
> > I guess my question is: is the action form considered part of the model? If
> > not, what?
Struts does not provide anything for the model.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: MVC Question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/2/05, Kent Boogaart <ke...@internode.on.net> wrote:
> I guess my question is: is the action form considered part of the model? If
> not, what?
Does it really matter, what you call it?
Officially action form is not part of the Model. Model is supposed to
reside in your own code, which you call from form/action/whatever.
On the other hand, some developers aggregate DTOs or even real BOs
into action form. Does this make action form a part of Model? Don't
think so, it is just a container at best.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: MVC Question
Posted by Ted Husted <te...@gmail.com>.
In the original SmallTalk MVC, the View does indeed update itself from
the Model, via the Observer pattern. The original MVC pattern is like
a loop.
But, a direct link between the Model and the View is not practical for
web applications, so we've modified MVC so that is more like a
horseshoe, with the controller in the middle.
Some web applications frameworks would call a gizmo like the
ActionForm the model, since from the page's perspective, the
ActionForm, and other servlet attributes, are all it knows about the
model. But, the ActionForm and other servlet attributes are more like
a model facade.
In Struts, we have a longstanding problem where people represent their
true Model in JavaBeans or EJBs, and then want to repurpose these
objects as ActionForms. Most of us feel that's a bad idea for *so*
many reasons, so we are careful to say that the ActionForm is *not*
the Model.
Architecturally, the ActionForm is an input/output buffer for the
controls on a server page. Component-based frameworks, like JSF and
ASP.NET, build the string buffers into the control objects, and so
they don't need an ActionForm member..
HTH, Ted.
On 8/2/05, Kent Boogaart <ke...@internode.on.net> wrote:
> Hi,
>
> I've just read this
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns
> /html/DesPageController.asp) MVC overview. They describe the view as
> obtaining its data directly from the model. I was under the impression that
> the view should obtain / update data only through the controller and should
> never directly access the model.
>
> Unless I'm mistaken, this is how struts works. The controller (action)
> retrieves data from the model (eg. EJBs) and populates the action form. The
> view then just obtains data from the action form.
>
> I guess my question is: is the action form considered part of the model? If
> not, what?
>
> Thanks,
> Kent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Dakota Jack <da...@gmail.com>.
You missed the point, Adam. No one is so daft as to be saying that
having an interface makes the implementations of that interface less
than specific implementations. The point is that you can switch them
out.
On 8/11/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Dave Newton on 10/08/05 16:25, wrote:
> >
> > (4) Dependency Injection/Configurability.
> >
> > Classes that implement interfaces can be instantiated at runtime
> > allowing for config-file-level application modification. This can
> > translate into HUGE wins over the life of an application.
> >
> > As a recent thread on DTOs pointed out having multiple implementations
> > of CRUD actions can be REALLY handy: I have an existing application that
> > uses Torque for persistence. I refactored out a lot of the typical CRUD
> > stuff into an interface, implemented a default Torque CRUD base class,
> > whung up a configuration file, and can now perform the most general CRUD
> > actions on my DB by giving a tablename String.
> >
> > When I migrate this to Hibernate "all" I'll need to do is implement a
> > generic Hibernate CRUD base class (and perhaps some specializers for
> > particular tables/OMs), change the class names in my config file, and my
> > application will work as before without having to change any of my Actions.
>
> Hold on a mo', you've lost me there. Haven't had my coffee yet -
>
> if you have a whole package of DAOs (doing the CRUD stuff), all
> inheriting the Torque base class which implements your DAO interface,
> and you change over to Hibernate, then surely you must write a whole new
> package of DAOs for Hibernate, not just the base class?
>
> Obviously though the business tier is coded to the interface so is
> unaffected.
>
> Correct me if I'm wrong,
>
> Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Dave Newton <ne...@pingsite.com>.
This got long-ish as I'm partially thinking out loud about this
work-in-progress. Sorry. The whole thing got blown out of proportion
late last week and I shouldn't be doing this with Struts at all, I
think. More of a Dave's Java Playground project, this.
Adam Hardy wrote:
> if you have a whole package of DAOs (doing the CRUD stuff), all
> inheriting the Torque base class which implements your DAO interface,
> and you change over to Hibernate, then surely you must write a whole
> new package of DAOs for Hibernate, not just the base class?
The DAO stuff is written by Hibernate (I might not be using the right
acronym, I suppose), and I haven't fully refactored my classes yet, but
in a nutshell:
public interface ICrudDelegate {
// CRUD operations
public Object getById(final String omClass_, final String id_);
public void deleteById(final String omClass_, final String id_);
public List getList(final String omClass_);
public void saveOm(final Object om_);
public void updateOm(final Object om_);
// CRUD method retrievers
public Method getUpdateMethod(final String omClass_);
// [... plus others like that ...]
}
So I have a DefaultTorqueCrudDelegateImpl class that does all the Right
Things for Torque. I also have a DefaultHibernateCrudDelegateImpl class
that does all the Right Things for Hibernate (although I suspect I have
a fair chunk of refactoring yet to do).
Actual it's more complicated than this, as I have a single Action that
does all the CRUD based on Ruby on Rails-style URLs :
/${prefix}/${table_name}/${command}[/${id}] and have a IHandleCommands
interface:
public interface IHandleCommands {
public boolean isCommandHandled(final String cmd_);
public Object handleCommand(final String cmd_, final Map cmdParams_)
throws UnsupportedOperationException,
CommandHandlerException;
public Class[] getHandlerSignature();
public Object[] getHandlerParams(final Map cmdParams_);
}
and currently a single implementation, StrutsCommandHandler. My single
CRUD action packages up relevant arguments (mapping, form, request,
response, my crud config (see below), etc) into the Map and hands it off
to the StrutsCommandHandler, which instantiates and uses the delegates
as described above.
So a chunk of my config file might look like this:
<crud-mappings>
<crud prefix="Admin">
<form tableName="Event"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
omClass="com.pingsite.om.Event"
/>
<form tableName="AnnouncementType"
crudHandler="com.pingsite.crud.handlers.AnnouncementTypeCrudHandler"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
formClass="com.pingsite.struts.forms.AnnouncementTypeForm"
omClass="com.pingsite.om.AnnouncementType"
/>
<form tableName="ProductCategory"
crudHandler="com.pingsite.crud.handlers.StrutsCommandHandler"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
formClass="com.pingsite.struts.forms.ProductCategoryForm"
omClass="com.pingsite.om.ProductCategory"
</crud>
<crud prefix="User">
<form tableName="AnnouncementType"
formClass="com.pingsite.struts.forms.UserAnnouncementTypeForm"
omClass="com.pingsite.om.UserAnnouncementType"/>
</crud>
</crud-mappings>
There are also the typical hooks you'd expect; things before the form is
displayed (so I can pre-populate dropdowns, etc.), things after the form
is submitted (like tweaking my form's checkboxes into integers for my
MySQL Torque stuff), blah blah blah. Except for the generation of JSP
chunks (currently barely handled by a Ruby script) it's a configuration
file change to add a table into the CRUD processing system, which is neat.
Totally out of control, though, and I'm not entirely sure I've really
accomplished anything except get better at design and reflection. It's
been a VERY interesting exercise, though!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Dave Newton on 10/08/05 16:25, wrote:
>
> (4) Dependency Injection/Configurability.
>
> Classes that implement interfaces can be instantiated at runtime
> allowing for config-file-level application modification. This can
> translate into HUGE wins over the life of an application.
>
> As a recent thread on DTOs pointed out having multiple implementations
> of CRUD actions can be REALLY handy: I have an existing application that
> uses Torque for persistence. I refactored out a lot of the typical CRUD
> stuff into an interface, implemented a default Torque CRUD base class,
> whung up a configuration file, and can now perform the most general CRUD
> actions on my DB by giving a tablename String.
>
> When I migrate this to Hibernate "all" I'll need to do is implement a
> generic Hibernate CRUD base class (and perhaps some specializers for
> particular tables/OMs), change the class names in my config file, and my
> application will work as before without having to change any of my Actions.
Hold on a mo', you've lost me there. Haven't had my coffee yet -
if you have a whole package of DAOs (doing the CRUD stuff), all
inheriting the Torque base class which implements your DAO interface,
and you change over to Hibernate, then surely you must write a whole new
package of DAOs for Hibernate, not just the base class?
Obviously though the business tier is coded to the interface so is
unaffected.
Correct me if I'm wrong,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
>I think it usually comes down to three reasons...
>
>
I'd add a fourth, although really it's just a result of the reasons you
mention. But I think it's important enough to warrant attention :)
(4) Dependency Injection/Configurability.
Classes that implement interfaces can be instantiated at runtime
allowing for config-file-level application modification. This can
translate into HUGE wins over the life of an application.
As a recent thread on DTOs pointed out having multiple implementations
of CRUD actions can be REALLY handy: I have an existing application that
uses Torque for persistence. I refactored out a lot of the typical CRUD
stuff into an interface, implemented a default Torque CRUD base class,
whung up a configuration file, and can now perform the most general CRUD
actions on my DB by giving a tablename String.
When I migrate this to Hibernate "all" I'll need to do is implement a
generic Hibernate CRUD base class (and perhaps some specializers for
particular tables/OMs), change the class names in my config file, and my
application will work as before without having to change any of my Actions.
Business logic will also be unaffected by the persistence mechanism change.
Jython utilities and GUI apps will also run unmodified: I use the new
Hibernate implementation, use the same config file, and everything is ducky.
I get giddy just thinking about it.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I think it usually comes down to three reasons...
(1) A class can only extend a single class, whereas it can implement
multiple interfaces (Interfaces are Java's version of multiple inheritance
in C). So, as soon as you get to the point where extending a single class
just isn't sufficient, it's no longer really a choice... well, I suppose
you could push all the functionality up the inheritance tree, but that
gets ugly in a hurry.
Since you can only extend a single class, you want to do so carefully,
kind of like if your in a desert, you don't want to drink your last glass
of water lightly :) So, if you keep implementing interfaces instead, you
keep that one inheritance path open to you.
It's really *not* the same as multiple inheritance because you aren't
inheriting functionality, but it in a sense leads to the same thing
because you of course have to implement all the methods of the interface,
and presumably you do so in a meaningful way, so in the end you get the
same basic effect.
(2) It allows for polymorphism. If a given class implements a given
interface, you can treat the class as an instance of the interface. So,
if you have a Dog class and a Dolphin class and a Lizard class and they
all implement the IHasBabies interface which has a single giveBirth()
method, obviously the method by which each of the classes "gives birth" is
quite different, but all you need to do in your code is:
((IHasBabies)animal).giveBirth();
...and animal can then be an instance of a Dog, Dolphin or Lizard and the
above code doesn't have to change at all. Note that if there was true
multiple inheritance you'd be able to do the same thing.
You may be asking "well, why not just have Dog, Dolphin and Lizard extent
a HasBabies class"? Again, it comes back to the multiple inheritance
problem... what if you want to have a class Eats and a class Sleeps and a
class Runs, etc., to encapsulate the common functionality? You either
have to put all that stuff into the one class that Dog, Dolphin and Lizard
extends, which is ugly, or you get into a situation where there is no
guarantee about the interface each class has... maybe Dog has sleepLong()
and Lizard has sleepShort(). Implementing an interface that describes
sleeping, then one that describes eating, etc., guarantees that each of
the implementing classes exposes the same generic functionality, even if
the specific details are different for each.
(3) Following on the heels of the last paragraph, implementing an
interface is a clean way of saying "ok, this class is guaranteed to have
the following members". It's a matter of extensibility... imagine when
you have to add another type of animal to the above example... maybe you
want to add an AlienFaceHugger class, which has yet another method of
giving birth (eeewwww!)... if it implements that IHasBabies interface,
then you know it is guaranteed to have that giveBirth() method, even if
you don't know what goes on inside it, and most importantly, this will be
enforced at compile-time.
So, it isn't so much a choice to use interfaces vs. not using them...
there are certain things that you won't be able to do without them in
Java. Or, at least there are things that you won't be able to do WELL in
Java.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, August 10, 2005 10:47 am, Carl Smith said:
>
> In Java/J2EE community, it seems that a lot of experienced developers tend
> to use a lot of interfaces, however, a lot of junior developers ignore
> using interface. I am not sure why interfaces seem to be favorite to some
> experienced developers. Can some one explain this?Can you give examples
> where an interface is preferred?
>
> Thanks.
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: SwitchAction.java in struts
Posted by Laurie Harper <la...@holoweb.net>.
Carl Smith wrote:
> Can you describe in which case we should be using SwitchAction.java in struts? Can you offer some sample code? Is this used for multiple submit buttons (save, delete, update, cancle buttons for example) on one jsp page? Thanks.
I'm not sure what this has to do with CactusStrutsTestCase, but the
answer is that SwitchAction is used for switching between modules --
specifically, for creating a link to a page in different module to the
one containing the page the link appears on.
http://svn.apache.org/builds/struts/maven/trunk/site-test/struts-core/apidocs/org/apache/struts/actions/SwitchAction.html
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
SwitchAction.java in struts
Posted by Carl Smith <cc...@yahoo.com>.
Can you describe in which case we should be using SwitchAction.java in struts? Can you offer some sample code? Is this used for multiple submit buttons (save, delete, update, cancle buttons for example) on one jsp page? Thanks.
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Re: CactusStrutsTestCase working problem with tiles extension
Posted by Laurie Harper <la...@holoweb.net>.
Firstly, when starting a new topic it's a better idea to post a new
message rather than replying to an existing one. Anyone not following
the thread you reply on wont see you message if you do that.
As far as your problem goes, it's not clear what the problem is because
it doesn't look like you posted all the relevant code: what does
verifyForward("display") do?
At a guess, I'd say the problem is that whatever is supplying the
expected value ('/myContentRoot/myApp.display.page') is wrong. That's a
tile name, which is an internal value.
L.
Carl Smith wrote:
> Is there any helps here? Thank you in advance.
>
> Carl Smith <cc...@yahoo.com> wrote:
> I am sorry for this a little long question, but you will be finding it interesting... Simply put, I have (1),(2) and (3), then we I run struts testing, I got error described as (4)
>
>
>
> (1) item in struts-config.xml
> type="my.actions.myAction"
> name="myForm"
> scope="request"
> validate="true"
> input="myInput">
>
>
>
> (2) item in tiles-defs.xml
>
>
>
>
>
>
>
>
>
>
>
>
> (3)
> I was trying to test MyAction.java (not shown here since it is just some simple stuff),
> I wrote the following struts testing case:
>
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> // after actionPerform(), MyAction is really forwarding to myApp.display.page
> // so the testing should have passed, but it did not, see below error
> verifyForward("display");
>
> }
>
> }
>
>
>
> (4)
> junit.framework.AssertionFailedError: was expecting '/myContentRoot/myApp.display.page' but received '/myContentRoot/jsp/default.jsp'
> at servletunit.struts.Common.verifyForwardPath(Common.java:170)
> at servletunit.struts.CactusStrutsTestCase.verifyForward(CactusStrutsTestCase.java:432)
>
>
> However, if I delete extends="myDefault" from the configure for myApp.display.page in tiles-defs.xml, then the test case passed.
> It seems there is an issue with the tiles extend, why this is happening? Do you have any idea or workaround?
>
>
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: CactusStrutsTestCase working problem with tiles extension
Posted by Carl Smith <cc...@yahoo.com>.
Thank you Richard for the answering... Since my app is written in a lower J2EE version so I have to use strutstest_2.0.0.jar which doesn't support verifyTilesForward() method.
Any other suggestions? Thanks.
Richard Yee <ry...@cruzio.com> wrote:
Carl,
Check the CactusStrutsTestCase javadoc. You should use
verifyTilesForward instead of verifyForward(). There is also a
verifyInputTilesForward() too.
-Richard
Carl Smith wrote:
> Is there any helps here? Thank you in advance.
>
> Carl Smith wrote:
> I am sorry for this a little long question, but you will be finding it interesting... Simply put, I have (1),(2) and (3), then we I run struts testing, I got error described as (4)
>
>
>
> (1) item in struts-config.xml
> type="my.actions.myAction"
> name="myForm"
> scope="request"
> validate="true"
> input="myInput">
>
>
>
> (2) item in tiles-defs.xml
>
>
>
>
>
>
>
>
>
>
>
>
> (3)
> I was trying to test MyAction.java (not shown here since it is just some simple stuff),
> I wrote the following struts testing case:
>
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> // after actionPerform(), MyAction is really forwarding to myApp.display.page
> // so the testing should have passed, but it did not, see below error
> verifyForward("display");
>
> }
>
> }
>
>
>
> (4)
> junit.framework.AssertionFailedError: was expecting '/myContentRoot/myApp.display.page' but received '/myContentRoot/jsp/default.jsp'
> at servletunit.struts.Common.verifyForwardPath(Common.java:170)
> at servletunit.struts.CactusStrutsTestCase.verifyForward(CactusStrutsTestCase.java:432)
>
>
> However, if I delete extends="myDefault" from the configure for myApp.display.page in tiles-defs.xml, then the test case passed.
> It seems there is an issue with the tiles extend, why this is happening? Do you have any idea or workaround?
>
>
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Re: CactusStrutsTestCase working problem with tiles extension
Posted by Richard Yee <ry...@cruzio.com>.
Carl,
Check the CactusStrutsTestCase javadoc. You should use
verifyTilesForward instead of verifyForward(). There is also a
verifyInputTilesForward() too.
-Richard
Carl Smith wrote:
> Is there any helps here? Thank you in advance.
>
> Carl Smith <cc...@yahoo.com> wrote:
> I am sorry for this a little long question, but you will be finding it interesting... Simply put, I have (1),(2) and (3), then we I run struts testing, I got error described as (4)
>
>
>
> (1) item in struts-config.xml
> type="my.actions.myAction"
> name="myForm"
> scope="request"
> validate="true"
> input="myInput">
>
>
>
> (2) item in tiles-defs.xml
>
>
>
>
>
>
>
>
>
>
>
>
> (3)
> I was trying to test MyAction.java (not shown here since it is just some simple stuff),
> I wrote the following struts testing case:
>
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> // after actionPerform(), MyAction is really forwarding to myApp.display.page
> // so the testing should have passed, but it did not, see below error
> verifyForward("display");
>
> }
>
> }
>
>
>
> (4)
> junit.framework.AssertionFailedError: was expecting '/myContentRoot/myApp.display.page' but received '/myContentRoot/jsp/default.jsp'
> at servletunit.struts.Common.verifyForwardPath(Common.java:170)
> at servletunit.struts.CactusStrutsTestCase.verifyForward(CactusStrutsTestCase.java:432)
>
>
> However, if I delete extends="myDefault" from the configure for myApp.display.page in tiles-defs.xml, then the test case passed.
> It seems there is an issue with the tiles extend, why this is happening? Do you have any idea or workaround?
>
>
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: CactusStrutsTestCase working problem with tiles extension
Posted by Carl Smith <cc...@yahoo.com>.
Is there any helps here? Thank you in advance.
Carl Smith <cc...@yahoo.com> wrote:
I am sorry for this a little long question, but you will be finding it interesting... Simply put, I have (1),(2) and (3), then we I run struts testing, I got error described as (4)
(1) item in struts-config.xml
type="my.actions.myAction"
name="myForm"
scope="request"
validate="true"
input="myInput">
(2) item in tiles-defs.xml
(3)
I was trying to test MyAction.java (not shown here since it is just some simple stuff),
I wrote the following struts testing case:
public class MyActionTest extends CactusStrutsTestCase {
public MyActionTest(String testingName){
super(testingName);
}
public void begin(WebRequest req){
req.setAuthentication(new BasicAuthentication("username","password"));
}
public void testDisplay() throws Exception {
setRequestPathInfo("/MyAction");
actionPerform();
// after actionPerform(), MyAction is really forwarding to myApp.display.page
// so the testing should have passed, but it did not, see below error
verifyForward("display");
}
}
(4)
junit.framework.AssertionFailedError: was expecting '/myContentRoot/myApp.display.page' but received '/myContentRoot/jsp/default.jsp'
at servletunit.struts.Common.verifyForwardPath(Common.java:170)
at servletunit.struts.CactusStrutsTestCase.verifyForward(CactusStrutsTestCase.java:432)
However, if I delete extends="myDefault" from the configure for myApp.display.page in tiles-defs.xml, then the test case passed.
It seems there is an issue with the tiles extend, why this is happening? Do you have any idea or workaround?
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
CactusStrutsTestCase working problem with tiles extension
Posted by Carl Smith <cc...@yahoo.com>.
I am sorry for this a little long question, but you will be finding it interesting... Simply put, I have (1),(2) and (3), then we I run struts testing, I got error described as (4)
(1) item in struts-config.xml
<action path="/MyAction"
type="my.actions.myAction"
name="myForm"
scope="request"
validate="true"
input="myInput">
<forward name="display" path="myApp.display.page" />
</action>
(2) item in tiles-defs.xml
<definition name="myDefault" path="/jsp/default.jsp">
<put name="header" value="/jsp/myHeader.jsp" />
</definition>
<definition name="myApp.display.page" extends="myDefault">
<put name="bodyContent" value="/jsp/myApp.jsp" />
</definition>
(3)
I was trying to test MyAction.java (not shown here since it is just some simple stuff),
I wrote the following struts testing case:
public class MyActionTest extends CactusStrutsTestCase {
public MyActionTest(String testingName){
super(testingName);
}
public void begin(WebRequest req){
req.setAuthentication(new BasicAuthentication("username","password"));
}
public void testDisplay() throws Exception {
setRequestPathInfo("/MyAction");
actionPerform();
// after actionPerform(), MyAction is really forwarding to myApp.display.page
// so the testing should have passed, but it did not, see below error
verifyForward("display");
}
}
(4)
junit.framework.AssertionFailedError: was expecting '/myContentRoot/myApp.display.page' but received '/myContentRoot/jsp/default.jsp'
at servletunit.struts.Common.verifyForwardPath(Common.java:170)
at servletunit.struts.CactusStrutsTestCase.verifyForward(CactusStrutsTestCase.java:432)
However, if I delete extends="myDefault" from the configure for myApp.display.page in tiles-defs.xml, then the test case passed.
It seems there is an issue with the tiles extend, why this is happening? Do you have any idea or workaround?
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Re: multiple struts-config.xml issues with CactusStrutsTestCase
Posted by Carl Smith <cc...@yahoo.com>.
Your solution works perfectly. Thank you Kishore.
Kishore Senji <ki...@gmail.com> wrote:I think by default the CactusStrutsTestCase reads the /WEB-INF/struts-
config.xml only. If you have multiple config files you would have to set the
appropriate config file in your test method. For eg:
public void testDisplay() throws Exception {
setConfigFile("/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml");
setRequestPathInfo("/MyAction");
actionPerform();
verifyForward("Your_forwardTarget_Path");
verifyNoActionErrors();
}
On 9/15/05, Carl Smith wrote:
>
>
> I have two struts-config.xml files. One is Struts default
> struts-config.xml and the other one is called
> struts-my.xml. and I have configued these two xml files in web.xml so that
> ActionServlet can take both struts-config.xml
> and struts-my.xml. See following:
>
>
> action
> org.apache.struts.action.ActionServlet
>
>
config
>
/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml
>
>
>
>
debug
>
2
>
>
>
detail
>
2
>
> 2
>
>
>
> Now I have a Cactus testing action to test MyAction.java (not included
> here), I found out a wired issue:
> if I configure MyAction.java in struts-config.xml, then my test succeed,
> however if I configure MyAction.java
> in struts-my.xml, the test fails with the following error. Any
> suggestions?
>
> junit.framework.AssertionFailedError: Cannot find forward
> 'Your_forwardTarget_Path' - it is possible that it is not mapped correctly.
> at java.lang.Throwable.(Throwable.java:52)
> at java.lang.Throwable.(Throwable.java:66)
>
>
>
>
> package com.ford.hr.mpc.performance.web.struts.action;
>
> import org.apache.cactus.WebRequest;
> import org.apache.cactus.client.authentication.BasicAuthentication;
>
> import servletunit.struts.CactusStrutsTestCase;
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
>
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> verifyForward("Your_forwardTarget_Path");
> verifyNoActionErrors();
> }
>
> }
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: multiple struts-config.xml issues with CactusStrutsTestCase
Posted by Kishore Senji <ki...@gmail.com>.
I think by default the CactusStrutsTestCase reads the /WEB-INF/struts-
config.xml only. If you have multiple config files you would have to set the
appropriate config file in your test method. For eg:
public void testDisplay() throws Exception {
setConfigFile("/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml");
setRequestPathInfo("/MyAction");
actionPerform();
verifyForward("Your_forwardTarget_Path");
verifyNoActionErrors();
}
On 9/15/05, Carl Smith <cc...@yahoo.com> wrote:
>
>
> I have two struts-config.xml files. One is Struts default
> struts-config.xml and the other one is called
> struts-my.xml. and I have configued these two xml files in web.xml so that
> ActionServlet can take both struts-config.xml
> and struts-my.xml. See following:
>
> <servlet>
> <servlet-name>action</servlet-name>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> <init-param>
> <param-name>config</param-name>
> <param-value>/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml
> </param-value>
> </init-param>
> <init-param>
> <param-name>debug</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>detail</param-name>
> <param-value>2</param-value>
> </init-param>
> <load-on-startup>2</load-on-startup>
> </servlet>
>
>
> Now I have a Cactus testing action to test MyAction.java (not included
> here), I found out a wired issue:
> if I configure MyAction.java in struts-config.xml, then my test succeed,
> however if I configure MyAction.java
> in struts-my.xml, the test fails with the following error. Any
> suggestions?
>
> junit.framework.AssertionFailedError: Cannot find forward
> 'Your_forwardTarget_Path' - it is possible that it is not mapped correctly.
> at java.lang.Throwable.<init>(Throwable.java:52)
> at java.lang.Throwable.<init>(Throwable.java:66)
>
>
>
>
> package com.ford.hr.mpc.performance.web.struts.action;
>
> import org.apache.cactus.WebRequest;
> import org.apache.cactus.client.authentication.BasicAuthentication;
>
> import servletunit.struts.CactusStrutsTestCase;
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
>
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> verifyForward("Your_forwardTarget_Path");
> verifyNoActionErrors();
> }
>
> }
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
Re: Why interface
Posted by Ulrich Elsner <ul...@gmail.com>.
On 8/10/05, Laurie Harper <la...@holoweb.net> wrote:
> Carl Smith wrote:
> > In Java/J2EE community, it seems that a lot of experienced developers tend to use a lot of interfaces, however, a lot of junior developers ignore using interface. I am not sure why interfaces seem to be favorite to some experienced developers. Can some one explain this?Can you give examples where an interface is preferred?
>
> Much more importantly than 'because Java doesn't have multiple inheritance'
> is what Dave's alluding to, that if you code to interfaces the
> implementation can be switched without impact. As a more general example,
> consider if you wrote all your code to use ArrayList and later found, after
> profiling, that you needed to switch to LinkedList for performance reasons.
> You'd have to update all your code -- including all the clients of all
> the methods that accepted or returned an ArrayList.
>
> Conversely, if you coded to the List interface, you would only need to
> change the implementation code. All the client code would be unaffected.
> That's Dave's point about being able to switch X for Y with minimal impact.
And to answer the original question to why experienced developers tend
to use interfaces more often than newbies: a seasoned programmer knows
that eventually their code needs to be updated, refactored or otherwise changed.
Hence in the long run, the extra effort it takes to design the
interface will pay off.
The newbie just assumes that he will get it right the first time.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/10/05, Dave Newton <ne...@pingsite.com> wrote:
> Laurie Harper wrote:
>
> > As a more general example, consider if you wrote all your code to use
> > ArrayList and later found, after profiling, that you needed to switch
> > to LinkedList for performance reasons. You'd have to update all your
> > code -- including all the clients of all the methods that accepted or
> > returned an ArrayList.
> >
> > Conversely, if you coded to the List interface, you would only need to
> > change the implementation code. All the client code would be
> > unaffected. That's Dave's point about being able to switch X for Y
> > with minimal impact.
>
> That was a much better example than mine :) I could have typed so much less!
Or even shorter: for polymorphic usage of similar but different classes ;-)
Problem with interfaces is they they are fixed. Once you define an
interface, you have to follow it. Say, you defined (er... I defined ;)
) an CRUD interface and forgot to define crudReset() method. Now even
if crudReset() method is defined in implementing class, it cannot be
polimorphically used for every class implementing CRUD interface.
Bummer.
Interfaces should be designed with much greated attention than regular
class hierarchies. If inteface is extended, then classes using it has
to switch to new interface explicitly.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Dave Newton <ne...@pingsite.com>.
Laurie Harper wrote:
> As a more general example, consider if you wrote all your code to use
> ArrayList and later found, after profiling, that you needed to switch
> to LinkedList for performance reasons. You'd have to update all your
> code -- including all the clients of all the methods that accepted or
> returned an ArrayList.
>
> Conversely, if you coded to the List interface, you would only need to
> change the implementation code. All the client code would be
> unaffected. That's Dave's point about being able to switch X for Y
> with minimal impact.
That was a much better example than mine :) I could have typed so much less!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why interface
Posted by Laurie Harper <la...@holoweb.net>.
Carl Smith wrote:
> In Java/J2EE community, it seems that a lot of experienced developers tend to use a lot of interfaces, however, a lot of junior developers ignore using interface. I am not sure why interfaces seem to be favorite to some experienced developers. Can some one explain this?Can you give examples where an interface is preferred?
Much more importantly than 'because Java doesn't have multiple inheritance'
is what Dave's alluding to, that if you code to interfaces the
implementation can be switched without impact. As a more general example,
consider if you wrote all your code to use ArrayList and later found, after
profiling, that you needed to switch to LinkedList for performance reasons.
You'd have to update all your code -- including all the clients of all
the methods that accepted or returned an ArrayList.
Conversely, if you coded to the List interface, you would only need to
change the implementation code. All the client code would be unaffected.
That's Dave's point about being able to switch X for Y with minimal impact.
In 'text book' terms, extending a base class expresses an IS-A relationship
where implementing an interface expresses a HAS-A (behaviour) relationship.
Inheritance is a very over-used language feature; often it's used to
express a 'has some of the same behaviour as, even if it's semantically
unrelated' relationship -- i.e. as an implementation convenience rather
than an expression of model semantics. Use of interfaces can go a long way
to providing cleaner object models.
Just my 2c...
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: multiple struts-config.xml issues with CactusStrutsTestCase
Posted by Praveen Kumar <va...@yahoo.com>.
HI
I dont know about Cactus . But Struts 1.2 onwards only more than one struts-config files are allowed that to be in this manner
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>com.struts.action.ActionServlet</servlet-class>
/////////// THis is for Defalut ////////////////////
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
/////////////////// This is for our own module//////////////////////////////
<init-param>
<param-name>my/config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
</servlet>
Pls check struts 1.2 spec for more clarification........
Regards
Praveen
Laurie Harper <la...@holoweb.net> wrote:
It's been rather a long time since I used Cactus so I can't rememner the
details of how you set things up, but are you sure that struts-my.xml is
being read in when you run your cactus tests?
L.
Carl Smith wrote:
> I have two struts-config.xml files. One is Struts default struts-config.xml and the other one is called
> struts-my.xml. and I have configued these two xml files in web.xml so that ActionServlet can take both struts-config.xml
> and struts-my.xml. See following:
>
>
> action
> org.apache.struts.action.ActionServlet
>
>
config
>
/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml
>
>
>
debug
>
2
>
>
>
detail
>
2
>
> 2
>
>
>
> Now I have a Cactus testing action to test MyAction.java (not included here), I found out a wired issue:
> if I configure MyAction.java in struts-config.xml, then my test succeed, however if I configure MyAction.java
> in struts-my.xml, the test fails with the following error. Any suggestions?
>
> junit.framework.AssertionFailedError: Cannot find forward 'Your_forwardTarget_Path' - it is possible that it is not mapped correctly.
> at java.lang.Throwable.(Throwable.java:52)
> at java.lang.Throwable.(Throwable.java:66)
>
>
>
>
> package com.ford.hr.mpc.performance.web.struts.action;
>
> import org.apache.cactus.WebRequest;
> import org.apache.cactus.client.authentication.BasicAuthentication;
>
> import servletunit.struts.CactusStrutsTestCase;
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
>
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> verifyForward("Your_forwardTarget_Path");
> verifyNoActionErrors();
> }
>
> }
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: multiple struts-config.xml issues with CactusStrutsTestCase
Posted by Laurie Harper <la...@holoweb.net>.
It's been rather a long time since I used Cactus so I can't rememner the
details of how you set things up, but are you sure that struts-my.xml is
being read in when you run your cactus tests?
L.
Carl Smith wrote:
> I have two struts-config.xml files. One is Struts default struts-config.xml and the other one is called
> struts-my.xml. and I have configued these two xml files in web.xml so that ActionServlet can take both struts-config.xml
> and struts-my.xml. See following:
>
> <servlet>
> <servlet-name>action</servlet-name>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> <init-param>
> <param-name>config</param-name>
> <param-value>/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml</param-value>
> </init-param>
> <init-param>
> <param-name>debug</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>detail</param-name>
> <param-value>2</param-value>
> </init-param>
> <load-on-startup>2</load-on-startup>
> </servlet>
>
>
> Now I have a Cactus testing action to test MyAction.java (not included here), I found out a wired issue:
> if I configure MyAction.java in struts-config.xml, then my test succeed, however if I configure MyAction.java
> in struts-my.xml, the test fails with the following error. Any suggestions?
>
> junit.framework.AssertionFailedError: Cannot find forward 'Your_forwardTarget_Path' - it is possible that it is not mapped correctly.
> at java.lang.Throwable.<init>(Throwable.java:52)
> at java.lang.Throwable.<init>(Throwable.java:66)
>
>
>
>
> package com.ford.hr.mpc.performance.web.struts.action;
>
> import org.apache.cactus.WebRequest;
> import org.apache.cactus.client.authentication.BasicAuthentication;
>
> import servletunit.struts.CactusStrutsTestCase;
>
> public class MyActionTest extends CactusStrutsTestCase {
> public MyActionTest(String testingName){
> super(testingName);
> }
>
>
> public void begin(WebRequest req){
> req.setAuthentication(new BasicAuthentication("username","password"));
>
> }
>
> public void testDisplay() throws Exception {
> setRequestPathInfo("/MyAction");
> actionPerform();
> verifyForward("Your_forwardTarget_Path");
> verifyNoActionErrors();
> }
>
> }
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT ]Re: Why interface
Posted by DG...@EvergreenInvestments.com.
"Program to an interface, not an implementation."
#1 principle from GoF. Here's a recent interview with Erich Gamma:
http://www.artima.com/lejava/articles/designprinciples.html
-Dennis
Carl Smith <cc...@yahoo.com>
08/10/2005 10:47 AM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@struts.apache.org>
cc
Subject
Why interface
In Java/J2EE community, it seems that a lot of experienced developers tend
to use a lot of interfaces, however, a lot of junior developers ignore
using interface. I am not sure why interfaces seem to be favorite to some
experienced developers. Can some one explain this?Can you give examples
where an interface is preferred?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[OT] Re: Why interface
Posted by Jerry Tan <jt...@dtcc.com>.
At the end of the day, some would say there's really no functional
difference between the two.
But as for a preference for interfaces, well, partly it's due to the
limitation of single inheritance in Java. Using interfaces provides the
functionality of acting as a derivative of multiple base classes, without
bumping into any of the difficulties or heartache in a language that does
allow true multiple base classes.
Another reason is that using interfaces allows a simpler extension point
that others can use in the future, without necessarily inheriting any of
the other miscellaneous members in a base class that would not actually be
used (which may not have been originally properly scoped in the base).
Defining an interface during a design phase also forces you to think long
and hard about what is the true *core* functionality of the object you're
trying to model, i.e., what are the minimal characteristics that such an
object satisfying this role would require, whether that role is what a
method returns or what it takes as a parameter.
So this process of stripping down some problem domain to its core "verbs",
so to speak, does help streamline the design process somewhat, i.e.,
forcing you to think purely in terms of functionality as these are exposed
through methods, rather than also having to think about how data members
may or may not fit in, or the interaction between these "verbs" and the
data it acts upon, which is something that would come up when you're
thinking of designing something through inheritance of base classes.
HTH, my 2 cents.
Carl Smith
<ccsmith20002001@
yahoo.com> To
Struts Users Mailing List
08/10/2005 10:47 <us...@struts.apache.org>
AM cc
Subject
Please respond to Why interface
"Struts Users
Mailing List"
<user@struts.apac
he.org>
In Java/J2EE community, it seems that a lot of experienced developers tend
to use a lot of interfaces, however, a lot of junior developers ignore
using interface. I am not sure why interfaces seem to be favorite to some
experienced developers. Can some one explain this?Can you give examples
where an interface is preferred?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Why interface
Posted by Carl Smith <cc...@yahoo.com>.
In Java/J2EE community, it seems that a lot of experienced developers tend to use a lot of interfaces, however, a lot of junior developers ignore using interface. I am not sure why interfaces seem to be favorite to some experienced developers. Can some one explain this?Can you give examples where an interface is preferred?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
multiple struts-config.xml issues with CactusStrutsTestCase
Posted by Carl Smith <cc...@yahoo.com>.
I have two struts-config.xml files. One is Struts default struts-config.xml and the other one is called
struts-my.xml. and I have configued these two xml files in web.xml so that ActionServlet can take both struts-config.xml
and struts-my.xml. See following:
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml,/WEB-INF/struts-my.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
Now I have a Cactus testing action to test MyAction.java (not included here), I found out a wired issue:
if I configure MyAction.java in struts-config.xml, then my test succeed, however if I configure MyAction.java
in struts-my.xml, the test fails with the following error. Any suggestions?
junit.framework.AssertionFailedError: Cannot find forward 'Your_forwardTarget_Path' - it is possible that it is not mapped correctly.
at java.lang.Throwable.<init>(Throwable.java:52)
at java.lang.Throwable.<init>(Throwable.java:66)
package com.ford.hr.mpc.performance.web.struts.action;
import org.apache.cactus.WebRequest;
import org.apache.cactus.client.authentication.BasicAuthentication;
import servletunit.struts.CactusStrutsTestCase;
public class MyActionTest extends CactusStrutsTestCase {
public MyActionTest(String testingName){
super(testingName);
}
public void begin(WebRequest req){
req.setAuthentication(new BasicAuthentication("username","password"));
}
public void testDisplay() throws Exception {
setRequestPathInfo("/MyAction");
actionPerform();
verifyForward("Your_forwardTarget_Path");
verifyNoActionErrors();
}
}
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: MVC Question
Posted by Stéphane Zuckerman <st...@gmail.com>.
> I guess my question is: is the action form considered part of the model? If
> not, what?
I think the question's been asked (in a different way) a few days/weeks
ago. Here's what Frank W. Zammetti said about it :
"
The Model is something, conceptually, outside of Struts. Struts provides
nothing for dealing with the Model.
Imagine that you write some classes that know how to talk to your
database, know how to perform your business logic. Further imagine that
these classes have a known set of methods (i.e., expose a known interface)
that can be called to form the application.
More specifically, imagine you have an application where you want to be
able to maintain a list of students and what classes they are taking in
school. Without arguing about how best to actually architect this (i.e.,
let's forget about DTOs and DAOs and persistence layers and all that and
keep it simple), you might come up with something like this:
Class Student
-------------
Method: List listStudents()
lists all students in the database
Method: void createStudent(String studentName, String ssn)
Creates a user with a given SSN in the database
Method: Map getStudent(String studentName)
Gets all the details for a given student from the database
Method: void addClass(String studentName, String className)
Adds a class a given student is attending
Method: void deleteClass(String studentName, String className)
Deletes a class a givent student is attending
Method: List listClasses(String studentName)
Lists all the classes a given student is attending
>From this you can create a webapp that allows you to list students, pick
one, see their details including what classes they are taking, and add and
remove classes. Again, we're ignoring how you really should architect
this, I'm just trying to get the basic point across.
Also note that this is completely independant of the fact that you are
writing a webapp. You can just as easily write a Swing-based client that
uses this class, or any other presentation technology.
Now, you have a single class that exposes a known interface that for all
intents and purposes represents your model.
Now, from your Struts Actions, you call these methods and render the
results as appropriate. The method parameters like studentName and
className would probably be coming in as request parameters, so you just
instantiate your Student class and call the appropriate method, then take
the result and pass it to the view for display. Struts itself doesn't
deal with the model for you. How you get at these classes is also up to
you... could be a JNDI lookup, could be just included with your app, etc.
Struts leaves this to you entirely.
Hope that answers your question :)
"
--
Stéphane Zuckerman
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org