Actually here is the state of our current works on the component set:
I have dojo covered currently in mine which still is undecided what to
do with it by about 80% on the dijit side. The big points missing in my
own one is the table and the tree. For the tree I have gathered the
knowledge to auto ajax it. Trinidad PPR is supported out of the box!
But I am currently on JSF 1.1 api and want to keep it that way until I
really find time to upgrade it.
My current biggest problem is lack of time, since I have to work 80% of
the time in non myfaces related projects and the other 10-20% is
reserved for myfaces 2.0
Ganesh as far as I know has a pretty well working tag set which coveres
dojo even more than I do, he has the table and tree already working,
main difference is he is already on facelet while I tackle the problem
on the component side.
We could use the work of Ganesh as a starting point for a more extensive
component facelets set, but we have to move Ganeshs work in one way or
the other because it is already hosted outside on sourceforge AFAIR!
Outside of that there is the ominous rich client component set which
Oracle wanted to opensource one day, Matthias knows more about it.
That is the state of sets I am aware of we probably could use within the
myfaces umbrella!
Werner
Matthias Wessendorf schrieb:
On Wed, May 27, 2009 at 10:57 AM, Ganesh <[email protected]> wrote:
Hi,
yes, sure, declarative languages have more limitations then procedural ones
and sometimes we must swich to the procedural backup and again yes I think
it it is worth working on "something like that".
IMHO we should first of all discuss the basis we want to work upon. Which
are your reasons to prefer starting with jQuery instead of dojo? Here's my
list of reasons why I chose dojo:
I personally like the jQuery syntax and it has not that big
(dependency) overhead.
That said I don't mind to have multiple libs supported, under such a
"umbrella" Facelets-
based library "MyFaces FOO Dojo", "MyFaces FOO jQuery" ...
-M
- better industry support
- larger widget base
- more of a hype right now (seems to me ...)
Best regards,
Ganesh
Matthias Wessendorf schrieb:
not sure I read that article, but I agree that it is worth to go the
Facelets road, for new things.
Not sure if EVERY 2.0 library needs to contain only template-based
components; old-fashion
renderers are still, ok...
so generally you also think it is worth to host something like that ?
I personally would like to start with this by introducing a wrapper for
jQuery (included via JSF 2.0 resource handling)
-M
On Wed, May 27, 2009 at 10:27 AM, Ganesh <[email protected]> wrote:
Hi Matthias,
Funny you're asking this today: Last night I've released the J4Fry
dojoFacelets library on sourceforge. It's a pure JSF template/dojo
library,
it was build on JSF 1.1/1.2 w/Facelets and it runs on JSF 2.0 out of the
box. The templates are AJAX enabled via ui:define. The first project
based
on the new components will be productive around juli in a european bank.
We've started working on this last autumn after I released this artivle
in
german JavaMagazin, making the point that future JSF tag libraries must
be
template based:
http://www.j4fry.org/resources/jung_JSF_JavaMagazin_Tag_Entwicklung_mit_Facelets.pdf.
The dojoFacelets are apache licensed and we would love to make them a
starting point for a new MyFaces subproject.
Here's a link to the documentation: http://j4fry.org/dojoFacelets.shtml
(with links to examples and downloads - the JSF 2.0 example is currently
offline, check the JSF 1.2 example).
Best regards,
Ganesh
Matthias Wessendorf schrieb:
Hi,
sure MyFaces 2.0 is not yet there, but I want to share an idea...
Since JSF 2.0 has the new Facelets support to easily create (custom)
components,
would it be a good idea to start a new (sandbox) project that defines
a JSF 2.0 set
of components, only written via the Facelets way ?
I had to play with some fancy JS (jQuery) to make a "wow" *easy*
component (via Facelets).
I think it would be cool to have such a library that provides a kinda
wrapper for some JS lib,
e.g. jQuery.
-Matthias
