struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <maili...@matthias-wessendorf.de>
Subject RE: Theoretical debate
Date Fri, 09 Jul 2004 07:30:04 GMT
> JSF takes care of conversion 
> problems, and redisplay in case of conversion errors, for you.

indeed, converters are a BIG-plus in JSF
the DateTimeConverter allows you to use
java.util.Date in a BackingBean.

<h:inputText ... value="#bean.date">
  <f:convertDateTime pattern="MM/dd/yyyy"/>
</h:inputText>

enter in textfield: 12/06/2004
and java.util.Date got created...

on the other side the output, i case of
presenting a date

<h:outputText ... value="#bean.date">
  <f:convertDateTime pattern="MM/dd/yyyy"/>
</h:ouputText>

so you got your date like '12/06/2004' instead of
java.util.Date@3242343 ;-)


btw. you can create your own converters

e.g for a telephone-nr class 

Telephone
-country
-city
-yournummer

give that converter a delimiter and some logic, on what digit is what

<h:inputText ... value="#{bean.tele}">
  <x:teleConverter delim="."/>
</h:inputText>
so you might enter '+1.410.803.2258'
and your Telephone-Object is created...
same for output...

btw. if your converter has attributes,
keep in mind, that you need to implement stateholder-Interface...


okay... before i turn too much offtopic...


regards
Matthias


> As a trivial example, assume you have a bean "mybean" that has an 
> input/output int property named "mycount" that you want to 
> render in a 
> JSF-based JSP page.  It is trivially simple:
> 
>   <h:inputText ... value="#{mybean.count}"/>
> 
> works fine.  The String->int and int->String conversions 
> (including any 
> errors that occur) are handled totally by JSF.  Your business 
> logic can 
> assume that, if was invoked, there were no conversion or 
> validation errors.
> 
> Craig
> 
> 
> 
> >--- Craig McClanahan <craigmcc@apache.org> wrote:
> >  
> >
> >>Hookom, Jacob wrote:
> >>
> >>    
> >>
> >>>Look at JSF, do you have actions? No, JSF just updates your POJO 
> >>>beans and calls methods on them.  Why have an ActionForm 
> or have to 
> >>>create all of these Actions that are simply getter/setter 
> adapters?  
> >>>Please don't be too quick to retort to my supposed anti-struts 
> >>>mindset, but there are other frameworks out there that 
> allow direct 
> >>>interaction with my business objects and don't require a heck of a 
> >>>lot of framework specific coding.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>(Coming into this discussion late, but figured that my experience on
> >>both the Struts and JSF side of things might provide some 
> illuminating 
> >>food for thought :-)
> >>
> >>It's instructive, first, to go back to the beginning of Struts
> >>development (just over four years ago), and recall why an 
> ActionForm 
> >>exists in the first place.  The only reason we created that 
> abstraction 
> >>was to deal with some pesky real world problems in 
> designing webapps ... 
> >>primarily dealing with conversion (where we really punted ... see 
> >>below), validation, and little things like maintaining the state of 
> >>checkboxes.  Because Struts doesn't have any "user 
> interface component" 
> >>concept, dealing with those things had to go somewhere -- 
> and a common 
> >>abstraction at least made it easy to understand.
> >>
> >>Therefore, the recommended design pattern for a Struts based app 
> >>becomes:
> >>
> >>- An ActionForm per input <form>, normally with
> >>  String-based properties (so you can redisplay
> >>  invalid input the way users expect you to).
> >>
> >>- A set of validation rules that are applied for you
> >>  on the server side, and optionally also on the
> >>  client side.
> >>
> >>- If a validation error occurs, Struts takes care
> >>  of redisplaying the page (with error messages)
> >>
> >>- If validation succeeds,  the application Action
> >>  is responsibe for performing conversions of the
> >>  String valued things in the ActionForm to match
> >>  the underlying model data types, typically by
> >>  copying them in to DTO/VO type objects and
> >>  passing them to business logic (although, as others
> >>  have pointed out, lots of Struts developers have
> >>  skipped this extra layer).
> >>
> >>With JSF, the component model takes care of all the responsibilities
> >>that Struts uses an ActionForm for, so you don't need one 
> any more.  
> >>Indeed, I anticipate people will choose one or more (they aren't 
> >>mutually exclusive) of at least three different styles for building 
> >>JSF-based webapps:
> >>
> >>(1) You can bind individual *components* to backing bean properties,
> >>     similar to how ASP.Net "code behind files" work.  This will
> >>     be most comfortable to VB developers, and is useful when
> >>     you need to programmatically modify component properties.
> >>
> >>(2) You can bind component *values* directly to properties in your
> >>     backing bean, and then provide the business logic as 
> action methods
> >>     in the same class.  Because the components take care 
> of conversion,
> >>     you're free to use model-oriented data types for such 
> properties,
> >>     so you don't need to worry about explicit conversion any more.
> >>     This style will appear to Struts developers like a 
> combination of an
> >>     Action and an ActionForm in the same class, and will 
> also appeal to
> >>     the crowd that likes O-O encapsulation :-).
> >>
> >>(3) You can bind component *values* directly to properties 
> on a VO/DTO
> >>     object, and bind action events to methods on a 
> separate bean that will
> >>     either perform the logic directly or delegate to a 
> business logic
> >>class.
> >>     This style will feel more like traditional Struts separated 
> >>ActionForm and
> >>     Action classes, but the Action won't have as much to 
> do.  It's also 
> >>a great
> >>     way to build a webapp on top of existing application 
> infrastructure 
> >>that
> >>     provides resuabe VO/DTO and business logic classes already.
> >>
> >>I believe that all three approaches are valid -- which one you take 
> >>for
> >>a particular application function depends on your use case for that 
> >>function.  You don't have to be exclusive, either.  Combine 
> them where 
> >>it makes sense.
> >>
> >>Craig McClanahan
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>    
> >>
> >
> >
> >		
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! Mail - 50x more storage than other providers! 
> >http://promotions.yahoo.com/new_mail
> >
> >---------------------------------------------------------------------
> >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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message