Hello,
Sorry to be coming in so late on this, but I had a couple of basic
questions (I have only started using STRUTS, so if this is obvious
please slap some links at me and send me on my way :-) ):
Which object type are people having their Action's send into their
business and/or data layers: ones that derive from ActionForm or ones
that implement the Value Object pattern? And how are they converting the
business and/or data layer's response back (into Action Forms? or are
you sending back the Value Object so that the custom tags can use
that?).
My initial feeling on this was to only send Value Objects to the
business and data layers so that they would not get coupled to what is
obviously a presentation layer object (I saw Actions as bridges between
the layers, converting between the Action Forms and Value Objects and
back again). The problem I hit was that I did not want to have to write
a bunch of conversion code (see below) to create my Value Object (since
it is immutable and, hence does not have the setValue(object) methods
that automatic JavaBean conversion utilities need):
MyValueObject val = new
MyValueObject(converter.convert(form.getValue(), typeOfConversion));
Where the above code would take the String value from an ActionForm,
convert it into the type needed, and pass it into the constructor for
the Value Object. Hit the same problem running back the other way (from
Value Objects to Action Forms).
OR are people making their value objects mutable and maybe having them
implement a read-only interface that the business and data layers use
when interacting with or returning the object?
OR are people passing in the ActionForm to the Value Object so that it
can extract what it needs (are you fronting it with an interface?)?
OR are people passing in a map of properties and their values to the
Value Object for it to pick and choose what it wants?
OR something else entirely...?
When you are going back from Value Object to Action Form, how are you
controlling the output format? I know that the Action needs to
understand the format of the data that it would expect to receive from a
submitted form... So, I am assuming that all formatting has to happen
before it gets to the custom tag (the only exception being when it is
writing data that will not come back through a form or query string). Is
this what people are doing?
The converter objects that Arron spoke about sound like one possible
solution to some of this... I was a bit unclear on what code was doing
what, though. From what I understand, are you saying that the
ActionServlet is configured to use these converters based on the
struts-config.xml file? And that it figures out what conversions to try
according to a method that is defined in an interface that your
ActionForms implement?
Could you describe how (from an object level) the data flows back in
forth?
For instance, does it work like this:
Container: Request comes in
|
ActionServlet: Get list of convertions to run from configured ActionForm
|
ActionServlet: Run converters
|
ActionServlet:
\
Conversion failed - send error messages back to user
\
Conversion worked - continue processing
|
... Then what happens?
Thanks for everyone's patience with such a long list of questions!
Allen
In Reference To:
----------------
From: Arron Bates
Subject: Re: General model question ?
Date: Tue, 27 Nov 2001 14:51:24 -0800
I didn't code it, but I have to use it. The chaps here did it
before I
hit the scene. But I have to say that it's quite elegant.
You won't find it in the code I've written for nesting
extension. I
didn't write this, so it's out of my hands to submit it (and I
think
that their client paid too much for it to give it away), but I
can
transfer some IP and wouldn't mind working on the actual
solution. But
back to the story...
1) yes.
2) yes, but the fine grained errors come from another validation
mechanism. Where a custom action was made from extending the
struts
action, and using an interface the the beans implement, fetch's
a series
of validation rules from the form to run through. This brings
the finer
grained business driven errors.
The Converters themselves however only throw one error per
object type.
What I'd like to see, and I think that it'd be easy to
implement, would
be that if a converter failed, that it register an error against
the
property key that threw it. Then you could write out the errors
properly
for each instance.
3) No. This would take an extra runtime mapping to say that n
inputs go
into the one converter. Not currently implemented, but I do
agree that
it would be some cool functionality. Best I've done is to have a
child
object that holds the three properties and returns the proper
Calendar
object when asked by the business logic.
The particular system that I work with is robust enough to get
the job
done, but I think that working in hind-sight would make it a
truly nice
solution.
Arron.
Paul Speed wrote:
>Admittedly, I haven't looked at your code... but can you please
>verify that it meets the following requirements:
>
>1) All form errors are displayed together. In other words, if
more
> than one field is bad, the user will see all bad fields
rather
> than having to correct them one at a time.
>
>2) The user sees the original data they input. In other words,
if
> the user enters "abc" into a dollar field, then the form
displaying
> the errors and allowing them to redo their input will also
display
> "abc".
>
>3) Data conversion and validation can be done on multiple
fields at
> once. One example is a set of date fields (month, day,
year) that
> together form a single Date object.
>
>I always find this topic interesting because I don't think the
right
>answer has really bubbled up yet. That's why I try to
understand
>the different approaches.
>
>>From my point of view, to meet the above requirements data
conversion
>and validation would have to be done on or within the entire
form
>bean. Since your code sounds like it does this before the data
ever
>gets to the form bean, I just wondered how you solved those
issues.
>
>-Paul
>
>Arron wrote:
>
>>People reading this thread should also look at the last few
in...
>>Re: Fwd: Re: Extensibility of struts...
>>It's touching the same topic.
>>
>>I think that the most important things is what was just
raised. The
>>marshaling of strings into more valid objects. One
implementation I'm
>>working with has altered the struts servlet to allow the
configuration
>>of Converter objects to be mapped to object types, so that you
can
>>specify classes that can handle this marshal on a specific
need in an
>>automatic process. e.g.: we use BigDecimal for all of our
dollar types
>>(financial app), and there's a converter set up to handle the
>>marshaling, and on the inside the model is perfectly fine. A
bad marshal
>>also results in an error, and is returned to the input view.
Quite neat.
>>
>>Not taking away from skill or intentions, you've all written
some sweet
>>stuff, but don't you think (this is more than likely just me.
I often
>>think too laterally and get the wrong point on things) that
relying on a
>>big property switcheroo from the form object to the data model
in the
>>action class is messy and almost defeating the point of struts
when it
>>handles everything automatically, excellently and
elegantly?...
>>
>>Struts' level of automagic management is something to be
beheld, but as
>>a group trying to maintain wads of yukky code that's
frizbee-ing data
>>from one object to another.
>>
>>It's like a Ken Done painting hanging on the wall of the
Sistine Chapel.
>>Nasty ugly little blemish.
>>
>>Arron.
>>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
