Thanks Ken. I don't really want to go the beans route for every small
thing as it requires more code . I would definately like to stick with
what JSFtemplating has to offer in this area. Is there any way we can
get another demo on this approach and a bit more on using dynafaces for
AJAX. Please let me know if that is possible as it would really help. We
don't need slides, some hands on and examples will do. If we can get
someone from Glassfish/admingui team to do this, that is fine as well.
Also, from inside sun how do I download the source for
admin-gui/admin-jsf. I tried but the I can't reach the external host.
thanks,
Karam
Ken Paulsen wrote On 01/16/07 20:59,:
> Hi Karam,
>
> Best practices is a good topic that probably has different opinions
> depending on who you ask. :) I'll give you some of my thoughts.
>
> See below.
>
> Karam Singh Badesha wrote:
>
>>Hi,
>>Because we are just starting our project using woodstock and
>>jsftemplating, it would be great if someone could provide some best
>>practices. This will really help us stay on the right track. Some of
>>points that I am interested in are:
>>- using jsftemplating what would I do different compared to what I
>>would have to do using woodstock alone (other than the difference in
>>tag name).
>
> You don't need to do anything different. You may follow traditional JSF
> design patterns which tend to center around creating a bunch of Mananged
> Beans and spending a large percentage of your time managing them. :)
>
> JSFTemplating offers the ability to take a more "event / handler" driven
> approach. This allows you to execute code in response to different
> "events" (time periods or user actions). This allows for better code
> reuse and more intuitive code, IMHO. This approach generally centers
> around defining a set of "handlers" (custom java methods that take
> input, do something, and produce output), and declaring them during events.
>
>>- beans usage in jsftemplating
>
> There are times when beans are the best approach. For example, you may
> already have bean objects provided by your backend, or a custom JSF
> component requires you use a bean (i.e. sun:helpWindow). So use managed
> beans (or unmanaged beans) whenever you feel it adds value.
>
> In my experience, creating a Java class just to hold values is usually
> just extra work. Instead, take a look at where your data is coming
> from... try not to change it. Put it in request scope, or in a general
> object that is in request scope (i.e. a Map, or some generic bean).
> Bind your values to that instead. You can do this during a
> <!beforeCreate> event, or in some cases <!beforeEncode>... or in cases
> like you suggested before where the value isn't known until the user
> makes a selection in a <!command> event. This provides better control,
> less data shuffling, and less configuration (no need to manage the data
> in the faces-config.xml, or to create many separate "bean" classes).
>
>>- pointers to some real examples of jsftemplating with woodstock
>>components.
>
> GlassFish is the best example I know of:
>
>
> http://fisheye5.cenqua.com/browse/glassfish/admin-gui/admin-jsf/src/docroot
>
> You may want to follow the instructions on the GlassFish web site
> (https://glassfish.dev.java.net) to checkout the "admin-gui/admin-jsf"
> source code.
>
> I hope this helps!
>
> Ken Paulsen
>
>
>>thanks
>>Karam