Freddy. No, you misunderstood if you thought I was responding with any hostility whatsoever.

There is a general problem where input would be better validated in the web tier so it can be decoupled from the model. So times comparing two dates would be useful and so on. But i think its also try to say that using anything but strings for user input will lead to problems.

And my suggestion could well be incorrect, I was putting it out there to see what response it would provoke.

Cheers Mark

On 26 Mar 2004, at 10:51, Freddy Villalba Arias wrote:

Mark, didn't mean to be pedantic... just wanted to prevent everybody
from going through all the (obvious / basic / simple) details and just
go to the "important" stuff. Neither am I an MVC guru.

In any case, thanx everybody 4 your help.

Regards,
Freddy.


-----Mensaje original----- De: Mark Lowe [mailto:[EMAIL PROTECTED] Enviado el: viernes, 26 de marzo de 2004 10:24 Para: Struts Users Mailing List Asunto: Re: Handling Date objects in ActionForm gracefully

I think the way of going about converting is pretty open, either have
some conversion utils between the web tier and the model. I tend to do
it in the action and then when things get long or i need the code again
move it out into  a util class or like you're saying make my model util
classes deal with strings (this makes a lot of sense as then other
front ends can be plugged on).

Talk of MVC aside (after all MVC is a broader issue than the particular
pattern that struts is based on) why piss about dealing with all sorts
of errors and exceptions being thrown in the place where its hardest to
deal with them?

You can and people do use different types for form beans, but I just
don't see the point. Date comes up often and lets face it dates are
more user friendly as dropdown menus rather than free text, so
getDay() , getMonth() and getYear() IMO are a simpler way of going
about things. Then have methods in you model that create a date based
on that, or have a util class in the web tier as you can deal with
validating the three values. Perhaps even have a date that's in you
form bean but is set and got (passed participle of get) via string
flavors day, month and year.

Not sure if this works but I think the idea is valid (corrections
welcome).

public class SomeForm extends ActionForm {

private Calendar aDate = Calender.instance();

        public String getDay() {
                int d = aDate.get(Calendar. DAY_OF_MONTH);
                return Integer.toString(d);
        }

        public void setDay(String day) {
                aDate.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day));
        }
        ...
        protected Date getAdate() {
                return dDate.getTime();
        }
}

This way come checking and comparing values before can be done, before
passing anything up to you model. Many folk would say that this should
be done in the model, but i'd say situations where you need to check if
a user has entered a valid date (e.g. expire and from dates with a
credit card).

This functionality will want to be produced even if you change the
model , if you wanted to demo your web tier on its own (without a model
e.g acme ltd credit card form)  and therefore doing it ONLY in the
model would be limited.

Very much IMO and I'm not MVC guru, but that's my understanding.

On 26 Mar 2004, at 09:43, Freddy Villalba Arias wrote:

As someone with good experience in MVC-based applications but a newbie
to Struts, what I understand from this discussion is that the
"recommended" implementation would have to comply, at least, with this
"guidelines":

- The conversion code is encapsulated in a separate class (I suppose
one
"converter" class per each <String, Target Data Type> combination
required, right?).

- Passes all (String) parameters to a Business Object that
encapsulates
the use case (I mean, the logic) and, from within that BO, use the
corresponding converter classes for getting the "actual" data object
to
flow around (i.e. be eventually get-ed or set-ed from the DAOs/DTOs,
bla
bla bla...)

I'm I right here or am I missing any other IMPORTANT aspect(s)?

STILL, there is something I don't get: how would you implement /
encapsulate then the opposite direction for data conversion; in other
words:

- Convert from "original" data types towards String (another method in
the same converter class?)

- Map (set) some (non-String) data object into the corresponding
String
property on the form bean.

Thanks,
Freddy.

-----Mensaje original-----
De: Mark Lowe [mailto:[EMAIL PROTECTED]
Enviado el: viernes, 26 de marzo de 2004 0:59
Para: Sreenivasa Chadalavada; Struts Users Mailing List
Asunto: Re: Handling Date objects in ActionForm gracefully

You deal with the conversion else where but not in the form bean, you
can argue about it or just believe me. The action form sits between
the

view and the action, the date conversion goes on between the action
and

the model.


Your approach isn't that bad its just not to the MVC pattern that
struts follows (not that its the only one).

Create a date convertion util class or something.

If you dont want to take my word for it here's what craig had to say
albeit in response to a different question

<snippet>
As the original designer of Struts :-), I must point out that the
design of
ActionForm (and the recommendation that form bean properties be
Strings) is
***very*** deliberate.  The reason this is needed is obvious when you
consider
the following use case:

* You have an input form that, say, accepts only integers.

* Your form bean property is of type "int".

* The user types "1b3" instead of "123", by accident.

* Based on experience with any garden variety GUI application,
   the user will expect that they receive an error message,
   plus a redisplay of the form ***WITH THE INCORRECT VALUES
   THAT WERE ENTERED DISPLAYED SO THE USER CAN CORRECT THEM***.

