You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by chamal desilva <ch...@yahoo.com> on 2006/06/08 18:29:34 UTC
ActionForm and EJB
Hi,
I read few articles on struts. They recommend not to
send action form class to EJBs as data holders. They
recommend we should use general classes for holding
data to decople web tier with EJBs.
What they say must be correct but I still have few
doubts (Maybe b'cause I am not experienced).
Don't we have to modify two classes, if we use both
ActionForms and normal java classes to store data.For
example we will have modify two classes to add a new
attribute, remove attribute etc.
Please help me to understand this more clearly.
Thanking You,
Chamal.
__________________________________________________
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: Reload the same page
Posted by "Albert L. Sapp" <as...@uiuc.edu>.
Maya menon wrote:
>All,
>
> I have a page, results.jsp with a link
> < ahref="deleteAction.do?/>
>
> In deleteAction, the record will be deleted by calling the helper classes and on succesful delete the request should be forwarded again to the results.jsp.
>
> How can I achieve this ?
>
> In strts-config, i have it properly pointed. But the page doesnot refresh. Am I missing anything ?
>
> Thanks
>
>
> __________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>
In our application, we place the parameters that created the results in
session scope bean. Then, you can rebuild your results for the result
page in the delete action or redirect on a successful delete back to the
action that normally does the query and builds the results.
HTH,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Reload the same page
Posted by Maya menon <ma...@yahoo.com>.
All,
I have a page, results.jsp with a link
< ahref="deleteAction.do?/>
In deleteAction, the record will be deleted by calling the helper classes and on succesful delete the request should be forwarded again to the results.jsp.
How can I achieve this ?
In strts-config, i have it properly pointed. But the page doesnot refresh. Am I missing anything ?
Thanks
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: ActionForm and EJB
Posted by Michael Jouravlev <jm...@gmail.com>.
On 6/8/06, Craig McClanahan <cr...@apache.org> wrote:
> On 6/8/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> * Annotations are not a good idea when the configuration concept should
> not be a concern of the person actually writing the code. In webapps, for
> example, I don't believe in configuring page navigation rules (Struts
> forwards,
> JSF navigation rules and cases, etc) directly into the action methods.
> The
> actions should describe what happened, not where to go next -- and this is
> something I personally don't care for, even at the code level, the way
> that
> WW2 does Results (or Spring MVC does ModelAndView) that combine
> the two concerns together. But that's a separate issue from whether
> the encoding should be with annotations or not :-).
I don't think that framework should define the navigation at all.
Well, maybe in some specific cases like redirecting a non-logged-in
user to a login page. But generally, a user navigates to a certain
resource himself by clicking links. Resources have states; depending
on state they render themselves differently, but this is not
navigation, this is just views/subviews. Programmatic navigation seems
like a wrong concept altogether to me.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, June 8, 2006 2:46 pm, Craig McClanahan wrote:
> Always slow to get on the latest bandwagon, eh Frank :-)
Who, what, me?!? Nnnnnaaaahhhhhh!
(hey, you were the last Ant vs. Maven holdout, I was happy I wasn't the
only one... you left me man!! LOL)
> That being said, XML configuration files are going out of fashion, at
> least
> among the developers who speak out a lot :-).
Yeah, I noticed that. :) I'll be there in 5 years or so :)
I personally think this is the case because there are some *bad* XML
config files around. I think when done right they are still preferable in
most cases. However...
> Here's my two cents on when
> I
> like to use annotations, and when I don't.
>
> * Annotations are a good idea when the configuration concept is directly
> related to how you code your source. Examples include beans used
> in a webapp (it really matters whether you're going to store it in
> request
> scope or session scope or application scope), transactional settings
> on an EJB, and so on. Storing the actual annotation in the source code
> reduces the chances that some sysadmin installing your application might
> accidentally or inadvertently change the scope setting, without
> understanding
> that they just broke your code.
Definitely fair poins... and I have to admit, looking at EJB3 as an
example, I in fact *love* annotations! EJB's (pre-EJB3) are probably the
best example IMO of where config files can go wrong.
> * Annotations are not a good idea when the configuration concept should
> not be a concern of the person actually writing the code. In webapps,
> for
> example, I don't believe in configuring page navigation rules (Struts
> forwards,
> JSF navigation rules and cases, etc) directly into the action methods.
> The
> actions should describe what happened, not where to go next -- and this
> is
> something I personally don't care for, even at the code level, the way
> that
> WW2 does Results (or Spring MVC does ModelAndView) that combine
> the two concerns together. But that's a separate issue from whether
> the encoding should be with annotations or not :-).
I agree with you here too. I remember 5 years or so ago before I started
using Struts, we built our own framework here, and one of the really nice
things about it is that all the navigations rules were in a database... we
could literally change the flow of the application on the fly (a few
exceptions, as you might expect, but generally true). Separating
navigation rules and such from the code I agree is probably not the right
use for annotations.
Good thoughts... I think we agree here almost entirely :) I like your
differentiation too... I think when I said I wasn't sold on annotations
yet I may have been subconsciously thinking of the things we both think
may not be the best use for them. Especially given EJB3, where I do
really see where they make life better, maybe I'm a little more on the
bandwagon than I thought already! :-)
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Craig McClanahan <cr...@apache.org>.
On 6/8/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
[snip]
>
> I'm still not sold on the whole concept of annotations myself... it seems
> to encourage scattering things throughout the code base that otherwise
> would be centralized.
Always slow to get on the latest bandwagon, eh Frank :-)
Ironically, the fact that Struts had, from the very beginning, a centralized
configuration file was one of the critical success factors in its early
growth. Not just because everything was in one place, but because it was
very easy for tooling around Struts to use struts-config.xml as the
persistence format ... no need to invent some data structure proprietary to
a particular tool, and which couldn't be shared across tools when the user
switches IDEs.
That being said, XML configuration files are going out of fashion, at least
among the developers who speak out a lot :-). Here's my two cents on when I
like to use annotations, and when I don't.
* Annotations are a good idea when the configuration concept is directly
related to how you code your source. Examples include beans used
in a webapp (it really matters whether you're going to store it in request
scope or session scope or application scope), transactional settings
on an EJB, and so on. Storing the actual annotation in the source code
reduces the chances that some sysadmin installing your application might
accidentally or inadvertently change the scope setting, without
understanding
that they just broke your code.
* Annotations are not a good idea when the configuration concept should
not be a concern of the person actually writing the code. In webapps, for
example, I don't believe in configuring page navigation rules (Struts
forwards,
JSF navigation rules and cases, etc) directly into the action methods.
The
actions should describe what happened, not where to go next -- and this is
something I personally don't care for, even at the code level, the way
that
WW2 does Results (or Spring MVC does ModelAndView) that combine
the two concerns together. But that's a separate issue from whether
the encoding should be with annotations or not :-).
* Annotations should also not be used to configure decisions where it is
appropriate to allow the user of your code an opportunity to override the
annotated choice, unless you also provide some mechanism to override
by exception. The Java EE specs that use annotations have tried to
follow this principle, allowing you to change certain aspects of what was
coded in annotations in the first place.
Craig
Re: ActionForm and EJB
Posted by Dave Newton <ne...@pingsite.com>.
Michael Jouravlev wrote:
> Check out Stripes, great stuff.
It is indeed pretty cool.
I really dislike putting my URL mappings in code, though, if for no
other reason than if I'm testing or need to stub out a URL handler
temporarily for some reason I have to touch things in two different
places (maybe I don't; I haven't looked in to it).
I think that's more or less what Craig was saying as well; there are
some things that simply don't belong in annotations; for me that's
really high on the list.
I'd also rather tweak a config file to define a service implementation
than dink in the source code, although that one is less problematic for me.
If it doesn't change the way I'd write the code then for me it's better
somewhere else than the code. Like Frank I've also done a lot with
putting things into a DB that can alter (sometimes radically!) the way
an application works without having to restart anything (DI configured
from a DB can be WONDERFUL, especially if you don't have access to the
config files... and can store implementations in the DB... dangerous,
but very handy).
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, June 8, 2006 3:07 pm, Michael Jouravlev wrote:
> So your argument is basically that database roundtrips will degrade
> performance.
Yes, but that's only one aspect of it... scalability is also a factor, as
is number of breakage point, as is cost, because to overcome the first two
you have to spend more. Not to mention complexity, and the need to hire
people with more database expertise.
> This should not (ideally) bother an application
> developer. A framework should care about that.
As far as who provides the actual code, I agree. But certainly the
application developer has to worry about how the architecture affects
performance, scalability, stability, etc, whether they write the code
themselves or not.
> If
> database has already defined the rules, they should be used.
But can you even code all the complex business logic in the database that
you might require? I suppose you could write stored procs in Java... I
wonder how much more difficult that would prove than business classes on
the app server? (I've never done it, so I don't know)
> But I
> don't want to repeat the same rules again and again.
This part we definitely agree on. But a Craig pointed out, there are
different kinds of validation rules, and the repetition is limited
somewhat by the domains being different. What I mean is, you want to
create a new Student record in the database... you may want to validate
that the first name, last name and teacher's name are entered. You do
that in the presentation (whether on the client or server, doesn't matter)
because they aren't "business rules" per se. You can do this and not
duplicate the code (use Commons Validator, can be called via AJAX if you
want, I've done it). Now, when you save the record, the record is to be
tied to the teacher's record. So, now you have a referential integrity
check: does the entered teacher's name exist? This isn't a check you
would generally do in the presentation layer anyway, they are really two
separate concerns, and appropriate in different places, so there's no real
duplication there.
To summarize my thinking, I think there's really three different types of
validation: presentation, business and data model.
The presentation-type validations are where you many times see
duplication... i.e., Javascript to see if a first name is filled in, then
that same check done on the server, since that double-checking is of
course a best practice. I think there are ways to avoid that though:
doing those validations with Commons Validator and calling it via AJAX,
and still letting those SAME RULES fire when the final form is submitted,
does the trick (or letting Struts generate the client-side validation
code, if you want to avoid the AJAX call).
For business rules, these are the "is the entered dollar amount greater
than the max value for this client?" sort of validations. I find these to
be more appropriate on the app server, NOT in the database, for a variety
of reasons (all the reasons I mentioned earlier, plus the fact that many
times you find that you want a chain of such validations, which I think is
easier to build outside the database using a real CoR implementation).
Then you have the database validations, things like referential integrity.
In other words, only do validations here that couldn't be done previously
without hitting the database. This also simplifies the data tier because
it tends to reduce the number of stored procs (read: code in the database)
that has to be written... most of this can be done with triggers and such,
which aren't really code, not as much as stored procs anyway. In other
words, I view the database as a database and not an app server,
generally-speaking.
> Unless I use several databases or design a
> clustered system, I am not tempted to use EJBs at all.
I've historically HATED EJBs for various reasons... I think EJB3 finally
begins to get them right, and I think you may be surprised how and where
you want to use them all of a sudden. Another discussion for another day
though :)
> Check out Stripes, great stuff.
Yes, it's on my "take a look at that" list already :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Michael Jouravlev <jm...@gmail.com>.
On 6/8/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> On Thu, June 8, 2006 2:12 pm, Craig McClanahan wrote:
> > * Enhance the user experience by catching errors as quickly
> > as possible (ideally client side in a webapp), with error messages that
> > are relevant to the user's context in that particular application.
>
> Absolutely agree.
>
> > * Minimize the number of times I need to specify the same
> > validation in source code, metadata, or whatever. Ideally, every
> > such requirement should be stated exactly once.
>
> Absolutely agree.
So your argument is basically that database roundtrips will degrade
performance. This should not (ideally) bother an application
developer. A framework should care about that. Metadata retrieval, its
caching, converting metadata to validation rules, combining these
rules with custom rules, this should be performed by a framework. If
database has already defined the rules, they should be used. Whether
it is database itself, or in DAO, or on business layer, or by
validator - does not matter for me as an application developer. But I
don't want to repeat the same rules again and again.On the other hand
I want to be able to add/modify/hide rules or object relationships.
These tasks have been implemented and reimplemented so many times by
many framework/tool developers (not only for Java) that I wonder why
it took 8 years or so for JSR 299 to appear. Still, EJBs as they are
defined now, do not automatically pull and use database metadata (or
do they? I should check out EJB 3.0 spec). So I will be able to use
EJBs as backing beans. BFD. Unless I use several databases or design a
clustered system, I am not tempted to use EJBs at all. If EJB
penetrated deeper in database metadata, then I would have a better
incentive to use them (again, have to check the spec. Maybe it already
does what I want).
> I'm still not sold on the whole concept of annotations myself... it seems
> to encourage scattering things throughout the code base that otherwise
> would be centralized.
Check out Stripes, great stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, June 8, 2006 2:12 pm, Craig McClanahan wrote:
> IMHO, where and how to do what kinds of validations is going to be the
> next
> "great debate" in application framework design :-)
Hehe, it's a debate that's been around for a while, not sure it can be the
"next" great debate :) LOL
> * Enhance the user experience by catching errors as quickly
> as possible (ideally client side in a webapp), with error messages that
> are relevant to the user's context in that particular application.
Absolutely agree.
> * Minimize the number of times I need to specify the same
> validation in source code, metadata, or whatever. Ideally, every
> such requirement should be stated exactly once.
Absolutely agree.
> It's also important to recognize that there's more than one kind of
> validation here ... the most important distinction being presentation ("is
> the date entered by the user syntactically correct for the locale that the
> user is interacting with" or "is this a correctly formatted credit card
> number") versus business rules ("is the invoice date after the customer's
> account-open date" or "is this credit card number and expiration date
> actually valid").
This is of course true... interestingly, I recently did a sample app for
some folks at work to demonstrate using Commons Validator via AJAX calls.
In the demo, there was a textbox for an account number entry. The example
verifies that the account exists on a mainframe system, so I had a custom
rule that did the call to the mainframe and all that. This was done via
an AJAX call in response to the onBlur of the field. It's interesting
because I also demonstrated how the "regular" Struts app still worked with
exactly the same validation rules, and it also showed that you can indeed
code "business rules" in Commons Validator, and of course it showed how
you can essentially do an event-based validation from the client, all
using the same set of rules and code.
> Because the database will have date-oriented data
> already
> converted to a DATE data type, it doesn't really seem appropriate to
> specify
> the presentation style restrictions there (most likely it'd be the same
> stuff for every single DATE in the entire schema). You've also got to
> deal
> with interesting complexities such as fields that are required in some
> contexts and not others, so you probably want some mechanism to deal with
> exceptions or overrides of the embedded rules.
Agreed.
> Indeed, this whole concept is relevant beyond just web frameworks ... it
> would make sense in the long term to have a JSR that standardized a set of
> validation annotations everyone could share, while giving various
> frameworks
> the freedom to implement the semantics of doing the validation in whatever
> fashion best fits the particular technologies that framework uses.
I'm still not sold on the whole concept of annotations myself... it seems
to encourage scattering things throughout the code base that otherwise
would be centralized. I do think it matters what is being annotated
though... I'm pretty strongly against annotating configuration information
for instance, but validation rules... that doesn't quute bother me as
much, not at first blush anyway.
A true validation JSR though, whatever the ultimate implementation
details, I could definitely get behind.
>
> Dave
>
>
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Craig McClanahan <cr...@apache.org>.
On 6/8/06, Dave Newton <ne...@pingsite.com> wrote:
>
> Frank W. Zammetti wrote:
> > On Thu, June 8, 2006 1:09 pm, Michael Jouravlev wrote:
> >
> >> On the other hand, the whole idea of Struts/Commons Validator sucks
> >> big time, because database already has all necessary validations,
> >> domains, triggers, etc. Since most apps use database anyway, input
> >> data should either be validated directly by a database or by DAO; DAO
> >> should pull metadata from database to build validation/conversion
> >> rules. Seems that Ruby on Rails is closer to this approach, while most
> >> other frameworks do the same job twice or even three times.
> >>
> >
> > I *totally* disagree with this :)
> >
>
> +1, and Frank didn't even mention that complex business-model-aware
> validations most likely _can't_ be done in the database without a pretty
> robust payer of triggers and stored procs, which are generally
> DB-specific: I don't want to validate zipcodes for addresses anwhere but
> at the outer-most levels of the app.
>
> I want form validation to be done as close to the form as possible. I
> want business-logic style validation to be done immediately following
> generic form processing. DB-level validation (references, etc.) handled
> last, and preferably the most generic.
IMHO, where and how to do what kinds of validations is going to be the next
"great debate" in application framework design :-) I'll sketch below what I
believe might be an ideal scenario, starting with a couple of motivating
goals:
* Enhance the user experience by catching errors as quickly
as possible (ideally client side in a webapp), with error messages that
are relevant to the user's context in that particular application.
* Minimize the number of times I need to specify the same
validation in source code, metadata, or whatever. Ideally, every
such requirement should be stated exactly once.
It's also important to recognize that there's more than one kind of
validation here ... the most important distinction being presentation ("is
the date entered by the user syntactically correct for the locale that the
user is interacting with" or "is this a correctly formatted credit card
number") versus business rules ("is the invoice date after the customer's
account-open date" or "is this credit card number and expiration date
actually valid"). Because the database will have date-oriented data already
converted to a DATE data type, it doesn't really seem appropriate to specify
the presentation style restrictions there (most likely it'd be the same
stuff for every single DATE in the entire schema). You've also got to deal
with interesting complexities such as fields that are required in some
contexts and not others, so you probably want some mechanism to deal with
exceptions or overrides of the embedded rules.
As to where/how to specify validation rules, using annotations for this (at
a couple of different levels) looks like an interesting possibility --
indeed, it was one of the topics that several of the Struts committers who
got together at JavaOne this year talked about briefly. One could envision
a situation where business logic validations were encoded as annotations on
the POJOs representing your persistence tier (JPA entity classes, Hibernate
based persistent classes, whatever), while presentation tier validations
were encoded on whatever things your presentation framework uses to store
the intermediate values (properties on an SAF1 ActionForm, or an SAF2/WW
action, or on JSF backing bean, for example). Ideally, your presentation
framework would also be able to "reach through" to the business rule
validations of the persistent objects your input forms are bound to, so it
could perform whatever business rule validations it was able to on the
client side (again, in a webapp world, perhaps by having your input field
widgets to AJAX callbacks to the server where necessary).
Indeed, this whole concept is relevant beyond just web frameworks ... it
would make sense in the long term to have a JSR that standardized a set of
validation annotations everyone could share, while giving various frameworks
the freedom to implement the semantics of doing the validation in whatever
fashion best fits the particular technologies that framework uses.
Dave
Craig
Re: ActionForm and EJB
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
> On Thu, June 8, 2006 1:09 pm, Michael Jouravlev wrote:
>
>> On the other hand, the whole idea of Struts/Commons Validator sucks
>> big time, because database already has all necessary validations,
>> domains, triggers, etc. Since most apps use database anyway, input
>> data should either be validated directly by a database or by DAO; DAO
>> should pull metadata from database to build validation/conversion
>> rules. Seems that Ruby on Rails is closer to this approach, while most
>> other frameworks do the same job twice or even three times.
>>
>
> I *totally* disagree with this :)
>
+1, and Frank didn't even mention that complex business-model-aware
validations most likely _can't_ be done in the database without a pretty
robust payer of triggers and stored procs, which are generally
DB-specific: I don't want to validate zipcodes for addresses anwhere but
at the outer-most levels of the app.
I want form validation to be done as close to the form as possible. I
want business-logic style validation to be done immediately following
generic form processing. DB-level validation (references, etc.) handled
last, and preferably the most generic.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, June 8, 2006 1:09 pm, Michael Jouravlev wrote:
> On the other hand, the whole idea of Struts/Commons Validator sucks
> big time, because database already has all necessary validations,
> domains, triggers, etc. Since most apps use database anyway, input
> data should either be validated directly by a database or by DAO; DAO
> should pull metadata from database to build validation/conversion
> rules. Seems that Ruby on Rails is closer to this approach, while most
> other frameworks do the same job twice or even three times.
I *totally* disagree with this :)
If a user is supposed to enter a first name, and they don't, there is NO
WAY I want to be going through all the overhead of hitting my database to
find that out. That's just a recipe for disaster in terms of scalability.
Even if you ask the DAO to do it, and even if all the rules are in the
DAO and the databse doesn't have to get involved, it's still going down
too far into the application. I grant you that some level of validation
still generally should happen there, as well as at the database, but in
general you want to catch any sort of validation error as soon as you can,
whether that means Javascript on the client for simple things or in the
database for more complex things (i.e., referential integrity).
No, you want as much validation to occur as close to the source of the
problem as possible. I agree with you that doing it 2 or 3 times isn't
good, and there is probably room for improvement in this regard, but I
definitely would not let it fall to the database as a rule.
Also, to assume that everyone has all sorts of triggers and domains and
such on their databases is, in my experience, a fallacy. I've seen
numerous databases that have nothing more than required fields and
referential intergrity defined, and that's it. Any data coming in is
assumed to otherwise have already been validated. Some people are
downright averse to doing more in the database for various reasons.
> Michael.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Michael Jouravlev <jm...@gmail.com>.
On 6/8/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Second, an ActionForm is, usually, used to repopulate an HTML form on a
> page when an error occurs, or when a page is initially shown. Since HTML
> forms only deal in Strings, another recommendation you frequently hear is
> to only have Strings in your ActionForms. For example, if you have a
> textbox in your HTML form for a user to enter a date, having a real Date
> field in the ActionForm can lead to problems because of the conversions
> that have to take place back and forth (and if I remember correctly, no
> conversion is done when redisplaying the HTML form anyway, so you'll get
> the default toString() of the Date object, which is almost certainly not
> what you want). If you instead make it a String field, the only
> conversion is when you ultimately need to pass it to the business layer,
> in which case you have more full control over it. So, since you probably
> want to be dealing with real Java data types in your business classes, but
> an ActionForm was designed to deal with HTML forms and therefore only
> Strings, trying to make an ActionForm serve both purposes can lead to
> problems, so its easier to just avoid the situation altogether.
Plugins like FormDef help with that. FormDef allows to nest a BO/DTO
inside a dynamic form bean, and to define conversion rules. FormDef
also integrates with validator.
On the other hand, the whole idea of Struts/Commons Validator sucks
big time, because database already has all necessary validations,
domains, triggers, etc. Since most apps use database anyway, input
data should either be validated directly by a database or by DAO; DAO
should pull metadata from database to build validation/conversion
rules. Seems that Ruby on Rails is closer to this approach, while most
other frameworks do the same job twice or even three times.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi Chamal,
The recommendation of not passing ActionForms to your business classes
stems from two thoughts...
First, by passing an ActionForm, you tie your business clases to Struts.
Should you want to change to another framework later, your business
classes should be unaffected, therefore, passing POJOs to them is a better
idea. This also makes unit testing them a little easier since you don't
have to manually construct an ActionForm during the test (this isn't such
a big deal with ActionForm, but imagine if it for some reason had a
reference to an HttpRequest object, then it would be more of a hassle).
Second, an ActionForm is, usually, used to repopulate an HTML form on a
page when an error occurs, or when a page is initially shown. Since HTML
forms only deal in Strings, another recommendation you frequently hear is
to only have Strings in your ActionForms. For example, if you have a
textbox in your HTML form for a user to enter a date, having a real Date
field in the ActionForm can lead to problems because of the conversions
that have to take place back and forth (and if I remember correctly, no
conversion is done when redisplaying the HTML form anyway, so you'll get
the default toString() of the Date object, which is almost certainly not
what you want). If you instead make it a String field, the only
conversion is when you ultimately need to pass it to the business layer,
in which case you have more full control over it. So, since you probably
want to be dealing with real Java data types in your business classes, but
an ActionForm was designed to deal with HTML forms and therefore only
Strings, trying to make an ActionForm serve both purposes can lead to
problems, so its easier to just avoid the situation altogether.
HTH,
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
On Thu, June 8, 2006 12:29 pm, chamal desilva wrote:
> Hi,
>
> I read few articles on struts. They recommend not to
> send action form class to EJBs as data holders. They
> recommend we should use general classes for holding
> data to decople web tier with EJBs.
>
> What they say must be correct but I still have few
> doubts (Maybe b'cause I am not experienced).
>
> Don't we have to modify two classes, if we use both
> ActionForms and normal java classes to store data.For
> example we will have modify two classes to add a new
> attribute, remove attribute etc.
>
> Please help me to understand this more clearly.
>
> Thanking You,
> Chamal.
>
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Michael Jouravlev <jm...@gmail.com>.
On 6/8/06, chamal desilva <ch...@yahoo.com> wrote:
> Hi,
>
> I read few articles on struts. They recommend not to
> send action form class to EJBs as data holders. They
> recommend we should use general classes for holding
> data to decople web tier with EJBs.
>
> What they say must be correct but I still have few
> doubts (Maybe b'cause I am not experienced).
>
> Don't we have to modify two classes, if we use both
> ActionForms and normal java classes to store data.For
> example we will have modify two classes to add a new
> attribute, remove attribute etc.
>
> Please help me to understand this more clearly.
It is not a good practice for persistence layer to know details about
presentation layer.
What you can do is to use our business objects as nested object within
a form bean. When you submit an HTML form, Struts will automatically
populate your nested business object, which you can persist.
Btw, new web beans JSR will allow to use EJBs directly as JSF backing
beans. So maybe this could be a reason for you to switch to JSF.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: ActionForm and EJB
Posted by Truong Xuan Tinh <ti...@pyramid-consulting.com>.
chamal desilva wrote:
> Hi,
>
> I read few articles on struts. They recommend not to
> send action form class to EJBs as data holders. They
> recommend we should use general classes for holding
> data to decople web tier with EJBs.
>
That's right.
> What they say must be correct but I still have few
> doubts (Maybe b'cause I am not experienced).
>
> Don't we have to modify two classes, if we use both
> ActionForms and normal java classes to store data.For
> example we will have modify two classes to add a new
> attribute, remove attribute etc.
>
>
You will use a Data Transfer Object (or Value Object as some called) to
wrap the data from your form bean, and send to the EJB and vice versa.
Then the EJB layer wont depend on the form bean (view layer). That's
best practices.
> Please help me to understand this more clearly.
>
> Thanking You,
> Chamal.
>
>
> __________________________________________________
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org