sorry for asking this only now... but is the JSF component lib dependent on facelets ?
would it be hard to remove the dependency on facelets ?
i'm not yet sure about the adoption of facelets. since it is the intention of the components that they are embedded into user applications, it should be usable in as many environments as possible.
it's not a hard requirement, but if it is just a matter of extra work, i think that extra work would be justified.
what do you think ?
i think i already know the answer...
you first build a plain JSP tag library and then you made that one available inside of facelets, right ?
that would be the right approach. cause then people without facelets can still use the plain JSP tags.
Nope, it's 100% Facelets. From what I've seen from IRC, just about anyone who is starting a new application is choosing Facelets over JSP. Adding JSP support is very possible for this taglib though.
I agree with David. Anyone doing jsf without facelets is either stupid, does not know how to use goodgle or has some kind of fetish.
Facelets is the way to go, atleast until the new jsp spec is final and implemented
I agree with David. Anyone doing jsf without facelets is either stupid, does not know how to use google or has some kind of fetish.
Well I didn't really mean to imply that anyone is stupid. But I do think Facelets is much more popular these days than JSP.
sorry, those are indeed MY words :-)
Anyone doing jsf without facelets is either stupid, does not know how to use goodgle or has some kind of fetish.
deciding which technologies we think are good and which we should use is a completely different discussion then what technologies are we going to support.
there are tons of situations where developers don't really have a choice and *have* to use plain servlet/JSP tech. apart from that, i'm quite sure there are a lot of devs like the ones you describe, too :-)
how much effort would it take to have plain tag libraries build on plain servlet tech and that can be used in the jbpm4jsf ui components ?
one conclusion that we could take out of this is that the jbpm4jsf library should be small and focus on the key components first. then get the tech right together with the integration into the new console. then when all is settled, we can think about expanding the functionalities of the library.
if we make the lib and functionalities to broad and deep, we can't make any such refactoring decisions like the one we are discusing here without a huge effort.
If people HAVE to use jsp but ARE ALLOWED to start with JSF, they (or their architects) are stupid. Sorry to restate that, but try building complex pages with plains jsp and jsf. unreadable code, rendering issues etc..etc..etc..
afaik, if you have a jsf taglib, that can be used with jsp and have to do some additional things to get it to work with facelets, so we should be fine here
Well, just to clear things up - I have implemented this tag library as a set of action classes (implementing ActionListener, which is a basic JSF interface), and a set of Facelets tag handlers to attach the action listeners to the enclosing component.
So all that is needed for JSP support is to implement a JSP Tag class corresponding to each of the Facelets TagHandler classes.
I don't think it would be all that much work, but I want to get the Facelets tags working first.
great. in that case we can even wait and see if there is real demand for it before we start investing more time in it.