Ken:
The thing is I am stuck on Tomcat 5.0.28 for the foreseeable future.
Glassfish is not in the roadmap and I'm wondering how this is going
affect my project.
I need to look closer into apt.
I greatly appreciate the examples and references, will keep moving
forward.
Thanks,
--Todd
-----Original Message-----
From: Ken.Paulsen_at_Sun.COM [mailto:Ken.Paulsen_at_Sun.COM]
Sent: Friday, September 29, 2006 4:10 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:
> My last post of the day... It's Friday. :)
>
> I want to make sure I go into the weekend understanding this.
>
> 1.) I don't see initPage information on the info.jsf output?
>
It's an event type... the events are not well documented anywhere. You
can look at the JavaDoc:
https://jsftemplating.dev.java.net/nonav/javadoc/com/sun/jsftemplating/l
ayout/event/package-summary.html
All events can use any handler (that makes sense) and are declared using
"<![eventType] ... />". The ... are the handlers. The [eventType] in
this case is "initPage":
<!initPage
someHandler(
param1="whatever",
param2='whatever'
output1=>$attribute{requestAttKey}
output2=>$session{sessionKey}
output3=>$page{pageSessionKey});
anotherHandler(...);
...
/>
You can see a bunch of .jsf examples looking at:
http://fisheye5.cenqua.com/browse/glassfish/admin-gui/admin-jsf/src/docr
oot
And handler examples:
http://fisheye5.cenqua.com/browse/glassfish/admin-gui/admin-jsf/src/java
/com/sun/enterprise/tools/admingui/handlers
This source code is from GlassFish and you may want to check it out to
browse through it more easily.
> 2.) Is getYourBean based on the following:
>
> getId
> com.sun.jsftemplating.handlers.UtilHandlers.getId
> INPUT> object(required) class java.lang.Object
>
> OUTPUT> clientId class java.lang.String
>
> OUTPUT> id class java.lang.String
>
> I have a backing bean such as:
>
> public class TransactionBean implements Serializable {
>
> Thus, would I write:
>
> <!initPage
> getTransactionBean...
> />
>
>
> So what would be the method parameters in "primaryKey="#{inputVal}"
> bean=>$attribute{beanKey}"?
>
> OR
>
> Am I writing:
>
> <!initPage
> getYourBean(primaryKey="#{TransactionBean}"
> bean=>$attribute{"transaction"});
> />
>
>
> "getYourBean" is not listed as a handler?
>
Actually "getYourBean" was meant to be a custom "handler". This would be
Java code that you write that gets executed during the "initPage" event.
For example:
/**
* This method retrieves your bean...
*/
@Handler(id="getYourBean",
input={
@HandlerInput(name="primaryKey", type=String.class, required=true) },
output={ @HandlerOutput(name="bean", type=org.whatever.YourBean.class)
})
public static void getOracleBean(HandlerContext handlerCtx) { // Type
conversion will happen automatically to give you a String if it isn't
already String key = (String) handlerCtx.getInputValue("primaryKey");
// Your bus. logic to get your bean:
YourBean bean = yourMethodToGetBean(key);
handlerCtx.setOutputValue("bean", bean); }
The above code is how you define a handler. It requires Java SE 5 and
"apt" to compile. See how this is done in either the GlassFish source
above, or the JSFTemplating source itself. One thing to be aware of is
that you must build all handlers at once... the apt compiler generates a
".map" file that describes the Handlers, it will overwrite this file if
you do incremental builds.
Good luck!
Ken
> Thanks,
>
> --Todd
>
> ________________________________
>
> From: Ken.Paulsen_at_Sun.COM [mailto:Ken.Paulsen_at_Sun.COM]
> Sent: Friday, September 29, 2006 3:20 PM
> To: dev_at_jsftemplating.dev.java.net
> Subject: Re: JSFTemplating: Questions about backing beans and do I
> still use the faces-config.xml?
>
>
>
> 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
>
>
>