dev@jsftemplating.java.net

Re: JSFTemplating: Questions about backing beans and do I still use the faces-config.xml?

From: Ken Paulsen <Ken.Paulsen_at_Sun.COM>
Date: Fri, 29 Sep 2006 13:19:51 -0700

If you already have access to the data in a Bean, you can just access it
directly: #{beanKey.propertyKey}. You can make the bean available either
by using a managed bean and registering it in the desired scope
(standard JSF stuff). Or you can do it w/ a handler:

<!initPage
getYourBean(primaryKey="#{inputVal}" bean=>$attribute{beanKey});
/>

<staticText value="#{beanKey.propertyKey}" />

Your backend design should be as you'd like it to be.

Ken

Todd Patrick wrote:
> I need to fill in a blank.
>
> Your example:
>
> <staticText value="#{requestScope.stVal}"> <!beforeCreate
> setAttribute(key="stVal" value="Hello!"); /> </staticText>
>
> What if I want to get the value that is stored in an Oracle 10g database
> that is accessible in a bean or POJO?
>
> I'm drawing a blank on getting data from a database into a dynamic
> object?
>
> Thanks,
>
> --Todd
>
> -----Original Message-----
> From: Ken.Paulsen_at_Sun.COM [mailto:Ken.Paulsen_at_Sun.COM]
> Sent: Friday, September 29, 2006 3:05 PM
> To: dev_at_jsftemplating.dev.java.net
> Subject: Re: JSFTemplating: Questions about backing beans and do I still
> use the faces-config.xml?
>
>
>
> Todd Patrick wrote:
>
>> One thing I absolutely believe is a waste of space is how SJSC2 has
>> create four .java files per page.
>>
>>
> I agree! :)
>
>> There really no need to create a java file for an ApplicationBean,
>> Page, RequestBean and SessionBean. I assume I don't need my bean to
>> extend com.sun.rave.web.ui.appbase.AbstractPageBean, since the
>> appbase.jar is not a requirement.
>>
>>
> That is correct... there is no need to do this.
>
>> So how does the backend work?
>>
>>
> This is very flexible. You can do what Creator does (obviously you're
> not going to). You can follow most of the JSF book recommendations and
> use one or more "backing beans" -- similar to Creator although perhaps
> more organized. Or, you can create dynamic objects and use handlers for
> processing requests (my recommendation).
>
> To create objects on the fly, you can use handlers. There are 4 events
> that can help you do this:
>
> 1) beforeCreate -- This event is fired before the UIComponent in which
> it is defined is instantiated. Useful for executing code (such as
> accessing your data) before the UIComponent is created, you can then
> refer to that data when creating the UIComponent. Example:
>
> <staticText value="#{requestScope.stVal}"> <!beforeCreate
> setAttribute(key="stVal" value="Hello!"); /> </staticText>
>
> 2) afterCreate -- Same as above, except it happens after the UIComponent
> is created (after factory is called). The example above will still work
> because #{} expressions are deferred. However, if the example above was
> written using $attribute{stVal} it would work for beforeCreate, but not
> afterCreate. The following should *not* work w/ afterCreate:
>
> <staticText value="$attribute{stVal}">
> <!afterCreate
> setAttribute(key="stVal" value="This doesn't work, change to
> beforeCreate or #{} expression!"); /> </staticText>
>
> 3) beforeEncode -- This happens during rendering. Because rendering in
> JSFTemplating is *not* controlled by JSFTemplating (it allows the
> UIComponents to render themselves). This event is only possible w/
> JSFTemplating based components. Currently this requires you to add an
> <event> component to get it to work -- I will be hiding this
> implementation detail in the future. This event is particularly useful
> for changing things during rendering (not possible w/o JSFTemplating).
> The first example again should work.
>
> 4) initPage -- Very much like beforeCreate, however, this event gets
> invoked during creation *AND* during page refreshes (in the restore view
> phase). This allows you to restore transient data (like request
> attributes in the examples above). If you place a button on the examples
> above and click the button, you'll notice the data disappears (only if
> you used #{}, ${} expressions store the value on the UIComponent). If
> you don't want your data to disappear, use this event type and it will
> get restored each request. The disadvantage to this event is that it is
> *ONLY* available at the page level. This means you must place it outside
> all other tags. So it is not good for component-specific handlers:
>
> <!initPage
> setAttribute(key="stVal" value="Hello!"); /> <staticText
> value="#{requestScope.stVal}" />
>
>> May I just create a simple bean that is serializable and create a
>> manage bean reference in my faces-config.xml?
>>
>>
> Yes. This works just fine.
>
> Good luck!
>
> Ken
>
>> Thanks,
>>
>> --Todd
>>
>>