Karam Singh Badesha wrote:
> 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.
>
Yes, I can. Can I do this early next week? Perhaps Monday?
> 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.
>
You may have to use a proxy. Or, if you can ping 64.125.133.206, you
might get it to work by the following to your "hosts" file adding:
cvs.dev.java.net 64.125.133.206
I think you can find out more information about this at appserver.sfbay.
Ken
> 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
>>>