RE: Handling Date objects in ActionForm gracefully
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
RE: Handling Date objects in ActionForm gracefully
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
RE: Handling Date objects in ActionForm gracefully
Cool!
No offence, Mark. In part, it's my fault since English is not my native
tongue and sometimes the same word translated into other language
changes the connotation of a phrase. Sh*t happens! :)
I believe yours is a valid approach (in fact, was one of the options I
was considering for the project we're about to begin). In any case, I'd
appreciate if you or anybody else would share any other views / opinions
about this issue (s) -- or any other related...
Peace, and thanx again everybody.
Freddy.
-Mensaje original-
De: Mark Lowe [mailto:[EMAIL PROTECTED]
Enviado el: viernes, 26 de marzo de 2004 11:05
Para: Struts Users Mailing List
Asunto: Re: Handling Date objects in ActionForm gracefully
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
[OT] JTA, JDBC and data persistence
Hello everybody, An off-topic question (it's Friday, I hope you accept it!): I want to implement a Business Object Model on top of many DAOs. Those BOs will be - obviously - related to each other (mainly 1:n and m:n relationships). I must implement this in such way that, when - for example - deleting a BO that has 3 children associated (therefore, those must be deleted as well), it's is possible to do so atomically. That is, I need to be able to delimit the beginning and the end of the transaction that spans the delete operation on those 4 objects. I want this to be as transparent and elegant as possible. I believe the right choice for solving this is using JTA objects (that is XA objects) instead of plain JDBC. I've been reading the API and some papers regarding JTA; I have a fundamental doubt: Does JTA allows me to delimit (and perform) 2 independent, yet concurrent transactions??? For instance: 2 users that click the delete button at the same time (it's a web application). I haven't seen anything like a transaction ID or similar on any example I've examined. Is this issue transparent to me? Is JTA able, in any way, to differentiate the Transaction begun from each user's corresponding instance of the respective BO (the one they wanted to delete... i.e. the father, not its children)??? I'd appreciate any light you can shed on this matter. Thanks and regards, Freddy.
Templating
Scenario: Sort of a templating system, based on the usual design patterns: Template, Attribute-Value, etc... (don't remember the exact names, but I'm confident you all know what I mean) :-) There are different entities whose (type's) properties are stored as attributes that are grouped and related altogether by an entity type (the Template). Therefore, the name and number of properties may vary from entity type to entity type. In order to manage (paint, enter data, store, etc...) this model, I understand there is something in Struts called indexed properties. Is that what I need to implement the right solution? Are there any best practices to solve the typical issues associated to this paradigm (data flow and validation, mainly)? I've implemented this before; however, the first time I try to do on a Struts-based application. All suggestion are welcome. Cheers, Freddy.
RE: Refresh parent window on popup submit with old params to parent
I'd say: Popup submits info. Info ges processed. Popup gets reloaded. On popup reload, invoke refresh on parent, then close (in that exact order). Parent gets fresh info. There is only one race-condition with this approach: The background operations launched by the popup's submit action (I assume there will be some) must be completed before the refresh function is invoked on the parent window. One way to avoid this is to wait until vital operations are completed, then return (to the popup window). HTH. Freddy V.A. -Mensaje original- De: Gandle, Panchasheel [mailto:[EMAIL PROTECTED] Enviado el: jueves, 18 de marzo de 2004 14:49 Para: Struts Users Mailing List Asunto: Refresh parent window on popup submit with old params to parent This must have asked before but ... I popup a child window from a parent window. Popup window submits info, gets closed. Parent window gets refreshed. Whats the best way to refresh parent window, such that it gets the new info from child window and the parameters that were previously submitted for the parent window to appear. Thanks Panchasheel - 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]
RE: Hierarchical Lists
I'm envolved in a Project that will be basically lots of this stuff. This CSS approach seems nice one, but it doesn't look like feasible if the hierarchical structure is too complex and / or it's just too big (then we would have an awfully heavy page). Everytime I face the same problem, I come to the very same conclusion (100% server-side solution). I admit it: I haven't had the guts to take the risk with the client-side one. Anybody: something to share regarding these issues? Has somebody gone all-the-way with some scripting solution for a complex hierarchy? Cheers, Freddy. -Mensaje original- De: Scherger, Derek [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 17 de marzo de 2004 23:16 Para: 'Struts Users Mailing List' Asunto: RE: Hierarchical Lists You might use something like select id=parent-list.../select select id=child-1 style=display:none;.../select select id=child-2 style=display:none;.../select select id=child-3 style=display:none;.../select select id=child-4 style=display:none;.../select Then in the onchange event of the parent-list you can call a javascript function that would do list = document.getElementById(child) list.style.display=; // show list list.style.display=none; // hide list as required. You'll have to set the proper list to be visible when the page first loads and you'll have to keep track of which list is currently visible (in javascript) so that you can toggle it off and the next one on. This type of thing seems to be working pretty well for me at the moment, although I haven't done exactly this. Let mw know how it works out. Cheers, Derek -Original Message- From: Randy Dillon [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 2:46 PM To: Struts Users Mailing List Subject: RE: Hierarchical Lists Derek, That's an interesting concept. My CSS skills are pretty basic though. How could you use CSS to do it? Would it work if the first list was multi-select with many different possible combinations? :- -Original Message- :- From: Scherger, Derek [mailto:[EMAIL PROTECTED] :- Sent: Wednesday, March 17, 2004 3:32 PM :- To: 'Struts Users Mailing List' :- Subject: RE: Hierarchical Lists :- :- :- I've though of (but not done) the possibility of using css :- to hide and show :- different versions of the second select list rather than :- adding/removing :- elements with javascript. Not sure which would be a better :- way to go as they :- both will require some scripting. The css hide/show :- version's script is :- pertty trivial though. :- :- Cheers, :- Derek :- :- -Original Message- :- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] :- Sent: Wednesday, March 17, 2004 12:54 PM :- To: [EMAIL PROTECTED] :- Subject: RE: Hierarchical Lists :- :- :- Short of a reload, I believe only a JavaScript/DHTML :- function can provide :- this behavior. :- :- :- -Original Message- :- From: Randy Dillon [mailto:[EMAIL PROTECTED] :- Sent: Wednesday, March 17, 2004 2:48 PM :- To: Struts Users Mailing List :- Subject: Hierarchical Lists :- :- :- Say I have 2 (or more) lists that are part of a hierarchy, :- such that the :- first list is a category (say Food Groups) and the second :- list contains :- children of each of the first list's items (for this :- example, let's say Food :- Types). :- :- How do I get the second list to be filtered based on the :- selection in the :- first list? I know this can be done by reloading the page :- each time the :- selection is changed in the first list, but is there a way :- to do this :- without the page reload? :- :- To add more detail to the example: :- :- Food Groups Food Types :- --- -- :- MeatDairy Beef :- Chicken :- Milk :- Eggs :- FruitVeg Melons :- Apples :- Oranges :- Lettuce :- . . :- . . :- . . :- :- If MeatDairy is selected in the Food Groups list, can the :- second Food Types :- list be filtered to only the MeatDairy food types without :- a page reload? :- :- :- :- - :- 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]
