Are you already using Java 5? You probably are b/c I think you'd have
run into problems already if you were still using Java 1.4 w/ the
published JSFTemplating .jar files (they're compiled with 1.5).
So I don't think you'll have any problem w/ Tomcat 5.0.28. Let me know
if you do!
Thanks,
Ken
Todd Patrick wrote:
> 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
>>
>>
>>
>>