Jörn Zaefferer schrieb:
Okay, maybe velocity isn't the right tool as a viewhandler, but how
about a renderer? The renderer only renders HTML, no need to worry about
templating or building a component tree.
I personally would go along the way of having velocity as the renderer
instead of the
Another thing I noticed: The ResponseWriter provides method for writing HTML
markup, but requires that nearly every call passes a component or
propertyname. In almost all cases those are completely unnecessary and not
even used anywhere.
I've written my own wrapper to skip all those additionals
Adrian Mitev schrieb:
I've posted RFE for jsf 2.0 [1] about api for component development.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246
Hi Adrian I think this does not go too far
Hi, Werner! You could post that as comment to my issue at
javaserverfaces-spec
2007/3/16, Werner Punz [EMAIL PROTECTED]:
Adrian Mitev schrieb:
I've posted RFE for jsf 2.0 [1] about api for component development.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246
For renderer templating engine - probably the Exadel guys will contribute
their engine to jsf 2.0.
2007/3/16, Werner Punz [EMAIL PROTECTED]:
Adrian Mitev schrieb:
I've posted RFE for jsf 2.0 [1] about api for component development.
I will this evening.
This has been a major gripe of mine for years now.
(Matthias probably also currently curses a lot on those issue)
It is in my opinion the biggest problem to get people into jsf and
also the biggest problem to find people willing to put time into
component development.
Adrian Mitev schrieb:
For renderer templating engine - probably the Exadel guys will
contribute their engine to jsf 2.0.
here is one reason why I would love to see velocity (anyway I am sure it
wont make it (I know the sun guys want a clear cut and as few logic as
possible in the templating,
I'm not familiar with Velocity, therefore I'd like to know how velocity
handles logic in its views. JSF in general does a good job avoiding any
classic if/else and loop constructs in my views. Can I get that with
Velocity, too?
On 3/16/07, Werner Punz [EMAIL PROTECTED] wrote:
Adrian Mitev
I like the approach of renderers written in velocity. Sounds like a logical
approach to me: Take a language with enough power that was written for
exactly the thing you need to do.
Fortunately JSF is quite flexible when it comes to exchanging certain
components like view handlers. Have you done
Velocity is a fine tool -- I use it all over the place.
Because of my experience with Velocity, I've looked into the attempts
to use it as viewhandler. It's not an ideal fit.Facelets does a
much better job. Velocity is not the right tool for the job.
Okay, maybe velocity isn't the right tool as a viewhandler, but how about a
renderer? The renderer only renders HTML, no need to worry about templating
or building a component tree.
On 3/16/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Velocity is a fine tool -- I use it all over the place.
Mike, Jeff;
For a Tomahawk², which should cover JSF 1.2 efforts of Tomahawk (and a
clean up?) I'd like to see the Trinidad stuff used.
-M
On 3/14/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Yeah I'm really hopeful that the code generation stuff from Trinidad, as
well as all the effort in that
Jeff Bischoff schrieb:
I agree, it would be great if that were part of the distro. Problem is,
Facelets still isn't officially supported by Tomahawk, and thus
developers don't have to ensure their components will work in Facelets,
let alone provide the configuration and handler classes. Seems
Matthias Wessendorf schrieb:
Mike, Jeff;
For a Tomahawk², which should cover JSF 1.2 efforts of Tomahawk (and a
clean up?) I'd like to see the Trinidad stuff used.
Which reminds me, please guys, write a proper documentation for the
Trinidad codegen, I once wanted to use it, and ended up
Absolutely! The JSF API itself isn't enough to write components without
duplicating tons of code. You either do duplication, or depend on a
particular implementation of the API.
And this isn't just a problem with JSF alone. I wanted to replace the
default month renderer on tomahawks schedule
I've posted RFE for jsf 2.0 [1] about api for component development.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246
2007/3/15, Jörn Zaefferer [EMAIL PROTECTED]:
Absolutely! The JSF API itself isn't enough to write components without
duplicating tons of code. You
Good idea!
regards,
Martin
On 3/16/07, Adrian Mitev [EMAIL PROTECTED] wrote:
I've posted RFE for jsf 2.0 [1] about api for component development.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246
2007/3/15, Jörn Zaefferer [EMAIL PROTECTED]:
Absolutely! The JSF API
Hi,
on the dev-list there is an actual discussion about the release. It
should hopefully occur within the next 2 weeks.
cheers,
Gerald
On 3/13/07, GUILLEMOT Simon [EMAIL PROTECTED] wrote:
I'm also interested to known when the next release is planned.
More next month or more next week :)
Good to know that a released is coming soon.
Any idea if it is planned to include the tomahawk-facelets-taglib.xml in the
release?
On 3/14/07, Gerald Müllan [EMAIL PROTECTED] wrote:
Hi,
on the dev-list there is an actual discussion about the release. It
should hopefully occur within the next
When I say update the Wiki here, I am specifically talking about the
taglib.xml mantained there.
Jeff Bischoff wrote:
Jörn,
AFAIK, no. I'm not a committer, but I do monitor the dev list pretty
closely.
I do, however, plan to help update the Wiki to make sure it is
up-to-date with the new
Ok, good to know someone is working on that. Still, it seems like a good
idea to stuff that into the official release, forcing every commiter to
provide the necessary descriptions or even custom tag handlers. In most
cases, its only three or four lines of xml, nothing compared to the
tld-effort.
I agree, it would be great if that were part of the distro. Problem is,
Facelets still isn't officially supported by Tomahawk, and thus
developers don't have to ensure their components will work in Facelets,
let alone provide the configuration and handler classes. Seems like a
huge number of
Jörn,
AFAIK, no. I'm not a committer, but I do monitor the dev list pretty
closely.
I do, however, plan to help update the Wiki to make sure it is
up-to-date with the new components, following the release. Any help is
welcome and appreciated! :)
Regards,
Jeff Bischoff
Kenneth L Kurz
I know that one of the biggest hold-ups for me is that I don't know
enough about Maven to set up a tomahawk-facelets module for dealing
with it.
The second issue is getting a form of code generation up and running
to handle all of the configuration files. This might be in place by
this point,
Yeah I'm really hopeful that the code generation stuff from Trinidad, as
well as all the effort in that area going on in the 1.2 branch, will be
a big boon to the future facelets support.
Mike Kienenberger wrote:
I know that one of the biggest hold-ups for me is that I don't know
enough about
I'm also interested to known when the next release is planned.
More next month or more next week :)
Thx,
-Message d'origine-
De : Ronald Johnson [mailto:[EMAIL PROTECTED]
Envoyé : mardi 13 mars 2007 10:26
À : users@myfaces.apache.org
Objet : Tomahawk release plans?
Hi,
I could not
26 matches
Mail list logo