* The current Struts environment will throw an exception
   due to the conversion failure.

* The suggested solution will ***hopelessly*** confuse the
   nature of a form bean, which is part of the VIEW tier, with
   model beans that have native data types.

Struts does not include any sort of "user interface component model"
where the
details of conversion are hidden inside the user interface component.
If that
is what you are after, you should look at a *real* user interface
component
model (such as using JavaServer Faces with a Struts application).
Corrupting
the functionality of a form bean to *pretend* that it is a user
interface
component is only going to create complications for the world.
</snippet>

I hope this helps

Mark

On 25 Mar 2004, at 21:26, Sreenivasa Chadalavada wrote:


Application Tier is strongly typed.


So if the field is a java.util.Date in the database, then the data
object will have the method

public DataObject{
        public java.util.Date getAsOfDate()
        public void setAsOfDate(java.util.Date asOfDate) methods.
}

My Action form is:

public MyActionForm extends ActionForm{
        public DataObject getDataObject();
        public void setDataObject(DataObject dataObject);
}

My jsp contains

<html:text property="dataObject.asOfDate"/>

This will fail if the user does not enter any date. I want the
(changed) struts framework to handle that.

I did not want to create a new method with type String for every Date

field

Hope this explanation helps !!

Thanks and Regards,
 Sree/-





-----------------------------------------------------------------------
-----------------
 This is a PRIVATE message. If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the
mistake in delivery. NOTE: Regardless of content, this e-mail shall
not operate to bind CSC to any order or other contract unless
pursuant

to explicit written agreement or government initiative expressly
permitting the use of e-mail for such purpose.



-----------------------------------------------------------------------
-----------------





Mark Lowe <mark.lowe
 @boxstuff.com>

03/25/2004 03:17 PM
Please respond to "Struts Users Mailing List"

       
        To:        "Struts Users Mailing List"
<[EMAIL PROTECTED]>
        cc:        
        Subject:        Re: Handling Date objects in ActionForm
gracefully



Ask yourself why are you trying to convert types for user input?

On 25 Mar 2004, at 21:11, Sreenivasa Chadalavada wrote:

Do you know if the behavior can be overridden?

Thanks and Regards,
Sree/-





-----------------------------------------------------------------------
-----------------
This is a PRIVATE message. If you are not the intended recipient,  
please
delete without copying and kindly advise us by e-mail of the
mistake in
delivery. NOTE: Regardless of content, this e-mail shall not
operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the

 
use of
e-mail for such purpose.



-----------------------------------------------------------------------
-----------------





"Takhar, Sandeep" <Sandeep.Takhar
@CIBC.ca>
03/25/2004 02:53 PM
Please respond to "Struts Users Mailing List"


        To:     "Struts Users Mailing List"   <[EMAIL PROTECTED]>         cc:         Subject:        RE: Handling Date objects in ActionForm   gracefully


yes it is.  It should be done once per classloader.


When struts populates the dyna form it is string array to string
array
conversion and uses
populate method of BeanUtils which eventually calls the converters.

sandeep

-----Original Message-----
From: Sreenivasa Chadalavada [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 2:47 PM
To: Struts Users Mailing List
Subject: Re: Handling Date objects in ActionForm gracefully


I am thinking of overriding the struts default mechanism. Override the default behavior of   org.apache.commons.beanutils.ConvertUtils

by registering
a valid converter...

I want to know if the above is possible..

Thanks and Regards,
Sree/-





-----------------------------------------------------------------------
-----------------
This is a PRIVATE message. If you are not the intended recipient,  
please
delete without copying and kindly advise us by e-mail of the
mistake in
delivery. NOTE: Regardless of content, this e-mail shall not
operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the

 
use of

e-mail for such purpose.



-----------------------------------------------------------------------
-----------------





Mark Lowe <mark.lowe
@boxstuff.com>
03/25/2004 02:36 PM
Please respond to "Struts Users Mailing List"


        To:     "Struts Users Mailing List" <[EMAIL PROTECTED]>         cc:         Subject:        Re: Handling Date objects in ActionForm   gracefully


Have it as a string and convert it to a date or calendar when you
pass
it back to the model.


On 25 Mar 2004, at 20:28, Sreenivasa Chadalavada wrote:


All,

We are facing a problem when we define java.util.Date field in
ActionForm.

Is there any way to override the default behavior provided by
Struts?

I very much appreciate your help!!


Thanks and Regards,
Sree/-




----------------------------------------------------------------------
-
-----------------
This is a PRIVATE message. If you are not the intended recipient,
please
delete without copying and kindly advise us by e-mail of the
mistake  
in
delivery. NOTE: Regardless of content, this e-mail shall not
operate  
to
bind CSC to any order or other contract unless pursuant to
explicit
written agreement or government initiative expressly permitting
the
use of
e-mail for such purpose.


----------------------------------------------------------------------
-
-----------------



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





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






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





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


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



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


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



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



Reply via email to