> 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
[EMAIL PROTECTED] ;-)
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! Mail - 50x more storage than other providers!
> >http://promotions.yahoo.com/new_mail
> >
> >---------------------------------------------------------------------
> >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]
