Re: myfaces popularity
Yes, I feared that :(
They have a relative defensive update policy.
On one side this is good for existing apps which doesn't have much
compatibility problems. But they e.g. still ship a very old jetty container
which contains lots of known bugs.
LieGrue,
strub
--- On Mon, 12/6/10, Nikolay Rychkov nikolay.rych...@gmail.com wrote:
From: Nikolay Rychkov nikolay.rych...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Monday, December 6, 2010, 2:02 AM
GAE does not support it.
http://code.google.com/p/googleappengine/issues/detail?id=3431q=elcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component%20Language
2010/12/5 Mark Struberg strub...@yahoo.de
thingy.edit('X')
So what you need is UEL-2.2. No idea if gae supports
this. Maybe there is
an option to get it (comes with Servlet-3.0). In this
case you would not
need to do anything - but if gae doesn't support it,
then you would most
likely be doomed :/
Maybe try asking Ali Ok, he did a few things on GAE in
the past.
LieGrue,
strub
--- On Sun, 12/5/10, ken keller klr...@gmail.com
wrote:
From: ken keller klr...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Sunday, December 5, 2010, 8:14 PM
I don't see how CDI helps. I tried 3
ways:
X denotes the value of the ID.
1) Pass id as view param using h:link:
h:link value=edit outcome=edit_thing
f:param name=id
value=X/
/h:link
and bind to pseudo-property named idToLoad in
edit_thing.xhtml:
f:metadata
f:viewParam name=id
value=#{thingy.idToLoad}/
/f:metadata
2) Pass id as view param using h:commandLink:
h:commandLink value=edit
action=#{thingy.edit}
f:param name=id
value=X/
/h:commandLink
Action method named edit() gets id from
FacesContext:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get(id);
If that isn't inconvenient, what is? :)
3) Pass id as EL param using h:commandLink:
h:commandLink value=edit
action=#{thingy.edit('X')}
/h:commandLink
myfaces complains:
java.lang.NoSuchMethodError:
javax.el.ELResolver.invoke(Ljavax/el/ELContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;
My action method is:
public String edit(String id) { ... }
My web.xml has:
context-param
param-namecom.sun.faces.expressionFactory/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
My pom.xml has:
dependency
groupIdjavax.el/groupId
artifactIdel-api/artifactId
version2.2/version
/dependency
dependency
groupIdorg.glassfish.web/groupId
artifactIdel-impl/artifactId
version2.2/version
/dependency
I don't know why this fails.
What's the best style?
On Sat, Dec 4, 2010 at 8:31 AM, Gerhard gerhard.petra...@gmail.com
wrote:
short addition:
with myfaces codi also beans annotated with
@ManagedBean are normal cdi
beans (automatically).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/12/4 Mark Struberg strub...@yahoo.de
+1, with CDI you would be able to
simply @Inject
all your needed
parameters. In general I'd say that one
should
generally use CDI instead
of
the JSF @ManagedBean mechanism.
LieGrue,
strub
--- On Sat, 12/4/10, Jakob Korherr
jakob.korh...@gmail.com
wrote:
From: Jakob Korherr jakob.korh...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Saturday, December 4, 2010,
3:45 PM
... or, you know, use CDI for
your
managed beans ;)
Regards,
Jakob
2010/12/4 Jakob Korherr jakob.korh...@gmail.com:
Hi,
Sorry, I just skimmed your
mail, but
for your last
point
Finally, what's the
correct way to
implement an
editor action? The managed
bean needs to be
initialized before
rendering it.
So instead of invoking the
no-arg constructor, I want
something
like:
Foo(id)
to be invoked.
you can use a no-arg
constructor and an
init method
annotated with
@PostConstruct. So something
like
this:
@PostConstruct
private void init() { // init
bean here
}
However, you can't pass
arguments
neither to the
constructor nor to
this init method. You need to
1) get
Re: serving views from jar files
Thank you, indeed the blog pointed by you was very helpful. I am currently able to load view definition files from jar files sitting on the classpath. Best regards, Dan. On 03.12.2010 10:43, Mark Struberg wrote: Hi Dan! You might take a look at Jason Lees blog if this is what you need: http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/ look at the custom ResourceResolver. You can also find this info in the JavaDoc (found the ResourceResolver trick in 2009 somewhere else too at least). LieGrue, strub --- On Fri, 12/3/10, Dan Corneanu c...@savatech.ro wrote: From: Dan Corneanu c...@savatech.ro Subject: serving views from jar files To: users@myfaces.apache.org Date: Friday, December 3, 2010, 8:15 AM Hi, I'm using JSF 2.0 (myfaces 2.0.2). I am trying to implement a modularization solution for my application. The basing idea is that I would like to be able to pack some xhtml view definitions in a jar file and put it on the classpath and be able to use this views as values of |to-view-id| in navigation rules. Is this possible? Ex. |to-view-id/plugins/foobar/foo.xhtml/to-view-id | I would like this id to be associated with an XHTML file located at jar:file:foobar.jar!/foo.xhtml I have tried to implement a custom resource loader but it seems that in the process of finding the right xhtml file to associate with a view ID, the implementation is always looking for the existence of a file on the local file system. Is there any extension point in the JSF 2.0 API that I can use in order to modify this behavior? Best regards, Dan.
Re: serving views from jar files
u r welcome. Btw, if you run on Apache tomcat, you should also check your settings in context.xml [1] Especially take care that 'antiJARLocking' is enabled! Otherwise you might get problems with locked files... LieGrue, strub [1] http://tomcat.apache.org/tomcat-6.0-doc/config/context.html --- On Mon, 12/6/10, Dan Corneanu c...@savatech.ro wrote: From: Dan Corneanu c...@savatech.ro Subject: Re: serving views from jar files To: MyFaces Discussion users@myfaces.apache.org Date: Monday, December 6, 2010, 11:13 AM Thank you, indeed the blog pointed by you was very helpful. I am currently able to load view definition files from jar files sitting on the classpath. Best regards, Dan. On 03.12.2010 10:43, Mark Struberg wrote: Hi Dan! You might take a look at Jason Lees blog if this is what you need: http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/ look at the custom ResourceResolver. You can also find this info in the JavaDoc (found the ResourceResolver trick in 2009 somewhere else too at least). LieGrue, strub --- On Fri, 12/3/10, Dan Corneanu c...@savatech.ro wrote: From: Dan Corneanu c...@savatech.ro Subject: serving views from jar files To: users@myfaces.apache.org Date: Friday, December 3, 2010, 8:15 AM Hi, I'm using JSF 2.0 (myfaces 2.0.2). I am trying to implement a modularization solution for my application. The basing idea is that I would like to be able to pack some xhtml view definitions in a jar file and put it on the classpath and be able to use this views as values of |to-view-id| in navigation rules. Is this possible? Ex. |to-view-id/plugins/foobar/foo.xhtml/to-view-id | I would like this id to be associated with an XHTML file located at jar:file:foobar.jar!/foo.xhtml I have tried to implement a custom resource loader but it seems that in the process of finding the right xhtml file to associate with a view ID, the implementation is always looking for the existence of a file on the local file system. Is there any extension point in the JSF 2.0 API that I can use in order to modify this behavior? Best regards, Dan.
Re: myfaces popularity
Which of the 3 styles is best? Am I missing one?
On Mon, Dec 6, 2010 at 1:45 AM, Mark Struberg strub...@yahoo.de wrote:
Yes, I feared that :(
They have a relative defensive update policy.
On one side this is good for existing apps which doesn't have much
compatibility problems. But they e.g. still ship a very old jetty container
which contains lots of known bugs.
LieGrue,
strub
--- On Mon, 12/6/10, Nikolay Rychkov nikolay.rych...@gmail.com wrote:
From: Nikolay Rychkov nikolay.rych...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Monday, December 6, 2010, 2:02 AM
GAE does not support it.
http://code.google.com/p/googleappengine/issues/detail?id=3431q=elcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component%20Language
2010/12/5 Mark Struberg strub...@yahoo.de
thingy.edit('X')
So what you need is UEL-2.2. No idea if gae supports
this. Maybe there is
an option to get it (comes with Servlet-3.0). In this
case you would not
need to do anything - but if gae doesn't support it,
then you would most
likely be doomed :/
Maybe try asking Ali Ok, he did a few things on GAE in
the past.
LieGrue,
strub
--- On Sun, 12/5/10, ken keller klr...@gmail.com
wrote:
From: ken keller klr...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Sunday, December 5, 2010, 8:14 PM
I don't see how CDI helps. I tried 3
ways:
X denotes the value of the ID.
1) Pass id as view param using h:link:
h:link value=edit outcome=edit_thing
f:param name=id
value=X/
/h:link
and bind to pseudo-property named idToLoad in
edit_thing.xhtml:
f:metadata
f:viewParam name=id
value=#{thingy.idToLoad}/
/f:metadata
2) Pass id as view param using h:commandLink:
h:commandLink value=edit
action=#{thingy.edit}
f:param name=id
value=X/
/h:commandLink
Action method named edit() gets id from
FacesContext:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get(id);
If that isn't inconvenient, what is? :)
3) Pass id as EL param using h:commandLink:
h:commandLink value=edit
action=#{thingy.edit('X')}
/h:commandLink
myfaces complains:
java.lang.NoSuchMethodError:
javax.el.ELResolver.invoke(Ljavax/el/ELContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;
My action method is:
public String edit(String id) { ... }
My web.xml has:
context-param
param-namecom.sun.faces.expressionFactory/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
My pom.xml has:
dependency
groupIdjavax.el/groupId
artifactIdel-api/artifactId
version2.2/version
/dependency
dependency
groupIdorg.glassfish.web/groupId
artifactIdel-impl/artifactId
version2.2/version
/dependency
I don't know why this fails.
What's the best style?
On Sat, Dec 4, 2010 at 8:31 AM, Gerhard gerhard.petra...@gmail.com
wrote:
short addition:
with myfaces codi also beans annotated with
@ManagedBean are normal cdi
beans (automatically).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/12/4 Mark Struberg strub...@yahoo.de
+1, with CDI you would be able to
simply @Inject
all your needed
parameters. In general I'd say that one
should
generally use CDI instead
of
the JSF @ManagedBean mechanism.
LieGrue,
strub
--- On Sat, 12/4/10, Jakob Korherr
jakob.korh...@gmail.com
wrote:
From: Jakob Korherr jakob.korh...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Saturday, December 4, 2010,
3:45 PM
... or, you know, use CDI for
your
managed beans ;)
Regards,
Jakob
2010/12/4 Jakob Korherr jakob.korh...@gmail.com:
Hi,
Sorry, I just skimmed your
mail, but
for your last
point
Finally, what's the
correct way to
implement an
editor action? The managed
bean needs to be
initialized before
rendering it.
So instead of invoking the
no-arg constructor, I want
something
like:
Foo(id)
to be invoked.
you can use a no-arg
constructor and an
Re: myfaces popularity
Hi Ken!
There are a few differences
h:commandLink will cause a form submit - POST
h:link with f:viewParam will cause a bookmarkable GET link
So it depends what you like to do.
LieGrue,
strub
--- On Mon, 12/6/10, ken keller klr...@gmail.com wrote:
From: ken keller klr...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Monday, December 6, 2010, 8:42 PM
Which of the 3 styles is best? Am I
missing one?
On Mon, Dec 6, 2010 at 1:45 AM, Mark Struberg strub...@yahoo.de
wrote:
Yes, I feared that :(
They have a relative defensive update policy.
On one side this is good for existing apps which
doesn't have much
compatibility problems. But they e.g. still ship a
very old jetty container
which contains lots of known bugs.
LieGrue,
strub
--- On Mon, 12/6/10, Nikolay Rychkov nikolay.rych...@gmail.com
wrote:
From: Nikolay Rychkov nikolay.rych...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Monday, December 6, 2010, 2:02 AM
GAE does not support it.
http://code.google.com/p/googleappengine/issues/detail?id=3431q=elcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component%20Language
2010/12/5 Mark Struberg strub...@yahoo.de
thingy.edit('X')
So what you need is UEL-2.2. No idea if gae
supports
this. Maybe there is
an option to get it (comes with
Servlet-3.0). In this
case you would not
need to do anything - but if gae doesn't
support it,
then you would most
likely be doomed :/
Maybe try asking Ali Ok, he did a few things
on GAE in
the past.
LieGrue,
strub
--- On Sun, 12/5/10, ken keller klr...@gmail.com
wrote:
From: ken keller klr...@gmail.com
Subject: Re: myfaces popularity
To: MyFaces Discussion users@myfaces.apache.org
Date: Sunday, December 5, 2010, 8:14
PM
I don't see how CDI helps. I tried 3
ways:
X denotes the value of the ID.
1) Pass id as view param using h:link:
h:link value=edit
outcome=edit_thing
f:param name=id
value=X/
/h:link
and bind to pseudo-property named
idToLoad in
edit_thing.xhtml:
f:metadata
f:viewParam
name=id
value=#{thingy.idToLoad}/
/f:metadata
2) Pass id as view param using
h:commandLink:
h:commandLink value=edit
action=#{thingy.edit}
f:param name=id
value=X/
/h:commandLink
Action method named edit() gets id
from
FacesContext:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get(id);
If that isn't inconvenient, what is?
:)
3) Pass id as EL param using
h:commandLink:
h:commandLink value=edit
action=#{thingy.edit('X')}
/h:commandLink
myfaces complains:
java.lang.NoSuchMethodError:
javax.el.ELResolver.invoke(Ljavax/el/ELContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;
My action method is:
public String edit(String id) { ... }
My web.xml has:
context-param
param-namecom.sun.faces.expressionFactory/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
My pom.xml has:
dependency
groupIdjavax.el/groupId
artifactIdel-api/artifactId
version2.2/version
/dependency
dependency
groupIdorg.glassfish.web/groupId
artifactIdel-impl/artifactId
version2.2/version
/dependency
I don't know why this fails.
What's the best style?
On Sat, Dec 4, 2010 at 8:31 AM, Gerhard
gerhard.petra...@gmail.com
wrote:
short addition:
with myfaces codi also beans
annotated with
@ManagedBean are normal cdi
beans (automatically).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache
MyFaces
2010/12/4 Mark Struberg strub...@yahoo.de
+1, with CDI you would be
able to
simply @Inject
all your needed
parameters. In general I'd
say that one
should
generally use CDI instead
of
the JSF @ManagedBean
mechanism.
LieGrue,
strub
--- On Sat, 12/4/10, Jakob
Korherr
jakob.korh...@gmail.com
wrote:
From: Jakob Korherr
jakob.korh...@gmail.com
Subject: Re: myfaces
popularity
To: MyFaces Discussion
users@myfaces.apache.org
Date: Saturday, December
4, 2010,
3:45
[ANNOUNCE] release of myfaces builder plugin 1.0.8
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Builder Plugin 1.0.8. Apache MyFaces Builder Plugin is a maven plugin, used internally in other projects like myfaces core and tomahawk for generate component classes, tag classes, faces-config files, .tld files and facelets taglib files. In other words, its several maven goals provide a component kit for generate jsf components with minimal effort. Apache MyFaces Builder Plugin is available in the central Maven repository under Group ID org.apache.myfaces.buildtools. Enjoy! Leonardo Uribe
Re: serving views from jar files
Thanks Kito. It works well. Ime --- On Fri, 12/3/10, Kito Mann kito.m...@virtua.com wrote: From: Kito Mann kito.m...@virtua.com Subject: Re: serving views from jar files To: MyFaces Discussion users@myfaces.apache.org, asangansi asanga...@yahoo.com Date: Friday, December 3, 2010, 7:20 PM Hello Ime, Sure -- just place a faces-config.xml file in the META-INF directory of the JAR file. This is how all of the component libraries add their own configuration, and I often use it to configure JSF artifacts in shared modules. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Public JSF 2 Training this January in London: JSF 2 Update for JSF 1.x users (http://bit.ly/jsf2updatecoursehttp://skillsmatter.com/course/java-jee/jsf2-update-course) and JSF 2 in Action (http://bit.ly/jsf2coursehttp://skillsmatter.com/course/java-jee/jsf-and-ajax ) On Fri, Dec 3, 2010 at 8:40 AM, Ime Asangansi asanga...@yahoo.com wrote: Is it possible also that each module has its faces-config.xml? So, that they are all aggregated from the jars? TIA. Ime Sent from my Nokia phone -Original Message- From: Mark Struberg Sent: 03/12/2010 9:43:58 am Subject: Re: serving views from jar files Hi Dan! You might take a look at Jason Lees blog if this is what you need: http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/ look at the custom ResourceResolver. You can also find this info in the JavaDoc (found the ResourceResolver trick in 2009 somewhere else too at least). LieGrue, strub --- On Fri, 12/3/10, Dan Corneanu c...@savatech.ro wrote: From: Dan Corneanu c...@savatech.ro Subject: serving views from jar files To: users@myfaces.apache.org Date: Friday, December 3, 2010, 8:15 AM Hi, I'm using JSF 2.0 (myfaces 2.0.2). I am trying to implement a modularization solution for my application. The basing idea is that I would like to be able to pack some xhtml view definitions in a jar file and put it on the classpath and be able to use this views as values of |to-view-id| in navigation rules. Is this possible? Ex. |to-view-id/plugins/foobar/foo.xhtml/to-view-id | I would like this id to be associated with an XHTML file located at jar:file:foobar.jar!/foo.xhtml I have tried to implement a custom resource loader but it seems that in the process of finding the right xhtml file to associate with a view ID, the implementation is always looking for the existence of a file on the local file system. Is there any extension point in the JSF 2.0 API that I can use in order to modify this behavior? Best regards, Dan.
