You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Ronald Johnson <rj...@googlemail.com> on 2007/03/13 10:25:53 UTC
Tomahawk release plans?
Hi,
I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
When will these be released?
cheers
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 nulls:
public class ResponseWriterWrapper {
private ResponseWriter original;
public ResponseWriterWrapper(ResponseWriter toWrap) {
this.original = toWrap;
}
public void startElement(String name) throws IOException {
original.startElement(name, null);
}
public void writeAttribute(String name, String value) throws IOException
{
original.writeAttribute(name, value, null);
}
public void endElement(String name) throws IOException {
original.endElement(name);
}
public void writeText(String string) throws IOException {
original.writeText(string, null);
}
}
On 3/16/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Good idea!
>
> regards,
>
> Martin
>
> On 3/16/07, Adrian Mitev <ad...@googlemail.com> 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 <jo...@googlemail.com>:
> > > 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 component. I've now ended
> by
> > extending Renderer directly, I can't even reuse a single line of the
> > AbstractWhateverScheduleRenderers. Instead I have to
> > duplicate parts of them in my own renderer.
> > >
> > > About the three classes: When I want to quickly create my own
> component
> > for handle a particular problem, I need only the component class itself
> and
> > my facelets taglib. The component can do the rendering.
> > >
> > > Once I'd have those components ready to publish to a greater audience
> I
> > wouldn't mind writing renderer and tag classes.
> > >
> > >
> > > On 3/15/07, Werner Punz <we...@gmail.com> wrote:
> > > > 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
> like a
> > > > > huge number of the userbase is already using or migrating to
> Facelets,
> > > > > though, so I would expect to see Facelet support improve over
> time.
> > This
> > > > > is, of course, a community project!
> > > > >
> > > > Getting away from the discussion itself...
> > > >
> > > > Actually having facelets in would be a great welcome for the
> component
> > > > devs too, I have been playing around with the thought of having
> parts
> > > > of the stuff I am doing being moved into the facelets domain, sort
> of
> > > > like a tomahawk facelets.
> > > > Problem is I cannot do it in the borders of the Tomahawk project
> > > > currently because those components would only work with facelets.
> > > > (There was a discussion in the myfaces list a while ago)
> > > >
> > > > I will give a description of the core problem.
> > > >
> > > > Simple JSF control == 3 classes (one tag class, one component class,
> one
> > > > renderer clasS)
> > > > two xml file entries
> > > >
> > > > each class is 100 locs code min and the renderer uses
> > > > a crude servlet like outputwriter api to the worst.
> > > > 90% of this code normally is just glue code.
> > > >
> > > > 90% of most of this code probably could be replaced by simply
> facelet
> > > > tags and only specialized stuff would have to be coded in the
> component
> > > > api itself.
> > > >
> > > > The component api probably is the biggest problem JSF has in my
> opinion
> > > > and it prevents a lot of people jumping onto the ship.
> > > > Facelets would be an easy entry point to add new components.
> > > >
> > > >
> > > > Heck everything which makes things easier and helps people to ease
> > > > coding is welcome, it does not have to be facelets.
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Tomahawk release plans?
Posted by Martin Marinschek <ma...@gmail.com>.
Good idea!
regards,
Martin
On 3/16/07, Adrian Mitev <ad...@googlemail.com> 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 <jo...@googlemail.com>:
> > 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 component. I've now ended by
> extending Renderer directly, I can't even reuse a single line of the
> AbstractWhateverScheduleRenderers. Instead I have to
> duplicate parts of them in my own renderer.
> >
> > About the three classes: When I want to quickly create my own component
> for handle a particular problem, I need only the component class itself and
> my facelets taglib. The component can do the rendering.
> >
> > Once I'd have those components ready to publish to a greater audience I
> wouldn't mind writing renderer and tag classes.
> >
> >
> > On 3/15/07, Werner Punz <we...@gmail.com> wrote:
> > > 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 like a
> > > > huge number of the userbase is already using or migrating to Facelets,
> > > > though, so I would expect to see Facelet support improve over time.
> This
> > > > is, of course, a community project!
> > > >
> > > Getting away from the discussion itself...
> > >
> > > Actually having facelets in would be a great welcome for the component
> > > devs too, I have been playing around with the thought of having parts
> > > of the stuff I am doing being moved into the facelets domain, sort of
> > > like a tomahawk facelets.
> > > Problem is I cannot do it in the borders of the Tomahawk project
> > > currently because those components would only work with facelets.
> > > (There was a discussion in the myfaces list a while ago)
> > >
> > > I will give a description of the core problem.
> > >
> > > Simple JSF control == 3 classes (one tag class, one component class, one
> > > renderer clasS)
> > > two xml file entries
> > >
> > > each class is 100 locs code min and the renderer uses
> > > a crude servlet like outputwriter api to the worst.
> > > 90% of this code normally is just glue code.
> > >
> > > 90% of most of this code probably could be replaced by simply facelet
> > > tags and only specialized stuff would have to be coded in the component
> > > api itself.
> > >
> > > The component api probably is the biggest problem JSF has in my opinion
> > > and it prevents a lot of people jumping onto the ship.
> > > Facelets would be an easy entry point to add new components.
> > >
> > >
> > > Heck everything which makes things easier and helps people to ease
> > > coding is welcome, it does not have to be facelets.
> > >
> > >
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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 outputwriter api.
Matzes approach was good, but it falls short on the problem that he
initializes velocity on component level, it has to be initialized on
request or session level and keep the component tree or its compiles in ram.
Basically having a velocity renderer with the component as model would
be the most feasable approach and would not interfer with existing view
handlers.
Also it would shift the renderer towards a target language side instead
of keeping it nailed down on the java side, where you have to fight the
cured printWriter api.
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 <mk...@gmail.com> wrote:
>
> 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.
>
> http://people.apache.org/~matzew/jsfvelocity.html
>
> On 3/16/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
> > 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 any research on actually
> > implementing a JSF renderer in velocity?
> >
> > On 3/16/07, Werner Punz <we...@gmail.com> wrote:
> > > Jörn Zaefferer schrieb:
> > > > 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?
> > > >
> > > actually jsf tries to avoid it and then mixes it in again via helper
> > > constructs (datalist in tomahawk or ui:repeat in facelets), thing is,
> > > that a templating mechanism basically has the same
> > > language needs as every other language, which is
> > > sequences, iterations and selections!
> > >
> > >
> > > JSF/EL follows the we want to be as minimalistic as possible approach
> > > and fails so far that the core language constructs had to be added via
> > > crude helper constructs.
> > >
> > > Velocity is on the other side of the fence, it adds a full blown
> > > language for templating which is as far as possible from xml to make a
> > > visual difference in editing, but it still tries to keep a clear
> border
> > > between model/controller and view.
> > >
> > > So what you get is, a full blown language on its own, with macro
> > > capabilities, an internal macro compiler and cacher, and still a clear
> > > border which is needed in mvc (one of the reasons why JSP itself is a
> > > bad solution is that it blurs those borders)
> > >
> > > So a typical velocity construct looks like this
> > >
> > > <h1>$component.myvalue</h1>
> > >
> > > #if($compoment.myvalue == 'A')
> > > #macro1($component)
> > > #else
> > > <h2 styleClass="error"> component value is not set </h2>
> > > #end
> > >
> > >
> > > so where is the difference to the printwriter...
> > >
> > > the difference is, basically an inversion of rendering,
> > > you basically define the renderers in the language you want to target,
> > > but with a full blown programming language underneath it which allows
> > > encapsulation of code parts sequences and iterations, but the
> > > strict cut between component as model/controller part is still there,
> > > the code is just shifted into a domain which is easier to maintain,
> than
> > >
> > > hundreds of lines of prints and calls into constants.
> > > I personally see this approach more feasable than a crude
> > > html/el approach or an approach of adding helpers ot the printwriter,
> > > or even worse the introduction of another jsp layer onto the component
> > > renderer where scriptlets are reintroduced again.
> > >
> > >
> >
> >
>
Re: Tomahawk release plans?
Posted by Mike Kienenberger <mk...@gmail.com>.
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.
http://people.apache.org/~matzew/jsfvelocity.html
On 3/16/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
> 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 any research on actually
> implementing a JSF renderer in velocity?
>
> On 3/16/07, Werner Punz <we...@gmail.com> wrote:
> > Jörn Zaefferer schrieb:
> > > 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?
> > >
> > actually jsf tries to avoid it and then mixes it in again via helper
> > constructs (datalist in tomahawk or ui:repeat in facelets), thing is,
> > that a templating mechanism basically has the same
> > language needs as every other language, which is
> > sequences, iterations and selections!
> >
> >
> > JSF/EL follows the we want to be as minimalistic as possible approach
> > and fails so far that the core language constructs had to be added via
> > crude helper constructs.
> >
> > Velocity is on the other side of the fence, it adds a full blown
> > language for templating which is as far as possible from xml to make a
> > visual difference in editing, but it still tries to keep a clear border
> > between model/controller and view.
> >
> > So what you get is, a full blown language on its own, with macro
> > capabilities, an internal macro compiler and cacher, and still a clear
> > border which is needed in mvc (one of the reasons why JSP itself is a
> > bad solution is that it blurs those borders)
> >
> > So a typical velocity construct looks like this
> >
> > <h1>$component.myvalue</h1>
> >
> > #if($compoment.myvalue == 'A')
> > #macro1($component)
> > #else
> > <h2 styleClass="error"> component value is not set </h2>
> > #end
> >
> >
> > so where is the difference to the printwriter...
> >
> > the difference is, basically an inversion of rendering,
> > you basically define the renderers in the language you want to target,
> > but with a full blown programming language underneath it which allows
> > encapsulation of code parts sequences and iterations, but the
> > strict cut between component as model/controller part is still there,
> > the code is just shifted into a domain which is easier to maintain, than
> >
> > hundreds of lines of prints and calls into constants.
> > I personally see this approach more feasable than a crude
> > html/el approach or an approach of adding helpers ot the printwriter,
> > or even worse the introduction of another jsp layer onto the component
> > renderer where scriptlets are reintroduced again.
> >
> >
>
>
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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.
Actually to sum it up, JSF has a not of nice areas, but the component
api is simply a desaster.
Adrian Mitev schrieb:
> Hi, Werner! You could post that as comment to my issue at
> javaserverfaces-spec
>
> 2007/3/16, Werner Punz < werner.punz@gmail.com
> <ma...@gmail.com>>:
>
> 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>
> >
> <https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=246>
> >
>
> Hi Adrian I think this does not go too far enough, a handful of common
> utils classes does not really help with the problem
>
> what is needed is to tackle the problem on various ends
> a) way too much configuration, try to get rid of it entirely, move the
> entire configuration into annotations and probably also get rid of
> the entire taglib binding classes that way.
>
> that way we also probably could get rid of the entire save and restore
> code, and the properties simply would be setters and getters with the
> save restore bindings woven around
>
> b) we need a renderer templating engine, but not like jsp more along the
> lines of velocity which can be used optionally
>
> c) we need something high level (goes hand in hand with b)
> eventually adding facelets to the mix, but with the possibility
> to hook in custrom control classes in a rather seamless way (this would
> be the same combination as in b, with facelets as templating for the
> component)
>
>
>
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 any research on actually
implementing a JSF renderer in velocity?
On 3/16/07, Werner Punz <we...@gmail.com> wrote:
>
> Jörn Zaefferer schrieb:
> > 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?
> >
> actually jsf tries to avoid it and then mixes it in again via helper
> constructs (datalist in tomahawk or ui:repeat in facelets), thing is,
> that a templating mechanism basically has the same
> language needs as every other language, which is
> sequences, iterations and selections!
>
>
> JSF/EL follows the we want to be as minimalistic as possible approach
> and fails so far that the core language constructs had to be added via
> crude helper constructs.
>
> Velocity is on the other side of the fence, it adds a full blown
> language for templating which is as far as possible from xml to make a
> visual difference in editing, but it still tries to keep a clear border
> between model/controller and view.
>
> So what you get is, a full blown language on its own, with macro
> capabilities, an internal macro compiler and cacher, and still a clear
> border which is needed in mvc (one of the reasons why JSP itself is a
> bad solution is that it blurs those borders)
>
> So a typical velocity construct looks like this
>
> <h1>$component.myvalue</h1>
>
> #if($compoment.myvalue == 'A')
> #macro1($component)
> #else
> <h2 styleClass="error"> component value is not set </h2>
> #end
>
>
> so where is the difference to the printwriter...
>
> the difference is, basically an inversion of rendering,
> you basically define the renderers in the language you want to target,
> but with a full blown programming language underneath it which allows
> encapsulation of code parts sequences and iterations, but the
> strict cut between component as model/controller part is still there,
> the code is just shifted into a domain which is easier to maintain, than
>
> hundreds of lines of prints and calls into constants.
> I personally see this approach more feasable than a crude
> html/el approach or an approach of adding helpers ot the printwriter,
> or even worse the introduction of another jsp layer onto the component
> renderer where scriptlets are reintroduced again.
>
>
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
Jörn Zaefferer schrieb:
> 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?
>
actually jsf tries to avoid it and then mixes it in again via helper
constructs (datalist in tomahawk or ui:repeat in facelets), thing is,
that a templating mechanism basically has the same
language needs as every other language, which is
sequences, iterations and selections!
JSF/EL follows the we want to be as minimalistic as possible approach
and fails so far that the core language constructs had to be added via
crude helper constructs.
Velocity is on the other side of the fence, it adds a full blown
language for templating which is as far as possible from xml to make a
visual difference in editing, but it still tries to keep a clear border
between model/controller and view.
So what you get is, a full blown language on its own, with macro
capabilities, an internal macro compiler and cacher, and still a clear
border which is needed in mvc (one of the reasons why JSP itself is a
bad solution is that it blurs those borders)
So a typical velocity construct looks like this
<h1>$component.myvalue</h1>
#if($compoment.myvalue == 'A')
#macro1($component)
#else
<h2 styleClass="error"> component value is not set </h2>
#end
so where is the difference to the printwriter...
the difference is, basically an inversion of rendering,
you basically define the renderers in the language you want to target,
but with a full blown programming language underneath it which allows
encapsulation of code parts sequences and iterations, but the
strict cut between component as model/controller part is still there,
the code is just shifted into a domain which is easier to maintain, than
hundreds of lines of prints and calls into constants.
I personally see this approach more feasable than a crude
html/el approach or an approach of adding helpers ot the printwriter,
or even worse the introduction of another jsp layer onto the component
renderer where scriptlets are reintroduced again.
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 <we...@gmail.com> wrote:
>
> 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, which I do not agree with)
>
> component java
> with annotations
>
> plain pojo with a handful of annotations in the easiest way
>
> renderer velocity: you would get template caching and a real programming
> language centered around templating, which mixes well with xml centric
> dialects due to having different synactic structures.
>
> in the end you probably just would need a
>
> $component for the component access
> and a
> $jsftools for the jsf access from the renderer
>
> and then you do your templates just the usual velocity way (which works
> very well in my opinion and is way better than the jstl, el etc...
> approach sun prefers
>
> anyway this wont make it, but it would be a nice soc project in my
> opinion, i do not see to much which would interfer by doing it now, you
> just have to find the hooks into velocity where you can add manually
> macros to the already existing data tree of velocity and initialize
> velocity globally, or at least on session level (also depending how
> thread save velocity is).
>
>
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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, which I do not agree with)
component java
with annotations
plain pojo with a handful of annotations in the easiest way
renderer velocity: you would get template caching and a real programming
language centered around templating, which mixes well with xml centric
dialects due to having different synactic structures.
in the end you probably just would need a
$component for the component access
and a
$jsftools for the jsf access from the renderer
and then you do your templates just the usual velocity way (which works
very well in my opinion and is way better than the jstl, el etc...
approach sun prefers
anyway this wont make it, but it would be a nice soc project in my
opinion, i do not see to much which would interfer by doing it now, you
just have to find the hooks into velocity where you can add manually
macros to the already existing data tree of velocity and initialize
velocity globally, or at least on session level (also depending how
thread save velocity is).
Re: Tomahawk release plans?
Posted by Adrian Mitev <ad...@googlemail.com>.
For renderer templating engine - probably the Exadel guys will contribute
their engine to jsf 2.0.
>
> 2007/3/16, Werner Punz < werner.punz@gmail.com>:
> >
> > 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 enough, a handful of common
> > utils classes does not really help with the problem
> >
> > what is needed is to tackle the problem on various ends
> > a) way too much configuration, try to get rid of it entirely, move the
> > entire configuration into annotations and probably also get rid of
> > the entire taglib binding classes that way.
> >
> > that way we also probably could get rid of the entire save and restore
> > code, and the properties simply would be setters and getters with the
> > save restore bindings woven around
> >
> > b) we need a renderer templating engine, but not like jsp more along the
> > lines of velocity which can be used optionally
> >
> > c) we need something high level (goes hand in hand with b)
> > eventually adding facelets to the mix, but with the possibility
> > to hook in custrom control classes in a rather seamless way (this would
> > be the same combination as in b, with facelets as templating for the
> > component)
> >
> >
> >
>
Re: Tomahawk release plans?
Posted by Adrian Mitev <ad...@googlemail.com>.
Hi, Werner! You could post that as comment to my issue at
javaserverfaces-spec
2007/3/16, Werner Punz <we...@gmail.com>:
>
> 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 enough, a handful of common
> utils classes does not really help with the problem
>
> what is needed is to tackle the problem on various ends
> a) way too much configuration, try to get rid of it entirely, move the
> entire configuration into annotations and probably also get rid of
> the entire taglib binding classes that way.
>
> that way we also probably could get rid of the entire save and restore
> code, and the properties simply would be setters and getters with the
> save restore bindings woven around
>
> b) we need a renderer templating engine, but not like jsp more along the
> lines of velocity which can be used optionally
>
> c) we need something high level (goes hand in hand with b)
> eventually adding facelets to the mix, but with the possibility
> to hook in custrom control classes in a rather seamless way (this would
> be the same combination as in b, with facelets as templating for the
> component)
>
>
>
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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 enough, a handful of common
utils classes does not really help with the problem
what is needed is to tackle the problem on various ends
a) way too much configuration, try to get rid of it entirely, move the
entire configuration into annotations and probably also get rid of
the entire taglib binding classes that way.
that way we also probably could get rid of the entire save and restore
code, and the properties simply would be setters and getters with the
save restore bindings woven around
b) we need a renderer templating engine, but not like jsp more along the
lines of velocity which can be used optionally
c) we need something high level (goes hand in hand with b)
eventually adding facelets to the mix, but with the possibility
to hook in custrom control classes in a rather seamless way (this would
be the same combination as in b, with facelets as templating for the
component)
Re: Tomahawk release plans?
Posted by Adrian Mitev <ad...@googlemail.com>.
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 <jo...@googlemail.com>:
>
> 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 component. I've now ended by
> extending Renderer directly, I can't even reuse a single line of the
> AbstractWhateverScheduleRenderers. Instead I have to duplicate parts of them
> in my own renderer.
>
> About the three classes: When I want to quickly create my own component
> for handle a particular problem, I need only the component class itself and
> my facelets taglib. The component can do the rendering.
>
> Once I'd have those components ready to publish to a greater audience I
> wouldn't mind writing renderer and tag classes.
>
> On 3/15/07, Werner Punz <we...@gmail.com> wrote:
> >
> > 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 like a
> > > huge number of the userbase is already using or migrating to Facelets,
> > > though, so I would expect to see Facelet support improve over time.
> > This
> > > is, of course, a community project!
> > >
> > Getting away from the discussion itself...
> >
> > Actually having facelets in would be a great welcome for the component
> > devs too, I have been playing around with the thought of having parts
> > of the stuff I am doing being moved into the facelets domain, sort of
> > like a tomahawk facelets.
> > Problem is I cannot do it in the borders of the Tomahawk project
> > currently because those components would only work with facelets.
> > (There was a discussion in the myfaces list a while ago)
> >
> > I will give a description of the core problem.
> >
> > Simple JSF control == 3 classes (one tag class, one component class, one
> > renderer clasS)
> > two xml file entries
> >
> > each class is 100 locs code min and the renderer uses
> > a crude servlet like outputwriter api to the worst.
> > 90% of this code normally is just glue code.
> >
> > 90% of most of this code probably could be replaced by simply facelet
> > tags and only specialized stuff would have to be coded in the component
> > api itself.
> >
> > The component api probably is the biggest problem JSF has in my opinion
> > and it prevents a lot of people jumping onto the ship.
> > Facelets would be an easy entry point to add new components.
> >
> >
> > Heck everything which makes things easier and helps people to ease
> > coding is welcome, it does not have to be facelets.
> >
> >
>
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 component. I've now ended by
extending Renderer directly, I can't even reuse a single line of the
AbstractWhateverScheduleRenderers. Instead I have to duplicate parts of them
in my own renderer.
About the three classes: When I want to quickly create my own component for
handle a particular problem, I need only the component class itself and my
facelets taglib. The component can do the rendering.
Once I'd have those components ready to publish to a greater audience I
wouldn't mind writing renderer and tag classes.
On 3/15/07, Werner Punz <we...@gmail.com> wrote:
>
> 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 like a
> > huge number of the userbase is already using or migrating to Facelets,
> > though, so I would expect to see Facelet support improve over time. This
> > is, of course, a community project!
> >
> Getting away from the discussion itself...
>
> Actually having facelets in would be a great welcome for the component
> devs too, I have been playing around with the thought of having parts
> of the stuff I am doing being moved into the facelets domain, sort of
> like a tomahawk facelets.
> Problem is I cannot do it in the borders of the Tomahawk project
> currently because those components would only work with facelets.
> (There was a discussion in the myfaces list a while ago)
>
> I will give a description of the core problem.
>
> Simple JSF control == 3 classes (one tag class, one component class, one
> renderer clasS)
> two xml file entries
>
> each class is 100 locs code min and the renderer uses
> a crude servlet like outputwriter api to the worst.
> 90% of this code normally is just glue code.
>
> 90% of most of this code probably could be replaced by simply facelet
> tags and only specialized stuff would have to be coded in the component
> api itself.
>
> The component api probably is the biggest problem JSF has in my opinion
> and it prevents a lot of people jumping onto the ship.
> Facelets would be an easy entry point to add new components.
>
>
> Heck everything which makes things easier and helps people to ease
> coding is welcome, it does not have to be facelets.
>
>
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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 like a
> huge number of the userbase is already using or migrating to Facelets,
> though, so I would expect to see Facelet support improve over time. This
> is, of course, a community project!
>
Getting away from the discussion itself...
Actually having facelets in would be a great welcome for the component
devs too, I have been playing around with the thought of having parts
of the stuff I am doing being moved into the facelets domain, sort of
like a tomahawk facelets.
Problem is I cannot do it in the borders of the Tomahawk project
currently because those components would only work with facelets.
(There was a discussion in the myfaces list a while ago)
I will give a description of the core problem.
Simple JSF control == 3 classes (one tag class, one component class, one
renderer clasS)
two xml file entries
each class is 100 locs code min and the renderer uses
a crude servlet like outputwriter api to the worst.
90% of this code normally is just glue code.
90% of most of this code probably could be replaced by simply facelet
tags and only specialized stuff would have to be coded in the component
api itself.
The component api probably is the biggest problem JSF has in my opinion
and it prevents a lot of people jumping onto the ship.
Facelets would be an easy entry point to add new components.
Heck everything which makes things easier and helps people to ease
coding is welcome, it does not have to be facelets.
Re: Tomahawk release plans?
Posted by Werner Punz <we...@gmail.com>.
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 doing my own one
again because I could not figure out in my limited time what half of the
attributes (which often have very generic names) were doing.
Re: Tomahawk release plans?
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <jb...@klkurz.com> wrote:
> 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 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, but even if it wasn't, Trinidad has a good solution in
> > place that could be ported over to deal with code generation issues.
> >
> > Once the infrastructure was in place, it'd be a lot easier to address
> > all of the issues for individual components.
> >
> > On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> >> 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 the userbase is already using or migrating to Facelets,
> >> though, so I would expect to see Facelet support improve over time. This
> >> is, of course, a community project!
> >>
> >> Tis said that to move a mountain, one must begin by carrying small
> >> stones. To that end, every little bit helps - like updating the wiki, or
> >> providing little patches to improve facelets compatibility (such as
> >> TOMAHAWK-914). Maybe soon we can get it where everything works great out
> >> of the box. :D
> >>
> >> Regards,
> >>
> >> Jeff Bischoff
> >> Kenneth L Kurz & Associates, Inc.
> >>
> >> Jörn Zaefferer wrote:
> >> > 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 can't imagine to use JSF ever again without Facelets... It just
> >> doesn't
> >> > make any sense ;)
> >> >
> >> > On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> >> >>
> >> >> 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 components, following the release. Any
> >> help is
> >> >> > welcome and appreciated! :)
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Jeff Bischoff
> >> >> > Kenneth L Kurz & Associates, Inc.
> >> >> >
> >> >> > Jörn Zaefferer wrote:
> >> >> >> 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 <bi...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> 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 <si...@capgemini.com> wrote:
> >> >> >>> >
> >> >> >>> > 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:rj.1970@googlemail.com]
> >> >> >>> > Envoyé : mardi 13 mars 2007 10:26
> >> >> >>> > À : users@myfaces.apache.org
> >> >> >>> > Objet : Tomahawk release plans?
> >> >> >>> >
> >> >> >>> > Hi,
> >> >> >>> >
> >> >> >>> > I could not find any roadmap for the Tomahawk versions 1.1.4 /
> >> >> 1.1.5
> >> >> .
> >> >> >>> > When will these be released?
> >> >> >>> >
> >> >> >>> > cheers
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > This message contains information that may be privileged or
> >> >> >>> confidential
> >> >> >>> and is the property of the Capgemini Group. It is intended only
> >> for
> >> >> the
> >> >> >>> person to whom it is addressed. If you are not the intended
> >> >> >>> recipient, you
> >> >> >>> are not authorized to read, print, retain, copy, disseminate,
> >> >> >>> distribute,
> >> >> >>> or use this message or any part thereof. If you receive this
> >> message
> >> >> in
> >> >> >>> error, please notify the sender immediately and delete all
> >> copies of
> >> >> >>> this
> >> >> >>> message.
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> http://www.irian.at
> >> >> >>>
> >> >> >>> Your JSF powerhouse -
> >> >> >>> JSF Consulting, Development and
> >> >> >>> Courses in English and German
> >> >> >>>
> >> >> >>> Professional Support for Apache MyFaces
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Tomahawk release plans?
Posted by Jeff Bischoff <jb...@klkurz.com>.
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 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, but even if it wasn't, Trinidad has a good solution in
> place that could be ported over to deal with code generation issues.
>
> Once the infrastructure was in place, it'd be a lot easier to address
> all of the issues for individual components.
>
> On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
>> 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 the userbase is already using or migrating to Facelets,
>> though, so I would expect to see Facelet support improve over time. This
>> is, of course, a community project!
>>
>> Tis said that to move a mountain, one must begin by carrying small
>> stones. To that end, every little bit helps - like updating the wiki, or
>> providing little patches to improve facelets compatibility (such as
>> TOMAHAWK-914). Maybe soon we can get it where everything works great out
>> of the box. :D
>>
>> Regards,
>>
>> Jeff Bischoff
>> Kenneth L Kurz & Associates, Inc.
>>
>> Jörn Zaefferer wrote:
>> > 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 can't imagine to use JSF ever again without Facelets... It just
>> doesn't
>> > make any sense ;)
>> >
>> > On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
>> >>
>> >> 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 components, following the release. Any
>> help is
>> >> > welcome and appreciated! :)
>> >> >
>> >> > Regards,
>> >> >
>> >> > Jeff Bischoff
>> >> > Kenneth L Kurz & Associates, Inc.
>> >> >
>> >> > Jörn Zaefferer wrote:
>> >> >> 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 <bi...@gmail.com> wrote:
>> >> >>>
>> >> >>> 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 <si...@capgemini.com> wrote:
>> >> >>> >
>> >> >>> > 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:rj.1970@googlemail.com]
>> >> >>> > Envoyé : mardi 13 mars 2007 10:26
>> >> >>> > À : users@myfaces.apache.org
>> >> >>> > Objet : Tomahawk release plans?
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> >
>> >> >>> > I could not find any roadmap for the Tomahawk versions 1.1.4 /
>> >> 1.1.5
>> >> .
>> >> >>> > When will these be released?
>> >> >>> >
>> >> >>> > cheers
>> >> >>> >
>> >> >>> >
>> >> >>> > This message contains information that may be privileged or
>> >> >>> confidential
>> >> >>> and is the property of the Capgemini Group. It is intended only
>> for
>> >> the
>> >> >>> person to whom it is addressed. If you are not the intended
>> >> >>> recipient, you
>> >> >>> are not authorized to read, print, retain, copy, disseminate,
>> >> >>> distribute,
>> >> >>> or use this message or any part thereof. If you receive this
>> message
>> >> in
>> >> >>> error, please notify the sender immediately and delete all
>> copies of
>> >> >>> this
>> >> >>> message.
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> http://www.irian.at
>> >> >>>
>> >> >>> Your JSF powerhouse -
>> >> >>> JSF Consulting, Development and
>> >> >>> Courses in English and German
>> >> >>>
>> >> >>> Professional Support for Apache MyFaces
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>>
>
>
>
Re: Tomahawk release plans?
Posted by Mike Kienenberger <mk...@gmail.com>.
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, but even if it wasn't, Trinidad has a good solution in
place that could be ported over to deal with code generation issues.
Once the infrastructure was in place, it'd be a lot easier to address
all of the issues for individual components.
On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> 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 the userbase is already using or migrating to Facelets,
> though, so I would expect to see Facelet support improve over time. This
> is, of course, a community project!
>
> Tis said that to move a mountain, one must begin by carrying small
> stones. To that end, every little bit helps - like updating the wiki, or
> providing little patches to improve facelets compatibility (such as
> TOMAHAWK-914). Maybe soon we can get it where everything works great out
> of the box. :D
>
> Regards,
>
> Jeff Bischoff
> Kenneth L Kurz & Associates, Inc.
>
> Jörn Zaefferer wrote:
> > 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 can't imagine to use JSF ever again without Facelets... It just doesn't
> > make any sense ;)
> >
> > On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> >>
> >> 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 components, following the release. Any help is
> >> > welcome and appreciated! :)
> >> >
> >> > Regards,
> >> >
> >> > Jeff Bischoff
> >> > Kenneth L Kurz & Associates, Inc.
> >> >
> >> > Jörn Zaefferer wrote:
> >> >> 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 <bi...@gmail.com> wrote:
> >> >>>
> >> >>> 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 <si...@capgemini.com> wrote:
> >> >>> >
> >> >>> > 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:rj.1970@googlemail.com]
> >> >>> > Envoyé : mardi 13 mars 2007 10:26
> >> >>> > À : users@myfaces.apache.org
> >> >>> > Objet : Tomahawk release plans?
> >> >>> >
> >> >>> > Hi,
> >> >>> >
> >> >>> > I could not find any roadmap for the Tomahawk versions 1.1.4 /
> >> 1.1.5
> >> .
> >> >>> > When will these be released?
> >> >>> >
> >> >>> > cheers
> >> >>> >
> >> >>> >
> >> >>> > This message contains information that may be privileged or
> >> >>> confidential
> >> >>> and is the property of the Capgemini Group. It is intended only for
> >> the
> >> >>> person to whom it is addressed. If you are not the intended
> >> >>> recipient, you
> >> >>> are not authorized to read, print, retain, copy, disseminate,
> >> >>> distribute,
> >> >>> or use this message or any part thereof. If you receive this message
> >> in
> >> >>> error, please notify the sender immediately and delete all copies of
> >> >>> this
> >> >>> message.
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> >>> --
> >> >>> http://www.irian.at
> >> >>>
> >> >>> Your JSF powerhouse -
> >> >>> JSF Consulting, Development and
> >> >>> Courses in English and German
> >> >>>
> >> >>> Professional Support for Apache MyFaces
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >
>
>
>
>
Re: Tomahawk release plans?
Posted by Jeff Bischoff <jb...@klkurz.com>.
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 the userbase is already using or migrating to Facelets,
though, so I would expect to see Facelet support improve over time. This
is, of course, a community project!
Tis said that to move a mountain, one must begin by carrying small
stones. To that end, every little bit helps - like updating the wiki, or
providing little patches to improve facelets compatibility (such as
TOMAHAWK-914). Maybe soon we can get it where everything works great out
of the box. :D
Regards,
Jeff Bischoff
Kenneth L Kurz & Associates, Inc.
Jörn Zaefferer wrote:
> 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 can't imagine to use JSF ever again without Facelets... It just doesn't
> make any sense ;)
>
> On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
>>
>> 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 components, following the release. Any help is
>> > welcome and appreciated! :)
>> >
>> > Regards,
>> >
>> > Jeff Bischoff
>> > Kenneth L Kurz & Associates, Inc.
>> >
>> > Jörn Zaefferer wrote:
>> >> 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 <bi...@gmail.com> wrote:
>> >>>
>> >>> 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 <si...@capgemini.com> wrote:
>> >>> >
>> >>> > 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:rj.1970@googlemail.com]
>> >>> > Envoyé : mardi 13 mars 2007 10:26
>> >>> > À : users@myfaces.apache.org
>> >>> > Objet : Tomahawk release plans?
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > I could not find any roadmap for the Tomahawk versions 1.1.4 /
>> 1.1.5
>> .
>> >>> > When will these be released?
>> >>> >
>> >>> > cheers
>> >>> >
>> >>> >
>> >>> > This message contains information that may be privileged or
>> >>> confidential
>> >>> and is the property of the Capgemini Group. It is intended only for
>> the
>> >>> person to whom it is addressed. If you are not the intended
>> >>> recipient, you
>> >>> are not authorized to read, print, retain, copy, disseminate,
>> >>> distribute,
>> >>> or use this message or any part thereof. If you receive this message
>> in
>> >>> error, please notify the sender immediately and delete all copies of
>> >>> this
>> >>> message.
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>> http://www.irian.at
>> >>>
>> >>> Your JSF powerhouse -
>> >>> JSF Consulting, Development and
>> >>> Courses in English and German
>> >>>
>> >>> Professional Support for Apache MyFaces
>> >>>
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 can't imagine to use JSF ever again without Facelets... It just doesn't
make any sense ;)
On 3/14/07, Jeff Bischoff <jb...@klkurz.com> wrote:
>
> 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 components, following the release. Any help is
> > welcome and appreciated! :)
> >
> > Regards,
> >
> > Jeff Bischoff
> > Kenneth L Kurz & Associates, Inc.
> >
> > Jörn Zaefferer wrote:
> >> 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 <bi...@gmail.com> wrote:
> >>>
> >>> 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 <si...@capgemini.com> wrote:
> >>> >
> >>> > 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:rj.1970@googlemail.com]
> >>> > Envoyé : mardi 13 mars 2007 10:26
> >>> > À : users@myfaces.apache.org
> >>> > Objet : Tomahawk release plans?
> >>> >
> >>> > Hi,
> >>> >
> >>> > I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5
> .
> >>> > When will these be released?
> >>> >
> >>> > cheers
> >>> >
> >>> >
> >>> > This message contains information that may be privileged or
> >>> confidential
> >>> and is the property of the Capgemini Group. It is intended only for
> the
> >>> person to whom it is addressed. If you are not the intended
> >>> recipient, you
> >>> are not authorized to read, print, retain, copy, disseminate,
> >>> distribute,
> >>> or use this message or any part thereof. If you receive this message
> in
> >>> error, please notify the sender immediately and delete all copies of
> >>> this
> >>> message.
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> http://www.irian.at
> >>>
> >>> Your JSF powerhouse -
> >>> JSF Consulting, Development and
> >>> Courses in English and German
> >>>
> >>> Professional Support for Apache MyFaces
> >>>
> >>
> >
> >
> >
> >
> >
> >
>
>
>
>
Re: Tomahawk release plans?
Posted by Jeff Bischoff <jb...@klkurz.com>.
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 components, following the release. Any help is
> welcome and appreciated! :)
>
> Regards,
>
> Jeff Bischoff
> Kenneth L Kurz & Associates, Inc.
>
> Jörn Zaefferer wrote:
>> 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 <bi...@gmail.com> wrote:
>>>
>>> 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 <si...@capgemini.com> wrote:
>>> >
>>> > 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:rj.1970@googlemail.com]
>>> > Envoyé : mardi 13 mars 2007 10:26
>>> > À : users@myfaces.apache.org
>>> > Objet : Tomahawk release plans?
>>> >
>>> > Hi,
>>> >
>>> > I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
>>> > When will these be released?
>>> >
>>> > cheers
>>> >
>>> >
>>> > This message contains information that may be privileged or
>>> confidential
>>> and is the property of the Capgemini Group. It is intended only for the
>>> person to whom it is addressed. If you are not the intended
>>> recipient, you
>>> are not authorized to read, print, retain, copy, disseminate,
>>> distribute,
>>> or use this message or any part thereof. If you receive this message in
>>> error, please notify the sender immediately and delete all copies of
>>> this
>>> message.
>>> >
>>> >
>>>
>>>
>>> --
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>
>
>
>
>
>
>
Re: Tomahawk release plans?
Posted by Jeff Bischoff <jb...@klkurz.com>.
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 & Associates, Inc.
Jörn Zaefferer wrote:
> 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 <bi...@gmail.com> wrote:
>>
>> 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 <si...@capgemini.com> wrote:
>> >
>> > 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:rj.1970@googlemail.com]
>> > Envoyé : mardi 13 mars 2007 10:26
>> > À : users@myfaces.apache.org
>> > Objet : Tomahawk release plans?
>> >
>> > Hi,
>> >
>> > I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
>> > When will these be released?
>> >
>> > cheers
>> >
>> >
>> > This message contains information that may be privileged or
>> confidential
>> and is the property of the Capgemini Group. It is intended only for the
>> person to whom it is addressed. If you are not the intended
>> recipient, you
>> are not authorized to read, print, retain, copy, disseminate,
>> distribute,
>> or use this message or any part thereof. If you receive this message in
>> error, please notify the sender immediately and delete all copies of
>> this
>> message.
>> >
>> >
>>
>>
>> --
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
Re: Tomahawk release plans?
Posted by Jörn Zaefferer <jo...@googlemail.com>.
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 <bi...@gmail.com> wrote:
>
> 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 <si...@capgemini.com> wrote:
> >
> > 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:rj.1970@googlemail.com]
> > Envoyé : mardi 13 mars 2007 10:26
> > À : users@myfaces.apache.org
> > Objet : Tomahawk release plans?
> >
> > Hi,
> >
> > I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
> > When will these be released?
> >
> > cheers
> >
> >
> > This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
> >
> >
>
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Tomahawk release plans?
Posted by Gerald Müllan <bi...@gmail.com>.
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 <si...@capgemini.com> wrote:
>
> 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:rj.1970@googlemail.com]
> Envoyé : mardi 13 mars 2007 10:26
> À : users@myfaces.apache.org
> Objet : Tomahawk release plans?
>
> Hi,
>
> I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
> When will these be released?
>
> cheers
>
>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
RE: Tomahawk release plans?
Posted by GUILLEMOT Simon <si...@capgemini.com>.
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:rj.1970@googlemail.com]
Envoyé : mardi 13 mars 2007 10:26
À : users@myfaces.apache.org
Objet : Tomahawk release plans?
Hi,
I could not find any roadmap for the Tomahawk versions 1.1.4 / 1.1.5.
When will these be released?
cheers
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.