> Konstantin Ignatyev <kgignatyev <at> yahoo.com> writes:
Apologies for participating the tapestry-user list, but
those comments get publically cycled into google for 'JSF' too :-)
My comments are below:
> What can I say: JSF is horrible! Tapestry has a
> learning curve, but JSF one was horrifying. I bought
> Kito Manns book JSF in Action and it is mind blowing
> how cumbersome simple things are:
> JSF documentation is awkward and incomplete;
> Lets take parameters for example, simple thing a
> parametrized command link:
JSF works on the command pattern, so you set state as
instance variables on a model object and then be able
to call methods on it. When you talk about parameter
passing, then you are dealing with transient variables
that only exist in the invocation scope.
While this is now do-able with JSF 1.2 (in a different
way than Tapestry), having models retain parameter
information (as is implied) offers an opportunity that is
more attuned to view lifecycles within rich-ui applications
and state management.
>
> 2nd accessing parameters mind blowing IMO:
> from Kitos book examples:
>
> public void doIt(ActionEvent actionEvent) {
> String param = null;
> List children =
> actionEvent.getComponent().getChildren();
> for (int i = 0; i < children.size(); i++) {
> if (children.get(i) instanceof UIParameter) {
> UIParameter currentParam = (UIParameter)
> children.get(i);
> if (currentParam.getName().equals("param") &&
> currentParam.getValue() != null) {
> param = currentParam.getValue().toString();
> break;
> }
> }
> }
> FacesContext context =
> FacesContext.getCurrentInstance();
> String id =
> actionEvent.getComponent().getClientId(context);
> System.out.println("In doIt(), component id:
> "+id+", param: "+param);
> }
JSF 'forces' a greater degree of separation between the UI
components and your business logic for the reasons above :-)
I don't think it's worth getting caught up in trying to
accomplish things like that when really, JSF components
are meant to bind state to POJO beans. So let the parameter
component do whatever, but simply point it at #{searchResult.page}
and let JSF do the work for you. Again, it's a different concept
than maybe what's promoted with Tapestry. But you can't use the above
as an argument against JSF when actually it should be handled in
a completely different way.
>
> What the heck!? Is this friendly and convenient API?
>
> JSF Configuration file, just look at that:
>
> <managed-bean>
>
> <managed-bean-name>globalOptions</managed-bean-name>
>
>
<managed-bean-class>com.sourcelabs.demo.webapp.web.jsf.GlobalOptions
</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> <managed-property>
> <property-name>pageLayout</property-name>
> <value>classic</value>
> </managed-property>
> </managed-bean>
>
> Hey guys, have you ever heard about object
> orientation? It looks ridiculous, same way as object
> like
> Class Person{
> String personFirstName;
> String personLastName;
> String personAge;
> }
>
> Cmon JSF guys, get back to school -school year is
> about to begin!
What is that above example? JSF works with POJOs (see last comment) and while
JSF's managed bean XML markup is a little lengthy, you always have the option to
use Hivemind or Spring behind JSF or use all 3 together.
>
> PS: Hope I will have time this week and add
> documentation to my comparison and publish it.
Please don't. Or if you do, please run it by someone from the the JSF EG to
clarify any points. I think it would also put more leverage behind any
arguments you bring up.
-- Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
