Re: facelets taglib for tomahawk and sandbox
Wow. No, I somehow missed the relevence of aliasBean on the facelets mailing list. For what it's worth, you're the first person in the history of facelets to need it, at least as far as I've read on mailing lists. Would it maybe be better to create a rendertime-compatible version of ui:include tag? It seems like trying to mix aliasBean in the mix will limit what you're able to do. Maybe that's what the component you posted does, though. On 10/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! The reason that there is no alias bean handler is because it's not needed with facelets. Still, the tag is not working as it should, so providing a tag handler will fix this. Instead you'd use a Facelets composition and ui:include statement. That is not true for my use-case. As you might have seen on the facelets user list I have to play around with dynamic includes. Means, where a backing bean provides a path to an xhtml file to an include component which gets included at render time instead of compile time. This do not always work with compile-time includes. For example, an include embedded in an dataList or dataTable. For this you can't use the ui:include as it is evaluated at compile time - you probably know :-) I've posted a component which will include another xhtml parsed JSF view at render time on the facelets user list. So for these few places in our app I have to still go the aliasBean way. Ciao, Mario
Re: facelets taglib for tomahawk and sandbox
Hey Mario,
Thanks for keeping me honest :-)
You've been correcting a number of my misconceptions recently :-)
I went back and reread your facelets thread, and it does appear to be
a good dynamic ui:include. Why not use ui:param instead of f:param?
ui:param is already defined for facelets.
On 10/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
For what it's worth, you're the first person in the history of
facelets to need it, at least as far as I've read on mailing lists.
Yep, sometimes I have some strange ideas :-)
Would it maybe be better to create a rendertime-compatible version of
ui:include tag?
That is what I have posted on the facelets user ml. I just haven't had
the time to look into a better way to pass down parameters to the include.
It definitely will be possible I think, something like
ui:dynamicInclude page=
f:param name=alias value=#{backing} /
/ui:dynamicInclude
could be done (if it is what you meant), but I do not have the time yet
to dig into this - hmmm ... when I think about it I feel it might be
really easy. But then again, not yet - for now I'll stick with the
aliasBean. The param way will be equally (un)flexible than the aliasBean
yet - in fact - under the hood both will do the same.
Ciao,
Mario
Re: [EMAIL PROTECTED] [was: facelets taglib for tomahawk and sandbox]
Once I get back to JSF work, I'd happily contribute to a MyFaces Facelets project. As I've said in years past, I don't know how to set up a maven project, but once someone set up the infrastructure for such a project, I'd be able to help with the rest. The same goes for the MyFaces commons project. If someone could set up the infrastructure, then I could start working on the rest. On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! If you, or anyone else for that matters, want to fix /add more handlers to the projects feel free to tell me and I can add you as members right away! What about a MyFaces Facelets (MyFaces MyFacelets ;-) ) project at all, not only for the taglibs we might host there then (as long as the generator is not live) but also for some Facelets dependent stuff. For example I'd start with my dynamicInclude component which allows to: 1) add xhtml fragments at render-time instead of compile-time - this is required if you'd like to include e.g. app-configured fragments to the JSF tree which might change from one request to the next. 2) add xhtml fragments to old JSP/JSF pages - this allows you to slowly migrate your app to facelets. This component is searching a home :-) Ciao, Mario
Re: [shared] trivial fix for missing serialVersionUID
Yes, wouldn't that have to be the case? Otherwise, A.jar and B.jar,
created by two independent groups, might use the same version id
without realizing it, and thus break a project depending on both of
them.
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
The stream identifier will take into account the FQCN, and the
version-identifier - so the two classes won't have the same stream
identifier, IMHO.
regards,
Martin
On 10/19/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Please consider the consequences of two different classes w/ the same stream
identifier.
Dennis Byrne
On 10/19/07, simon [EMAIL PROTECTED] wrote:
Why would that make any difference? The classes are in two different
packages
On Fri, 2007-10-19 at 14:29 -0500, Dennis Byrne wrote:
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into two
classes, one for core and one for tomahawk. When they are split, you
will have two completely classes in the JVM who have the same serial
id. I'm not going to say don't do it, but I do think we can agree
this is not a good idea?
Dennis Byrne
On 10/19/07, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'd like to make a trivial commit to add serialVersionUID
values to two classes in shared that don't yet have them. This
avoids compile warnings in IDEs that have warn on missing
serialVersionUID set.
Adding the serialVersionUID is technically the right thing to
do, IMO although in practice I agree it isn't terribly
important for these particular classes.
Any objections?
Cheers,
Simon
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(revision 586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(working copy)
@@ -74,6 +74,7 @@
public static final String SELECT_ITEM_LIST_ATTR =
RendererUtils.class.getName () + .LIST;
public static final String EMPTY_STRING = ;
public static final Object NOTHING = new Serializable() {
+private static final long serialVersionUID =
-8618356560493578754L;
};
public static final String ACTION_FOR_LIST =
org.apache.myfaces.ActionForList;
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(revision
586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(working
copy)
@@ -25,6 +25,8 @@
public class SourceCodeServlet extends HttpServlet
{
+private static final long serialVersionUID =
-2233965185519715475L;
+
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException
{
--
Dennis Byrne
--
Dennis Byrne
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [vote] start up the MyFaces Commons project
+1 :-) On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
Re: [vote] start up the MyFaces Commons project
Actually, let's clarify this to be all the stuff which is not renderkit-specific. Ie, if the validator/component/converter/other can be used with any reasonable[1] combination of JSF_RI/MyFacesCore/Tomahawk/Tobago/Trinidad/IceFaces/RichFaces/PortletBridge, then it should be available here. [1] Reasonable being that if the library in question goes out of its way to be incompatible with expected JSF behavior, then we consider including it anyway. On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
Re: [vote] start up a MyFaces Facelets project
+1. I'd suggest tomahawk-facelets[.jar] as the name since that's what it is. The versioning should match Tomahawk's versioning, and hopefully we'll release a new version each time Tomahawk is released. On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Lets start up a MyFaces Facelets project. A name needs to be found. The aim of this project will be to contain: 1) the taglibs for tomahawk and tomahawk-sandbox as long as we have the generator not running again. I'd like to ask Bruno if we can jump-start with his google project 2) everything which is directly related to stuff which only works with Facelets, being that components or whatever. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) I am not sure if we collect enough substance for this project to survive, but time will tell. Ciao, Mario
Re: MyFaces Commons project questions raised on the vote thread
Also, just to clarify for those who haven't waded through the past archives on the subject, this is mostly a structural change rather than an organizational change. The goal is to split the Tomahawk jars into renderkit-specific and non-renderkit-specific jar files so that Tobago, Seam, and other renderkit-specific projects can take advantage of what's available. On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Moving this out of the vote thread. On 10/24/07, Paul Spencer [EMAIL PROTECTED] wrote: 1) Will their be a JSF version specific version, i.e. commons_1.2 and commons_2.0? I'd say yes, if it makes sense to do so. 2) What are some of the module will you be moving into the project(s)? Some of the things I'd expect to see in here are most of the Tomahawk validators and converters, possibly t:saveState (I'd have to look at it to be sure this will work, but I think it could), and I'd like to see a t:dataList without the almost-never-used rendering part, ie, layout = simple. I'd love to see s:subForm in here, but I don't think it's possible to do this in a render-kit independent way. Maybe someone can prove me wrong, though.
Re: MyFaces Commons project questions raised on the vote thread
Moving this out of the vote thread. On 10/24/07, Paul Spencer [EMAIL PROTECTED] wrote: 1) Will their be a JSF version specific version, i.e. commons_1.2 and commons_2.0? I'd say yes, if it makes sense to do so. 2) What are some of the module will you be moving into the project(s)? Some of the things I'd expect to see in here are most of the Tomahawk validators and converters, possibly t:saveState (I'd have to look at it to be sure this will work, but I think it could), and I'd like to see a t:dataList without the almost-never-used rendering part, ie, layout = simple. I'd love to see s:subForm in here, but I don't think it's possible to do this in a render-kit independent way. Maybe someone can prove me wrong, though.
MyFaces Commons project: aliasBean
Why wouldn't aliasBean work as a commons project component? I haven't looked at the implementation, but at first glance of the docs, it doesn't seem to do anything renderkit-specific. I looked at the renderer implementation and it simply looks like its being used as a callback hook back into the component, and it's not doing any rendering. On 10/24/07, Volker Weber [EMAIL PROTECTED] wrote: Hi, +1 although the thing from tomahawk i was missing most, aliasBean, did not fit into tobagos layout system. But things like converters and validators should work with any implementation. Regards, Volker 2007/10/24, Mario Ivankovits [EMAIL PROTECTED]: Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
Re: A new approach to JSF error handling?
It would definitely be a Tomahawk thing rather than a MyFaces Core change.
I haven't looked at your architecture in detail, but trying to wrap a
validator or converter is problematic, at least under JSF 1.1 + jsp.
It will probably work for JSF 1.2 or JSF 1.1 with facelets, though, if
I remember right.
=
-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Aug 10, 2005 1:26 PM
Subject: Re: Creating a delegating validator
To: [EMAIL PROTECTED]
So it looks like those validators are getting lost when the tree is
serialized by JSF?
Also, do your validators implement stateholder? The problem is that
Facelets does the 'correct' tree building that also accomodates JSF
1.2-- with what should be happening. What you are seeing with JSP is
that the validators are probably always being assigned on every page
refresh (new) while JSF 1.2 expects the validator to be assigned only
the first time the tree is created, and then serialized as part of the
view.
=
On 10/24/07, Val [EMAIL PROTECTED] wrote:
Hi, Martin.
The change I am proposing is completely independent from Tomahawk. Since
the message decoration happens in the wrapper converter/validator, we
get to decorate any JSF message with or without Tomahawk. In fact, this
should work with any bare JSF implementation and it supersedes
Tomahawk's error-message decoration functionality.
Do you think this approach would be useful for MyFaces or is this
something that is more down Tomahawk's alley?
Val
On Wed, 2007-24-10 at 09:46 +0200, Martin Marinschek wrote:
Hi Val,
I was just referring to your code snippet, which didn't show you were
using Tomahawk. So you don't want to change JSF
error-message-handling, but Tomahawk message-handling?
regards,
Martin
On 10/19/07, Val [EMAIL PROTECTED] wrote:
Yes, I am using tomahawk 1.1.2. Specifically, I use the t:messages tag
to display my errors, which uses
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.
The code that does the replacement of input field id with the associated
label's value is in
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer. Both
getSummary() and getDetail() methods look up the associated label and
use its value if found...
Why do you think that there should be no error processing?
Val
On Fri, 2007-19-10 at 09:53 +0200, Martin Marinschek wrote:
You are not reinventing the wheel - first, are you using tomahawk?
Cause if you use the standard-components you said you use, I wonder
why you get this error-handling at all, you should only see the client
id, so like this:
'firstName': is required
regards,
Martin
On 10/18/07, Val [EMAIL PROTECTED] wrote:
Hi.
I would like to run an idea by the community to check that I am not
being crazy in doing this stuff. I would appreciate any comments,
criticism, ideas and whether you think that this approach might be
worth
including in the MyFaces implementation.
I was thinking about JSF's error processing mechanism, specifically
about how label text gets associated with an input field. So, I am
talking about this kind of stuff:
h:outputLabel for=firstName
value='#{msgs[applicant.search.firstName]}: ' /
h:inputText id=firstName
value='#{applicantDetailsBackingBean.firstName}' required=true/
If the value is not entered into the input field, we will get an error
message saying:
'First Name': is required
So HtmlMessageRenderer has replaced the field id in the FacesMessage
with the label text by using the association set up with the 'for'
attribute on the label. All of this message decoration work happens
in
the RENDER phase in a centralized location. I see a couple of
weaknesses
in this approach:
1) It is too late for resolving label text data if the label is
inside a
data table
2) JSF establishes associations between label text and the input
fields
by using the label components to point to their input fields. Although
this seems more natural, it limits label text sources to just the
label
components present on the current page (or whatever is nested under
them), which makes it impossible to associate input field messages
with
label text that does not exist on the page in its entirety.
Let's look at a couple of hypothetical examples the kinds of which I
ran
into in my application:
1) Consider a situation in which we have a dataTable where every row
consists of a student name and an input field for entering their
assignment mark. The validation on the input field will be restricted
to
valid letter grades only. If the user enters an
Re: MyFaces Commons project: aliasBean
Well, if aliasBean only works with Myfaces Core, I wonder why we even include it with Tomahawk. It sounds like it should really be an extension point of MyFaces Core. In any case, it doesn't sound like a candidate for MyFaces commons at present. On 10/24/07, Volker Weber [EMAIL PROTECTED] wrote: Hi Mike, in general i'm +1 for aliasBean into the commons project, it just did not fit into tobago. But there is a problem: afaik aliasBean did not work with RI. The myfaces lifecycleImpl has a special handling of BindingAware interface components, which are afaik only aliasBean and aliasBeanScope. I don't think this special handling is included into RI. Regards, Volker 2007/10/24, Mike Kienenberger [EMAIL PROTECTED]: Why wouldn't aliasBean work as a commons project component? I haven't looked at the implementation, but at first glance of the docs, it doesn't seem to do anything renderkit-specific. I looked at the renderer implementation and it simply looks like its being used as a callback hook back into the component, and it's not doing any rendering. On 10/24/07, Volker Weber [EMAIL PROTECTED] wrote: Hi, +1 although the thing from tomahawk i was missing most, aliasBean, did not fit into tobagos layout system. But things like converters and validators should work with any implementation. Regards, Volker 2007/10/24, Mario Ivankovits [EMAIL PROTECTED]: Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
Re: [vote] start up a MyFaces Facelets project
Andrew, you're asking for a different project than what's being proposed. This is a (hopefully) temporary project to provide drop-in Tomahawk facelets support until such time as built-in facelets support (via code generation) is available in Tomahawk. On 10/24/07, Andrew Robinson [EMAIL PROTECTED] wrote: +1 on a facelets-only JSF project and not be related to tomahawk at all. -1 for #1 I think tomahawk should have built in facelets support for its own components and not have to rely on an outside project/jar -1 on using tomahawk in the name (for above reason) (non-binding) On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote: +1. I'd suggest tomahawk-facelets[.jar] as the name since that's what it is. The versioning should match Tomahawk's versioning, and hopefully we'll release a new version each time Tomahawk is released. On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Lets start up a MyFaces Facelets project. A name needs to be found. The aim of this project will be to contain: 1) the taglibs for tomahawk and tomahawk-sandbox as long as we have the generator not running again. I'd like to ask Bruno if we can jump-start with his google project 2) everything which is directly related to stuff which only works with Facelets, being that components or whatever. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) I am not sure if we collect enough substance for this project to survive, but time will tell. Ciao, Mario
Re: [vote] start up a MyFaces Facelets project
I misread Mario's original scope for this proposal. I don't have any issues with it being more inclusive than tomahawk taglibs. My apologies to Andrew. If you are one of the people voting against a facelets subproject containing tomahawk taglibs, does this mean you are volunteering to integrate code generator facelets support directly into Tomahawk, which is the other reasonable alternative? Also, is it going to be an issue if Facelets is a dependency of Tomahawk, since Facelets depends on JSF 1.2 and JSF 1.1 api? (I don't think so, but I figured I'd mention it in case I'm wrong). MyFacelets is a cute name, but it's going to be confusing and slow to read. Human brains work on pattern matching, and MyFacelets matches too closely to other names in the domain (MyFaces/Facelets). Aend iff youuu donnt thynk tahts turrue, yooo porabably kant reed thhis. MyFaces MyFaces MyFaces MyFacelets MyFaces MyFacelets Facelets MyFacelets MyFaces.
Re: A new approach to JSF error handling?
On 10/24/07, Val [EMAIL PROTECTED] wrote: I handled the addition of a converter or validators into the wrapper by having my custom tag push a dummy UIInput tag onto the tag stack that UIComponentTag uses and then having the wrapped converter/validators set themselves up in the dummy component on the top of the stack as they usually do (no changes there). Then when we come back up to the doEndTag() of my wrapper custom tag, I simply steal all the validator/converter info from my dummy UIInput and apply it to the wrapper, which then applies itself to the actual parent UIInput. So this adds a level of indirection, but it is entirely handled by the custom tag during page compilation. This way it works out to be fairly non intrusive. What problems with JSF 1.1 + jsp did you have in mind? Well, it's been two-and-a-half years, but I seem to remember the problem was that under JSF 1.1 + jsp, the converters and validators are created from scratch every request rather than restored using the JSF state-saving mechanism. So all of the values set on the converters/validators would be lost the next request. Also, a question on mailing list protocol, if you don't mind. This is my first attempt at participating in developer mailing lists so I am uncertain what would be a more appropriate way to show this thing to Tomahawk guys - reposting the whole thing in the tomahawk list, or referencing the post I made here? This is both the MyFaces Core and MyFaces Tomahawk mailing list. So you don't need to repost it. My comment was that, structurally, this patch would be a candidate for the Tomahawk project, but would not be a candidate for the MyFace Core project. In fact, it might fit in with the newly-proposed (earlier today) MyFaces Commons project better since it doesn't seem to be dependent on any particular renderkit.
Re: A new approach to JSF error handling?
Yes, but your wrapping validator doesn't have the ability to save the state of the wrapped validator, does it? Sorry. I really don't remember the details, but I would expect Myfaces 1.1.x to still have the same problem. Perhaps we were just doing it wrong back then, though :-) The process would be to discuss it here on the dev list (which you are doing) and get feedback, then at some point open a JIRA issue and attach a patch to provide your contribution. The MyFaces developers would be the collective judge of any decision. I'd say there's no reason why we wouldn't accept this contribution since it's frequently-asked-for functionality and the implementation seems to fit with JSF architecture easily enough. On 10/24/07, Val [EMAIL PROTECTED] wrote: Well, it's been two-and-a-half years, but I seem to remember the problem was that under JSF 1.1 + jsp, the converters and validators are created from scratch every request rather than restored using the JSF state-saving mechanism. So all of the values set on the converters/validators would be lost the next request. Hmm, I am using MyFaces 1.1.3. That's JSF 1.1, right? The code in UIInput explicitly calls saveAttachedState() on the validators and converter, so I guess that problem was fixed. In fact, it might fit in with the newly-proposed (earlier today) MyFaces Commons project better since it doesn't seem to be dependent on any particular renderkit. ooh, nice - I like the idea of a commons project. And yeah, that looks like the place where my framework could fit into. So, now my ignorance of the Apache development process comes into play again. Assuming that this change would be welcome in the MyFaces Commons project (who would be the judge of that, btw?), what do I need to do to get it there? Since I am not a regular contributor, I suspect I can't just check it in :), so what is the proper process? Thanks. Val On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote: On 10/24/07, Val [EMAIL PROTECTED] wrote: I handled the addition of a converter or validators into the wrapper by having my custom tag push a dummy UIInput tag onto the tag stack that UIComponentTag uses and then having the wrapped converter/validators set themselves up in the dummy component on the top of the stack as they usually do (no changes there). Then when we come back up to the doEndTag() of my wrapper custom tag, I simply steal all the validator/converter info from my dummy UIInput and apply it to the wrapper, which then applies itself to the actual parent UIInput. So this adds a level of indirection, but it is entirely handled by the custom tag during page compilation. This way it works out to be fairly non intrusive. What problems with JSF 1.1 + jsp did you have in mind? Well, it's been two-and-a-half years, but I seem to remember the problem was that under JSF 1.1 + jsp, the converters and validators are created from scratch every request rather than restored using the JSF state-saving mechanism. So all of the values set on the converters/validators would be lost the next request. Also, a question on mailing list protocol, if you don't mind. This is my first attempt at participating in developer mailing lists so I am uncertain what would be a more appropriate way to show this thing to Tomahawk guys - reposting the whole thing in the tomahawk list, or referencing the post I made here? This is both the MyFaces Core and MyFaces Tomahawk mailing list. So you don't need to repost it. My comment was that, structurally, this patch would be a candidate for the Tomahawk project, but would not be a candidate for the MyFace Core project. In fact, it might fit in with the newly-proposed (earlier today) MyFaces Commons project better since it doesn't seem to be dependent on any particular renderkit.
Re: A new approach to JSF error handling?
Hmm. I honestly don't remember calling saveAttachedState() -- maybe that was my problem :-) Good to know for the future if it ever comes up again. You can create a JIRA issue for it at any time. Just open it under TOMAHAWK and set it to NEW COMPONENT. If we decide to make a COMMONS or FACELETS jira project (and I don't really think we'll do that), we'll migrate the issue at that time. We're also proposing a new MyFaces facelets project -- that's probably where your facelets code will end up. At some point, we'll hopefully merge it all together, but we're not at that point yet. On 10/24/07, Val [EMAIL PROTECTED] wrote: Yes, but your wrapping validator doesn't have the ability to save the state of the wrapped validator, does it? All I needed to do here was make my wrapping validator a StateHolder and call saveAttachedState() on the wrapped validators. So everything is saved and restored properly this way. then at some point open a JIRA issue and attach a patch to provide your contribution. Since this will probably go into MyFaces Commons, I guess I will need to wait until that project is created, before I can make a patch for it. I am also wondering where I would put the custom tag's Facelets counterpart (the custom MetaTagHandler). Does MyFaces provide any Facelets related code? Or would this be more of a documentation item saying that If you want to use this with facelets, paste this code in? Val On Wed, 2007-24-10 at 17:52 -0400, Mike Kienenberger wrote: Yes, but your wrapping validator doesn't have the ability to save the state of the wrapped validator, does it? Sorry. I really don't remember the details, but I would expect Myfaces 1.1.x to still have the same problem. Perhaps we were just doing it wrong back then, though :-) The process would be to discuss it here on the dev list (which you are doing) and get feedback, then at some point open a JIRA issue and attach a patch to provide your contribution. The MyFaces developers would be the collective judge of any decision. I'd say there's no reason why we wouldn't accept this contribution since it's frequently-asked-for functionality and the implementation seems to fit with JSF architecture easily enough. On 10/24/07, Val [EMAIL PROTECTED] wrote: Well, it's been two-and-a-half years, but I seem to remember the problem was that under JSF 1.1 + jsp, the converters and validators are created from scratch every request rather than restored using the JSF state-saving mechanism. So all of the values set on the converters/validators would be lost the next request. Hmm, I am using MyFaces 1.1.3. That's JSF 1.1, right? The code in UIInput explicitly calls saveAttachedState() on the validators and converter, so I guess that problem was fixed. In fact, it might fit in with the newly-proposed (earlier today) MyFaces Commons project better since it doesn't seem to be dependent on any particular renderkit. ooh, nice - I like the idea of a commons project. And yeah, that looks like the place where my framework could fit into. So, now my ignorance of the Apache development process comes into play again. Assuming that this change would be welcome in the MyFaces Commons project (who would be the judge of that, btw?), what do I need to do to get it there? Since I am not a regular contributor, I suspect I can't just check it in :), so what is the proper process? Thanks. Val On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote: On 10/24/07, Val [EMAIL PROTECTED] wrote: I handled the addition of a converter or validators into the wrapper by having my custom tag push a dummy UIInput tag onto the tag stack that UIComponentTag uses and then having the wrapped converter/validators set themselves up in the dummy component on the top of the stack as they usually do (no changes there). Then when we come back up to the doEndTag() of my wrapper custom tag, I simply steal all the validator/converter info from my dummy UIInput and apply it to the wrapper, which then applies itself to the actual parent UIInput. So this adds a level of indirection, but it is entirely handled by the custom tag during page compilation. This way it works out to be fairly non intrusive. What problems with JSF 1.1 + jsp did you have in mind? Well, it's been two-and-a-half years, but I seem to remember the problem was that under JSF 1.1 + jsp, the converters and validators are created from scratch every request rather than restored using the JSF state-saving mechanism. So all of the values set on the converters/validators would be lost the next request. Also, a question on mailing list protocol, if you don't mind. This is my first attempt at participating in developer mailing lists so I am uncertain what
Re: svn commit: r576248 - in /myfaces/tomahawk/trunk/core/src: main/java/org/apache/myfaces/convert/ main/resources-facesconfig/META-INF/ site/ site/xdoc/ test/java/org/apache/myfaces/convert/
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference to it is the commit itself.
-Mike
On 9/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: dennisbyrne
Date: Sun Sep 16 20:30:22 2007
New Revision: 576248
URL: http://svn.apache.org/viewvc?rev=576248view=rev
Log:
three new Converters, three tests, and documentation
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicLongConverter.java
myfaces/tomahawk/trunk/core/src/site/xdoc/atomicConversion.xml
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicBooleanConverterTestCase.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicIntegerConverterTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicLongConverterTest.java
Modified:
myfaces/tomahawk/trunk/core/src/main/resources-facesconfig/META-INF/faces-config.xml
myfaces/tomahawk/trunk/core/src/site/site.xml
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java?rev=576248view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
Sun Sep 16 20:30:22 2007
@@ -0,0 +1,39 @@
+package org.apache.myfaces.convert;
+
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import javax.faces.component.UIComponent;
+import javax.faces.context.FacesContext;
+import javax.faces.convert.Converter;
+import javax.faces.convert.ConverterException;
+
+public class AtomicBooleanConverter implements Converter {
+
+ public Object getAsObject(FacesContext ctx, UIComponent ui, String
string) {
+
+ return string != null string.trim().length() 0 ?
+ new
AtomicBoolean(Boolean.parseBoolean(string.trim())) : null;
+ }
+
+ public String getAsString(FacesContext ctx, UIComponent ui, Object
object) {
+
+ String string = ;
+
+ if( object != null ) {
+
+ if(object instanceof String) {
+ string = (String) object;
+ }else if(object instanceof AtomicBoolean){
+ string = ((AtomicBoolean)object).toString();
+ }else {
+ throw new ConverterException(Received an
instance of
+ + object.getClass().getName()
+ , but was expecting an instance of
+ +
AtomicInteger.class.getName());
+ }
+ }
+
+ return string;
+ }
+
+}
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java?rev=576248view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
Sun Sep 16 20:30:22 2007
@@ -0,0 +1,49 @@
+package org.apache.myfaces.convert;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+import javax.faces.component.UIComponent;
+import javax.faces.context.FacesContext;
+import javax.faces.convert.Converter;
+import javax.faces.convert.ConverterException;
+
+public class AtomicIntegerConverter implements Converter {
+
+ public Object getAsObject(FacesContext ctx, UIComponent ui, String
value) {
+
+ Object object = null;
+
+ if( value != null value.trim().length() 0 ) {
+ try
+ {
+ object = new
AtomicInteger(Integer.parseInt(value.trim()));
+
+ }catch(NumberFormatException nfe) {
+ throw new
Re: Refactoring of tomahawk project (spawned from facelets discussion)
Should this also include myfaces-commons? I would expect Tomahawk to build on myfaces-commons especially now that we're talking about putting the common programming utilities into it, but I don't know if that means it should be part of the Tomahawk super-project. Second, JSF 1.1 requires jdk 1.4. (Maybe even 1.3, but I don't think anyone is using 1.3 with JSF). Currently, there's only one item in Tomahawk that requires 1.5, and I'm about to revert it due to the 1.5 incompatibility (and due to the fact it should never have been put into tomahawk the way it was in the first place). The primary reason I'm still using JSF 1.1 is that Java 1.5 is only now being phased in at my JSF client site. On 10/27/07, Andrew Robinson [EMAIL PROTECTED] wrote: I would like to propose the following refactoring of the tomahawk project under myfaces Current structure under tomahawk: trunk/ assembly (for building releases) core (tomahawk core) examples (examples for the core project) sandbox (sandbox) sandbox15 (Sandbox with JDK 1.5 dependency) pom.xml Proposed change: trunk/ core/ assembly/ tomahawk-build/ tomahawk-api/ tomahawk-impl/ tomahawk-facelets/ sandbox/ assembly/ sandbox-build/ sandbox-api/ sandbox-impl/ sandbox-facelets/ branches/ jsf-1.2/ current/ core/ assembly/ tomahawk-build/ tomahawk-api/ tomahawk-impl/ tomahawk-facelets/ sandbox/ assembly/ sandbox-build/ sandbox-api/ sandbox-impl/ sandbox-facelets/ (Releases here - ex 1.1.7) jdk-1.5/ current/ core/ assembly/ tomahawk-build/ tomahawk-api/ tomahawk-impl/ tomahawk-facelets/ sandbox/ assembly/ sandbox-build/ sandbox-api/ sandbox-impl/ sandbox-facelets/ (Releases here - ex 1.1.7) jsf-2.0 (future)/ Along with this change will be migration to use the maven faces plug-in for component generation. This will facilitate the inclusion of facelets support. The plug-in would be based on the current myfaces generator that is being used for myfaces core 1.2 and re-factored to use 1.1. The jsf-1.2 branch can use the existing files, with possible modifications as required. The sandbox15 becomes a separate release of the sandbox with 1.5 code added. I see this being much more flexible than a separate jar. This way tomahawk core classes can be made to support JDK 1.5 as desired. Question: is the branch for JDK 1.5 on JSF 1.1 required, or should the JSF 1.2 branch be used for this code instead? I don't have a whole lot of time, but I am willing to put some work in to help split the projects out and setup the maven plug-in part. Other help would be needed. If people agree, I see this as a phased approach: 1) Create a new branch under tomahawk to house the work in progress. 2) Modify the myfaces code in the maven-faces-plugin to support JSF 1.1 (configuration support is already there, the plug-in just doesn't use it) 3) Setup the tomahawk-build core project xml files 4) create an SVN tag as the branch point 5) starting moving core over 6) repeat 3-5 for the sandbox 7) repeat 3-5 for a jsf-1.2 branch and optionally the jdk-1.5 branch. 8) (in parallel to 1-7): update the framework for nightly builds, and any changes to the system that would need to be made for these changes. Opinions? -Andrew
Re: [vote] start up the MyFaces Commons project
Yes, this is perhaps another reason why this might best be placed under Tomahawk. We already have a Tomahawk sandbox in place for both Jdk 1.5 and pre-1.5. Once a sandbox component is ready for promotion, part of the evaluation could be deciding if it should go into the works-with-anything commons project or the less-compatible Tomahawk project. On 10/27/07, Andrew Robinson [EMAIL PROTECTED] wrote: On 10/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Yes, we need to be careful about what goes in. And we should agree on some rules here. Is lazy consensus enough? Or should every addition require an official vote (on a regarding jira issue)? My opinion on this would be to have a sandbox where components can be put without vote, and only with an official vote get included in the official branch.
Re: [vote] start up the MyFaces Commons project
Manfred, I think we're using the same terminology to mean different
things, which is what I was afraid of.
The project Mario/Volker/Myself/others proposed was for
renderkit-independent components, not for common programming apis.
Ie, the goal is to make available to Tobago and Trinidad those parts
of Tomahawk which are not incompatible. Also, it's to move such
things out of Tobago (and maybe Trinidad) into a common place (like
the non-Faces-request-processor-servlet-filter).
Perhaps we still need to work out naming conventions, but let's be
clear that the proposed purpose of this project proposal deals with
components not apis.
On 10/27/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Yes, we need to be careful about what goes in. And we should agree on
some rules here. Is lazy consensus enough? Or should every addition
require an official vote (on a regarding jira issue)?
Mike, the original intention of the jsf commons project was a
collection of useful jsf stuff (helpers and utilities) that is
convenient for component and application (and jsf implementation)
developers. This includes renderkit (html) specific stuff. There is no
harm in html specific stuff as long as it is really useful for many
people and it is located in a clearly separated java package.
Having common (renderkit independent) components was not the primary
goal AFAIR. I'd rather see these in another new project: something
like MyFaces Base Components
WDYT?
--Manfred
On 10/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think we're starting to confuse the focus here.
There's a difference between common components that can be used with
any JSF project, and common programming utilities, many of which may
be renderkit (like html) specific.
I'm ok with common programming utilities being in this project, but
we're going to need to be careful regarding what we put into it. But
we do need to be careful about what goes in it.
On 10/27/07, Manfred Geiler [EMAIL PROTECTED] wrote:
+1
But to avoid common design mistakes I propose some additional
issues/prerequisites:
1. Clear separation of API and IMPL (at least on package level, better
by separate artifacts). Mind that the idea behind these commons
classes is that many other projects use them - and therefore depend on
them. So a clear and stable API is essential.
2. Let's start to name svn folders the same as the artifacts. This
seems to be best practice in many other maven projects. And there are
good reasons to do this.
So, the new project should be located in a folder named like
myfaces-commons with two sub folders myfaces-commons-api and
myfaces-commons-impl.
BTW, some other candidates for commons classes are trivial utils
like this one:
public static void doNavigation(String outcome) {
FacesContext facesContext = FacesContext.getCurrentInstance();
NavigationHandler navigationHandler =
facesContext.getApplication().getNavigationHandler();
navigationHandler.handleNavigation(facesContext, null, outcome);
}
Yes, no big deal. But convenient, though, to have this code in one
good place instead of inventing a new JSFUtils class for every new
customer project... ;-)
-Manfred
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Lets start up the long awaited MyFaces Commons project.
The aim of this project will be to contain all stuff which do not belong
to a component.
[ ] +1 yea, lets start
[ ] +0
[ ] -1 no, for those reasons .
I'll do the maven work then (a not very sophisticated one, just copy it
from another of our modules)
Ciao,
Mario
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
Re: svn commit: r576248 - in /myfaces/tomahawk/trunk/core/src: main/java/org/apache/myfaces/convert/ main/resources-facesconfig/META-INF/ site/ site/xdoc/ test/java/org/apache/myfaces/convert/
No discussion/action taken by original committer -- reverting.
Note that I think these converters would be a good candidate for
sandbox15 and Tomahawk 1.2, and I recommend checking them back into
that location.
On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
good point.
On 10/25/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference to it is the commit itself.
-Mike
On 9/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: dennisbyrne
Date: Sun Sep 16 20:30:22 2007
New Revision: 576248
URL: http://svn.apache.org/viewvc?rev=576248view=rev
Log:
three new Converters, three tests, and documentation
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicLongConverter.java
myfaces/tomahawk/trunk/core/src/site/xdoc/atomicConversion.xml
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicBooleanConverterTestCase.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicIntegerConverterTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/convert/AtomicLongConverterTest.java
Modified:
myfaces/tomahawk/trunk/core/src/main/resources-facesconfig/META-INF/faces-config.xml
myfaces/tomahawk/trunk/core/src/site/site.xml
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java?rev=576248view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicBooleanConverter.java
Sun Sep 16 20:30:22 2007
@@ -0,0 +1,39 @@
+package org.apache.myfaces.convert;
+
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import javax.faces.component.UIComponent;
+import javax.faces.context.FacesContext;
+import javax.faces.convert.Converter;
+import javax.faces.convert.ConverterException;
+
+public class AtomicBooleanConverter implements Converter {
+
+ public Object getAsObject(FacesContext ctx, UIComponent ui,
String string) {
+
+ return string != null string.trim().length() 0 ?
+ new
AtomicBoolean(Boolean.parseBoolean(string.trim())) : null;
+ }
+
+ public String getAsString(FacesContext ctx, UIComponent ui,
Object object) {
+
+ String string = ;
+
+ if( object != null ) {
+
+ if(object instanceof String) {
+ string = (String) object;
+ }else if(object instanceof AtomicBoolean){
+ string =
((AtomicBoolean)object).toString();
+ }else {
+ throw new ConverterException(Received an
instance of
+ +
object.getClass().getName() + , but was expecting an instance of
+ +
AtomicInteger.class.getName());
+ }
+ }
+
+ return string;
+ }
+
+}
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java?rev=576248view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/convert/AtomicIntegerConverter.java
Sun Sep 16 20:30:22 2007
@@ -0,0 +1,49 @@
+package org.apache.myfaces.convert;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+import javax.faces.component.UIComponent;
+import javax.faces.context.FacesContext;
+import javax.faces.convert.Converter;
+import
Re: JSF 2
And in case you somehow missed the other messages (which is why Matthias started this thread), I've now reverted this from Tomahawk due to Java 1.5 dependencies (and a lack of discussion beforehand). For now, I'd recommend either committing it to sandbox15 or to MyFaces 1.2. On 10/26/07, Dennis Byrne [EMAIL PROTECTED] wrote: This was on the 1.1 branch. I agree, it would be nice to have in this in JSF 2.0. It's hard to beat Caucho :( Dennis Byrne On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: wouldn't it make sense to have that on standard, instead of tomahawk / sandbox? On 10/26/07, Dennis Byrne [EMAIL PROTECTED] wrote: I committed this to Tomahawk a few weeks ago. Dennis Byrne On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, do you guys plan to support converters for the Numbers in package java.util.concurrent.atomic, like AtomicLong or AtomicInteger ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: [vote] start up the MyFaces Commons project
No, it's not. There are components in Tomahawk that depend on javascript. There are components in tomahawk that depend on MyFaces core (aliasBean). There are components in Tomahawk that depend on dojo. There are components in Tomahawk that depends on the MyFaces form. Right now, Tomahawk is a mix of many different things, some of which are useful in Tobago and most of which are not useful in Tobago. Again, I think that this project makes more sense as a subproject of Tomahawk (the truely-independent-works-anywhere part) rather than as a separate project. But the hope is that we will produce a components-that-work-anywhere.jar which can be dropped into Tobago or Trinidad or WAP or Seam or Xforms-renderkit or Swing-Renderkit or whatever. On 10/27/07, Andrew Robinson [EMAIL PROTECTED] wrote: The project Mario/Volker/Myself/others proposed was for renderkit-independent components, not for common programming apis. Isn't this what tomahawk already is?
Re: [result][vote] start up the MyFaces Commons project
I don't think there's any hard rule that all projects have to be prefixed with MyFaces. But then, I also don't have any problem with it being associated with Tomahawk or MyFaces (in the name). On 10/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I agree that MyFaces Basics is too MyFaces-Core-esque.Tomahawk Basics or JSF Basics would be better choices. Hmmm ... I think the MyFaces JSF Basics is the only option then. As far as I know the token MyFaces needs to be in there as it is a project of the MyFaces project. Personally I think the token tomahawk suggest that the Basic module is meant as something related to tomahawk only then. Also we should clearly state in the future that the term MyFaces does not not necessarily mean a module works only with the MyFaces JSF implementation nor with tomahawk only. But I think this is something we already do as good as we can, e.g. with Apache MyFaces Trinidad, Apache MyFaces Orchestra. Btw, Tobago is an exception here, they call their project just Tobago instead of Apache MyFaces Tobago as it should be ... I think. Ciao, Mario
Re: restructuring of MyFaces Tomahawk SVN
From what little I understand of maven, this looks like a good idea. However, I think that with the proposal of a MyFaces Basics/Commons project and a MyFaces Facelets project, that Tomahawk restructuring should wait a few days. I'm still not seeing any consensus on what these projects are going to contain or look like. It seems like everyone has a slightly-different idea. I'd recommend that we postpone redesigning Tomahawk's layout until we know how these two pieces are going to fit in. A lack of feedback is probably not a sufficient reason to push forward for a major restructuring. On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Well, there really hasn't been any feedback on this thread: Original thread: Refactoring of tomahawk project (spawned from facelets discussion) Link: http://tinyurl.com/2gnpqd So I figure that no news is good news? I'd like to take a vote/poll so that we can move this issue along and see if we can get Tomahawk with Facelets support. Vote: [ ] +1 for those that have reviewed the new folder structure and approve of it [ ] +0 for those not against it or necessarily for it [ ] -1 for those that oppose it and reasons and suggested changes to the structure. -Andrew
Re: [Orchestra] TODO in UrlParameterNavigationHandler
Note: pure speculation.
Possibly it's due to the misunderstanding that the #{blah} part of
the string is the EL expression.
Any string is an EL expression, and #{} is simply one operator that
can be used in that string. So #{a} text #{b} text #{c} is one EL
expression, not three.
On 10/30/07, David Brainard [EMAIL PROTECTED] wrote:
Hi,
i was looking into the UrlParameterNavigationHandler class i saw a TODO
with the following comments
// TODO: this only supports one EL expression at the moment; it would be
nice
// to support multiple.
protected String interceptRedirect(FacesContext context, String url)
But when i tried to use multiple el expressions in faces-config it seems
that it is wrking fine
my faces-config entry and the URL
navigation-rule
display-nameMain/display-name
from-view-id/Main.jsp/from-view-id
navigation-case
from-outcomeredirect/from-outcome
to-view-id/Redir.jsp?navValue=#{testBean.navValue}amp;navValue1=#{testBean.navValue1}/to-view-id
redirect /
/navigation-case
/navigation-rule
http://localhost:8080/Tomahawk/faces/Redir.jsp?navValue=1768707082navValue1=998817167
navValue and navValue1 are the two parameters..
what i am doin is right???
pls comment..
if it is so i can add sme javadocs and delete the TODO as a patch.
Regards
David Brainard Sounthiraraj
Re: [result][vote] start up the MyFaces Commons project
Well, I think there's probably enough difference between the two goals that we do need to separate projects, even though it contributes to the Yet Another MyFaces Subproject quagmire. At least it's a step in the right direction since we're looking at merging common code rather than futher separation. Let's leave the components - api dependency out until such time that it's explicitly needed. On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
We're discussing two completely different concepts here. One is an api for writing new components. For component developers. One is a library of common renderkit-independent components for use in JSF applications. For application developers. Attempting to combine them is going to shortchange one side or the other. Either the library is going to end up with dependencies on renderkit-specific stuff, or the api is going to be severely limited in what it provides. On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: Hi, i don't understand what should go into the utils and what into the components parts. I think we can mix static utils with renderkid independent components in one library. for renderkid dependend compeonents we have already tomahawk, tobago and trinidad. Regards, Volker 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Core 1.1.5 patch for Weblogic
Please open a JIRA issue and attach your changes as a unified diff patch.
-Mike
On Nov 20, 2007 9:47 AM, Vorobjov, Dmitriy (DB) [EMAIL PROTECTED] wrote:
Guys,
I implemented TODO null-check for Weblogic, that tries to initialize
Servlet before ContextListener in FacesServlet class (line 92).
And tested it with Weblogic 10. It works fine.
This is changes for MyFaces Core 1.1.5, FacesServlet class.
try {
_facesContextFactory =
(FacesContextFactory)FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
} catch (IllegalStateException e) {
log.trace(reinit StartupServletContextListener);
//It's patch for Weblogic, that tries to initialize Servlet
before ContextListener
ServletContext sc = servletConfig.getServletContext();
clearFacesInitFlag(sc);
StartupServletContextListener.initFaces(sc);
_facesContextFactory =
(FacesContextFactory)FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
}
private void clearFacesInitFlag(ServletContext sc) {
sc.setAttribute(StartupServletContextListener.class.getName() +
.FACES_INIT_DONE, null);
}
Could you integrate changes in MyFaces Core 1.1.5.
Here is full FacesServlet class listing (changes marked with bold):
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package javax.faces.webapp;
import java.io.IOException;
import javax.faces.FacesException;
import javax.faces.FactoryFinder;
import javax.faces.context.FacesContext;
import javax.faces.context.FacesContextFactory;
import javax.faces.lifecycle.Lifecycle;
import javax.faces.lifecycle.LifecycleFactory;
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.myfaces.webapp.StartupServletContextListener;
/**
* see Javadoc of a
href=http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/index.html;JSF
Specification/a
*
* @author Manfred Geiler (latest modification by $Author: vorodmi $)
* @version $Revision: #1 $ $Date: 2007/11/16 $
*/
public final class FacesServlet
implements Servlet
{
private static final Log log = LogFactory.getLog(FacesServlet.class);
public static final String CONFIG_FILES_ATTR =
javax.faces.CONFIG_FILES;
public static final String LIFECYCLE_ID_ATTR =
javax.faces.LIFECYCLE_ID;
private static final String SERVLET_INFO = FacesServlet of the MyFaces
API implementation;
private ServletConfig _servletConfig;
private FacesContextFactory _facesContextFactory;
private Lifecycle _lifecycle;
public FacesServlet()
{
super();
}
public void destroy()
{
_servletConfig = null;
_facesContextFactory = null;
_lifecycle = null;
if(log.isTraceEnabled()) log.trace(destroy);
}
public ServletConfig getServletConfig()
{
return _servletConfig;
}
public String getServletInfo()
{
return SERVLET_INFO;
}
private String getLifecycleId()
{
String lifecycleId =
_servletConfig.getServletContext().getInitParameter(LIFECYCLE_ID_ATTR);
return lifecycleId != null ? lifecycleId :
LifecycleFactory.DEFAULT_LIFECYCLE;
}
public void init(ServletConfig servletConfig)
throws ServletException
{
if(log.isTraceEnabled()) log.trace(init begin);
_servletConfig = servletConfig;
try {
_facesContextFactory =
(FacesContextFactory)FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
} catch (IllegalStateException e) {
log.trace(reinit StartupServletContextListener);
Re: Rendering amp; instead of for href attribute
For html, I think we should continue to render . For xhtml, we should render amp; On Nov 21, 2007 7:37 AM, Manfred Geiler [EMAIL PROTECTED] wrote: Please have a look at http://issues.apache.org/jira/browse/MYFACES-1774 Do you think there is a problem with generally rendering amp; instead of ? Issues with old browsers perhaps? Thanks, Manfred
Re: SortableModel and t:dataTable changes/improvements
It was left that way to provide identical backward compatible behavior.
However, you should be able to subclass (or use) BaseSortableModel
instead of the default sortable model.
On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:
That's a very good idea. However, in the latest svn sources the HtmlDataTable
component still uses SortableModel class to set the current sort column.
Wouldn't be normal to use BaseSortableModel class to allow extensibility?
Thanks.
Mike Kienenberger wrote:
As a first step in this process, I've separated SortableDataModel into
SortableDataModel (current behavior, final, subclass of
BaseSortableDataModel) and BaseSortableDataModel (extendable, works on
Comparators).
I tested all of the simple examples involving dataTable at one point,
but it's possible that something may have slipped by me that I didn't
notice.
On 3/14/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
I took a look at SortableModel and t:dataTable sorting again last
night. My requirements in most cases are to simply specify a sort
order in the page code, not to allow end-users to manipulate the sort
order.From what I can tell, there's no easy way to do this. I
documented the most effective method I could find on the wiki under a
static sorting subheading, but even that method leaves unnecessary
links in the column headers.
At the same time, I looked into what it would take to make sorting
cleaner and more user-friendly.
I came up with a subclass of extended dataTable and a replacement
SortableModel that did what I wanted for the most part:
my:sortableDataTable
preserveDataModel=true
value=#{bean.carList}
var=car
f:facet name=comparator
my:propertyComparator
property=style.color
descending=true /
/f:facet
/my:sortableDataTable
This is based in part on reusing my components for sorting selectItem
lists. For some reason, couldn't make this work without using
preserveDataModel. [Strangely enough, doing the same thing with the
current t:dataTable sort attributes didn't require preserveDataModel.]
In any case, a comparator component can be any UIComponent that
implements a ComparatorSource interface (ie, public Comparator
getComparator()), which provides a great deal of flexibility.
The propertyComparator implementation basically does the same thing as
the internal guts of the current SortableModel, but is pluggable. I
used beanutils in my comparator rather than EL to process the property
expression, which also eliminates the rowObjectGet hack. An EL
comparator could be implemented if the EL processing features were
needed.
I think it would be worthwhile to replace the current SortableModel
with a more generic pluggable one. A good start would be to pull all
of the property-resolving/comparison out of it, and stick it into a
comparator like I did. setSortCriteria(List criteria) appears to be
misnomer since only the first item in the list is used -- using a
comparator would also solve that issue as you can create
MultipleComparator that takes a list of other comparators and goes
through them in order.
Following is what DataTable looks like to make this work. Note that
this doesn't handle the current sorting options.
protected DataModel createDataModel()
{
DataModel dataModel = super.createDataModel();
UIComponent comparatorUIComponent = getComparator();
Comparator comparator = null;
if (null != comparatorUIComponent)
{
if (comparatorUIComponent instanceof ComparatorSource)
{
comparator =
((ComparatorSource)comparatorUIComponent).getComparator();
}
else
{
// TODO: need log error instead
throw new RuntimeException(comparatorUIComponent
should
implement ComparatorSource);
}
}
boolean isSortable = null != comparator;
if (isSortable)
{
if (!(dataModel instanceof BaseSortableModel))
{
dataModel = new BaseSortableModel(dataModel);
}
((BaseSortableModel)dataModel).setComparator(comparator);
}
return dataModel;
}
After stripping out the comparator stuff from SortableModel, these are
the major changes:
public void setComparator(Comparator _comparator) {
this._comparator = _comparator;
_sort();
}
private void _sort()
{
if (null == _comparator)
{
// restore unsorted order:
_baseIndicesList = _sortedIndicesList = null;
return
Re: SortableModel and t:dataTable changes/improvements
Tomahawk's t:dataTable requires SortableDataModel, which is why that
check is in here. At some point I'd love to see that requirement
relaxed, but no one has done further work toward that end.
I think the easiest thing to do right now is to subclass HtmlDataTable
and override createDataModel.
This is how I did it.
package test;
import java.util.Comparator;
import javax.faces.component.UIComponent;
import javax.faces.model.DataModel;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.myfaces.component.html.ext.HtmlDataTable;
/**
* @author Mike Kienenberger (latest modification by $Author: mlk $)
* @version $id$
*/
public class SortableHtmlDataTable extends HtmlDataTable
{
private static final Log log =
LogFactory.getLog(SortableHtmlDataTable.class);
public static final String COMPARATOR_FACET_NAME = comparator;
/**
* @see
org.apache.myfaces.component.html.ext.HtmlDataTableHack#createDataModel()
*/
protected DataModel createDataModel()
{
DataModel dataModel = super.createDataModel();
UIComponent comparatorUIComponent = getComparator();
Comparator comparator = null;
if (null != comparatorUIComponent)
{
if (comparatorUIComponent instanceof ComparatorSource)
{
comparator =
((ComparatorSource)comparatorUIComponent).getComparator();
}
else
{
// TODO: need log error instead
throw new RuntimeException(comparatorUIComponent should
implement ComparatorSource);
}
}
boolean isSortable = null != comparator;
if (isSortable)
{
if (!(dataModel instanceof BaseSortableModel))
{
dataModel = new BaseSortableModel(dataModel);
}
((BaseSortableModel)dataModel).setComparator(comparator);
}
return dataModel;
}
/**
* Gets the comparator facet for sorting.
*/
public UIComponent getComparator() {
return (UIComponent)getFacets().get(COMPARATOR_FACET_NAME);
}
public void setComparator(UIComponent comparator) {
getFacets().put(COMPARATOR_FACET_NAME, comparator);
}
//-- GENERATED CODE BEGIN (do not modify!)
public static final String COMPONENT_TYPE = test.SortableHtmlDataTable;
public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Table;
}
On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:
I can subclass it of course, but because HtmlDataTable (in createDataModel
method) checks if the DataModel is an instance of SortableDataModel, it will
actually wrap my extended BaseSortableModel into a SortableModel, that will
not use my custom defined comparator.
I would expect that HtmlDataTable to use only BaseSortableModel and every
time a column header link is clicked to notify me by which column the data
to be sorted.
Or maybe I got it wrong. Could you explain in few words how would you
implement a custom sortable model starting from BaseSortableModel?
Thanks.
Catalin
Mike Kienenberger wrote:
It was left that way to provide identical backward compatible behavior.
However, you should be able to subclass (or use) BaseSortableModel
instead of the default sortable model.
On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:
That's a very good idea. However, in the latest svn sources the
HtmlDataTable
component still uses SortableModel class to set the current sort column.
Wouldn't be normal to use BaseSortableModel class to allow extensibility?
Thanks.
Mike Kienenberger wrote:
As a first step in this process, I've separated SortableDataModel into
SortableDataModel (current behavior, final, subclass of
BaseSortableDataModel) and BaseSortableDataModel (extendable, works on
Comparators).
I tested all of the simple examples involving dataTable at one point,
but it's possible that something may have slipped by me that I didn't
notice.
On 3/14/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
I took a look at SortableModel and t:dataTable sorting again last
night. My requirements in most cases are to simply specify a sort
order in the page code, not to allow end-users to manipulate the sort
order.From what I can tell, there's no easy way to do this. I
documented the most effective method I could find on the wiki under a
static sorting subheading, but even that method leaves unnecessary
links in the column headers.
At the same time, I looked into what it would take to make sorting
cleaner and more user-friendly.
I came up with a subclass of extended dataTable and a replacement
SortableModel that did what I wanted for the most part:
my:sortableDataTable
preserveDataModel=true
Re: MyFaces JSF Commons Project
If you're going to support 1.1, support 1.4. Otherwise, just stick with JSF 1.2. I know where I do my primary JSF work, the major holdup has been JDK 1.5, which was only recently adopted, not JSF 1.2, per se. I'm personally good with JSF 1.2 only, though, for this new project. On Dec 3, 2007 2:43 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! +1 on JSF 1.2 only +0.5 on 1.1 support with JDK 1.5 required on both. -1 on 1.1 w/ 1.4 +1 on that view! Ciao, Mario
Re: [VOTE] Commons API JSF 1.2 only
+1 On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Lets make the myfaces commons JSF API an official vote so we can have a fixed time frame on this decision +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces commons project +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2 trunk -1 [ ] -- you feel that 1.1 should be required and why you feel that it is needed My vote: +1 -Andrew
Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]
At least in terms of the validators/converters/etc (non-api) parts of commons, it is not intended that Tobago or any other project depend on these. These are additional components made available to the end users. So it's true that some small subset of Tobago users won't be able to use it. The same is true for Trinidad and Tomahawk users. I don't think that's reason enough to require that these projects support JSF 1.1. I still think the conglomeration of developer-targeted utilities/apis and end-user-targeted components is a mistake, and I was under the impression that each of these pieces was independent of each other. If that's the case, there's no reason why the api/utils developer-targeted projects can't maintain JSF 1.1 support while leaving the component end-user-targeted projects at JSF 1.2. On Dec 5, 2007 5:08 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: The tobago codebase will be 1.1 or 1.2 compatible as much as possible. If commons only supports 1.2 we are not able to use it in tobago until the 1.1 version is only in maintenance mode. I think it's ok if some parts of commons are 1.2 only. I think jdk 1.4 compatibility is not a requirement.(We can provide a retrotranslated version) As far I know some of the tobago users still using 1.1 jsf and not able to switch to 1.2 until end of 2008. Andrew Robinson schrieb: As the vote states, if -1, please provide a reason why 1.1 has to be supported. An argument of why not is not enough. On Dec 5, 2007 2:14 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: -1 I don't see any reason why a commons fileupload should not support 1.1 Can someone define what commons API means? Is this just a subproject of commons like commons validator or commons converter? Scott O'Bryan schrieb: +1 Mario Ivankovits wrote: +1 Lets make the myfaces commons JSF API an official vote so we can have a fixed time frame on this decision +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces commons project +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2 trunk -1 [ ] -- you feel that 1.1 should be required and why you feel that it is needed My vote: +1 -Andrew
Re: Java version compatibility (was Re: svn commit: r605927 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java)
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
On Dec 20, 2007 10:11 AM, Simon Kitching [EMAIL PROTECTED] wrote:
This problem happens no matter what java versions are being talked about.
When the aim is to support java N, but the latest is java X then it is
difficult to prevent accidents.
Compiler property source prevents the use of *language features* that are
not supported in the specified version
Compiler property target ensures that the generated bytecode is readable by
the specified version.
But nothing checks that you are using only APIs provided by the runtime
library distributed by that version. Currently the only way to do that is to
compile against the runtime lib distributed with that version (which
basically means *using* that version to compile).
The CLIRR project does binary-compatibility testing on jars. I have always
suspected that it would only need a minor enhancement to generate an API
summary for the rt.jar of version N of java, and then to be able to
automatically check that an app only makes calls to the APIs defined by that
summary file. Just need that old 40 hour day in order to get time to do it :-)
Cheers, Simon
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
I'd be fine with Java5 instead of 1.4
-M
On Dec 20, 2007 3:37 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
yes, that is what I'm saying.
Saying that this is a bug is maybe pushing it too hard... the
attributes just translate into a compiler language level - that does
not mean that someone automagically knows all API changes from 1.4 to
1.6 and automatically applies them. The only chance for you to catch
all these problems is to actually compile with 1.4.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
So,
you say that a configuration like:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
inheritedtrue/inherited
configuration
source1.5/source
target1.5/target
/configuration
/plugin
does allow you to use JDK6 methods?
That would be a bad bug, IMO.
-M
On Dec 20, 2007 3:22 PM, Martin Marinschek [EMAIL PROTECTED]
wrote:
Yes, so 1.5/1.6 syntax will correctly be found and disallowed. But API
changes are not checked for, so a newly added method will not be
found.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 3:19 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
I thought the compile was configured for source/target not 1.5 ||
1.6
(the compiler plugin)
-M
On Dec 20, 2007 3:18 PM, Martin Marinschek
[EMAIL PROTECTED]
wrote:
No - if you are building with 1.6, it won't. Only the language
level
is
checked.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 2:45 PM, [EMAIL PROTECTED] wrote:
Author: skitching
Date: Thu Dec 20 05:45:06 2007
New Revision: 605927
URL: http://svn.apache.org/viewvc?rev=605927view=rev
Log:
Remove accidental use of java 1.6 method String.isEmpty
isn't the build catching this ?
-M
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java?rev=605927r1=605926r2=605927view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java
Thu Dec 20 05:45:06 2007
@@ -838,7 +838,7 @@
private static void formatPattern(DateFormatSymbols
symbols,
ParserContext context, String patternSub, boolean
yearIsWeekYear,
StringBuffer out)
{
-if ((patternSub == null) || (patternSub.isEmpty()))
+if ((patternSub == null) || (patternSub.length()
Re: Java version compatibility (was Re: svn commit: r605927 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/dateformat/SimpleDateFormatter.java)
I agree, but it could be set up on the continuum server (if it's not already set up there). I know nothing about maven, but maybe the rt.jar can be pulled down into the repository, where it should be in a standard location. On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote: Mike Kienenberger [EMAIL PROTECTED] schrieb: Can't you do something like this to force the rt.jar to be 1.4? http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html % javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs OldCode.java Yep. However that cannot be put into the pom because the location of the jdk1.4 will be different on everyone's machine - if they have it installed at all. And because it isn't automatic, most people won't bother to set it up. I'm not sure I would...
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2?
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
On Jan 21, 2008 4:10 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) Sorry. I'll be more careful in my wording: If something was publicly made available as 1.2.1 already, then -- even if it was pulled -- please do not make something else publicly available as 1.2.1 again unless it is identical to the first 1.2.1.
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
http://wiki.apache.org/myfaces/Code_Generation 2) Generating base classes instead of templates from xml-config-files For what it's worth, what you're describing here is the Generation Gap pattern. I've got a lot of experience using it with Cayenne over the years (and WebObjects years before that), and it's effective. It's sometimes painful to write and maintain your base class in a templating language, though, but once your base class is done, you don't need to mess with it again, so this is a one-time painful experience. And yes, you would typically generate an empty concrete subclass whenever one doesn't exist (the first time code generation runs for a given component). I check the code thus generated into the repository. I also keep the generated code in a subpackage called *.generated off the concrete subclasses's package.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas or dtds. Is
something similar available for javadoc annotations in the standard
IDEs? Or will errors not be checked until the javadocs are processed,
which seems like it may be several minutes into the build process?
Not saying it's a showstopper, just pointing out another area to consider.
On 3/19/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Wed, Mar 19, 2008 at 3:39 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Leonardo Uribe schrieb:
Thanks Simon for make more clear this on the wiki page. I have
also
added comments about how
should work isSetFieldMethod and isGetLocalMethod attributes for
@mfp.property.
And thanks for your additions.
Is the setLocalMethod stuff specifically something that trinidad
needs? I have not seen this anywhere in core or tomahawk that I
remember. If so, then perhaps the wiki could say (trinidad only) or
similar next to those props.
setLocalMethod and isSetProperty stuff is necessary only for tomahawk
(trinidad does not require this because it use
a FacesBean to manage the data).
On Tue, Mar 18, 2008 at 12:44 PM, Andrew Robinson
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
wrote:
On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Andrew,
Andrew Robinson schrieb:
One major drawback to the javadoc annotation approach
has been
left
out and that is attribute reuse. The maven-faces-plugin
allows you to
import XML fragments using XPath. So in Trinidad,
onclick,
onmouseover, onmouseout, etc. you can import one XML
file and
not have
to re-define all these. But with the javadoc approach,
you
have to
either one, try to hack the code to extend other
classes, two
have
some weird interface usage to import these. Either way,
the
object
hierarchy has to be hacked to get it to work.
Hmm..interesting. So trinidad has cases where a class X
is not
related
to A by inheritance, but does want to provide the same
properties as A?
Java currently defines implements and extends; sounds
like
Trinidad
has invented a new OO concept, emulates :-).
No, it only imports certain attributes, not all of them.
Take some
time to look at the trinidad-build project and how it works.
It is
better to see than explain.
In tomahawk, there are interfaces like
org.apache.myfaces.component.UserRoleAware that
define getter and
setter methods for a particular group of related properties.
Maybe we
can do something like this:
/**
* @mfp.interface //or propertiesinterface or setofproperties or
anything related
**/
public interface UserRoleAware
{
static final String ENABLED_ON_USER_ROLE_ATTR =
enabledOnUserRole;
static final String VISIBLE_ON_USER_ROLE_ATTR =
visibleOnUserRole;
/**
* @mfp.property
**/
String getEnabledOnUserRole();
void setEnabledOnUserRole(String userRole);
/**
* @mfp.property
**/
String getVisibleOnUserRole();
void setVisibleOnUserRole(String userRole);
}
Then the abstract component class can implements this interface
and
finally the generated class must implement the methods. In this
way we
make clearer the API, and eliminate in a clean way the advantage
of
using xml files.
I see. Yes, where is a group of properties to be shared between two
classes, the OO way would be to declare a common interface.
I guess another example is the set of html passthrough
attributes that
is attached to many components.
The myfaces-builder-plugin code already walks interfaces looking for
property definitions. Currently the normal @mfp.component
annotation
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Ok, so to summarize, validation would only happen during the maven build process. I did a quick search for QDox plugins (Eclipse, Idea, Netbeans) and didn't immediately find anything. On 3/21/08, simon [EMAIL PROTECTED] wrote: Hi Mike, Although the metadata is written like a javadoc comment, it is not processed by the javadoc tool. The qdox (qdox.codehaus.org) library is a full java parser that builds a datastructure representing everything in the java files you feed it - except the method bodies. This includes analysing the javadoc for tags. The plugin applies this parser to the java source in the generate-sources phase, ie before any java code is compiled by javac. When actually writing the meta-data, the auto-complete ability that is available for an xml file (due to a schema) *is* better than the doc-annotation approach (which has no IDE help). However on the plus side, there is much less to write as much of the data is actually derived from analysing the real class hierarchy, method signature, etc. Error-reporting for malformed metadata is automatic for xml with a schema at the syntax level. With the doc-annotation approach, the plugin needs to specifically check that the right annotations are there (but that's not too hard). In both cases, the error-reporting will occur before any code compilation. I believe that at the semantic level the doc-annotation approach is better checked because you cannot get inconsistent declaration of properties vs code for example; the property metadata is *derived* from the actual code declaration. With the xml approach, the class hierarchy and property types are effectively typed in once in java and once in xml, and there will be problems if the two don't match.. Regards, Simon On Fri, 2008-03-21 at 14:40 -0400, Mike Kienenberger wrote: I've been following this thread on and off, so my apologies if you already covered it, but how different will syntax checking be with the javadoc annotations vs xml? Xml editors automatically validate with schemas or dtds. Is something similar available for javadoc annotations in the standard IDEs? Or will errors not be checked until the javadocs are processed, which seems like it may be several minutes into the build process? Not saying it's a showstopper, just pointing out another area to consider. On 3/19/08, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 3:39 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Leonardo Uribe schrieb: Thanks Simon for make more clear this on the wiki page. I have also added comments about how should work isSetFieldMethod and isGetLocalMethod attributes for @mfp.property. And thanks for your additions. Is the setLocalMethod stuff specifically something that trinidad needs? I have not seen this anywhere in core or tomahawk that I remember. If so, then perhaps the wiki could say (trinidad only) or similar next to those props. setLocalMethod and isSetProperty stuff is necessary only for tomahawk (trinidad does not require this because it use a FacesBean to manage the data). On Tue, Mar 18, 2008 at 12:44 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Andrew, Andrew Robinson schrieb: One major drawback to the javadoc annotation approach has been left out and that is attribute reuse. The maven-faces-plugin allows you to import XML fragments using XPath. So in Trinidad, onclick, onmouseover, onmouseout, etc. you can import one XML file and not have to re-define all these. But with the javadoc approach, you have to either one, try to hack the code to extend other classes, two have some weird interface usage to import these. Either way, the object hierarchy has to be hacked to get it to work. Hmm..interesting. So trinidad has cases where a class X is not related
Re: MyfacesBuilderPlugin
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the velocity template language.
I also think you're better off NOT putting velocity-specific utilities
on the data model. Determine if those methods would make sense if you
were not using velocity, and if that's the case, keep it on a separate
java object (By the way, these separate java objects are called
tools in the velocity jargon.).
I'm not sure what the ideal way of doing this from maven is, but in
ant, we typically configured these tools using the BSD-licensed
VPP-provided ant tasks.
http://vpp.sourceforge.net/
It's not all difficult to do this in java code, if you have direct
control over the code setting up the Velocity engine.
velocityContext.put(stringUtils, new StringUtils());
velocityContext.put(myfacesUtils, new MyfacesUtils());
On Wed, Apr 2, 2008 at 9:52 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a macro file on inside the template:
## [ Setting Utility Classes to use ]
##
#set($utils =
$classes.forName(org.apache.commons.lang.StringUtils).newInstance())
In this case, we can copy
org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
myfaces-faces-plugin and use it
inside the templates. like this
$utils.lowerCase($field.getAttributeValue(name))
2) Use a file to create velocity macros and implement this here. Inside we
need to use StringUtils like in (1), but from the point of view of the
template designer, He/she doesn't see this.
3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
(like getting the properties from a component) and is more clean. For
example:
package ${component.tagPackage};
public class ${component.tagName}{
#foreach( $property in ${component.propertyList} )
//getter and setter methods
#end
}
This two methods (getTagPackage and getTagName and derived properties of
tagClass).
What option could be better? If no suggestions, I will go for option 1 and
3.
regards
Leonardo Uribe
On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I'm not quite clear what your description above means. I think we are
talking about the same thing, but just to be clear this is how I would
see it working:
== for goal build-metadata:
start with an empty model
for each jarfile containing a META-INF/myfaces-metadata.xml file
read that myfaces-metadata.xml file
add the resulting objects into the model[1]
run the ModelBuilder for the current project, which adds more objects to
the model
save the model into META-INF/myfaces-metadata.xml in the current project
An alternative would be to do the merging just at the xml level, then
build a model from the resulting merged xml file. That also seems
reasonable.
== for other goals (eg generate faces.xml, generate tag classes):
start with an empty model
read META-INF/myfaces-metadata.xml for the current project only
add the resulting objects to the model
pass the model object to the appropriate generator class[3]
[1] Hmm..might need to somehow detect and handle duplicate data.
Yes, duplicated data is the problem.
In particular, tomahawk will depend on both myfaces-api and
myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
copy of all the data from the myfaces-metadata.xml contained in
myfaces-api jarfile. So if *all* jars in the classpath are processed,
the data from myfaces-api.jar will be processed twice.
Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
core depends of myfaces api only (because it should be compatible with jsf
ri, no
impl dependences should be present). So the problem ilustrated here raises
on sandbox.
Options I see are
(a) don't worry; the data will just be identical
Right.
(b) check that if a model object is being overwritten, the new data is
identical
(c) have the plugin configured with an explicit list of jars to process
metadata from. Then in the pom it must be configured so that
myfaces-impl is processed and myfaces-api is ignored. Then make it an
error for the same model object to be defined twice.
(d) have a myfaces-metadata.xml file *not* include data inherited from
parent projects. That's cleaner in a way, but means that when processing
other goals we cannot just load the metadata file from the local
Re: MyfacesBuilderPlugin
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: The drawback is that creates a log file on the project folder (I'm not found how to output the log on the screen yet!). Have you looked at this page? http://velocity.apache.org/engine/devel/developer-guide.html#configuring_logging Here are some specific examples: http://www.java2s.com/Code/Java/Velocity/Velocity-Log.htm
Re: MyfacesBuilderPlugin
Another alternative to option 1 is to #parse($fileName) or #include($fileName). You can specify filename externally. This is probably the best solution so long as the contents of the file included can be included as-is. On 4/9/08, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi I have another design question. I have finished tag class generation using velocity, and right now I'm working on generation of component classes, but later I want to use this tool for generate faces-config.xml and taglib.tld files too. The problem is that in some point it is necessary to let the user define files like faces-config-base.xml and taglib-base.xml, to add some content inside the generated file (or in other words merge this files). 1. One option is use velocity like this: faces-config $customContentFromFacesConfigBase !-- generated xml content -- /faces-config 2. But another solution is try to merge this files with some xml tool. 3. Other solution is provide what we want to insert what we need to add on the template that are readed from mylib/src/main/resources/META-INF/templateForFacesConfig.vm What option could be better? If no suggestions I will go with option 3 (the easy the better, but option 1 sound good too). regards Leonardo Uribe
Re: core, myfaces-builder-plugin: issues noticed
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote: * @JSFJspProperty name = message inheritedTag=true returnType = java.lang.String longDesc = alternate validation error message format string */ public class CSVValidator extends ValidatorBase Inheritance of properties for converters and validators are not supported (in my concept there is no sense to allow this, but if there is a strong reason we can study the impact and change it), so all properties defined on the parent (in that case ValidatorBase) should be defined again with inheritedTag=true. I guess I'd have to disagree that there's no sense in allowing inheritance of properties on validators and converters. The original goal of the ValidatorBase class was to provide a message properties to all subclasses. Why would you extend a validator or converter if you weren't planning on using the same properties of the parent?
Re: core, myfaces-builder-plugin: issues noticed
A practical use case for converter inheritance would be identical -- allowing custom converter per-instance messages properties. Since the JSF spec does not declare validator and converter classes final, assume that inheritance is possible and that properties will propagate. Again, if you are subclassing a converter, there's obviously some reason why you did it rather than writing one from scratch. On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote: * @JSFJspProperty name = message inheritedTag=true returnType = java.lang.String longDesc = alternate validation error message format string */ public class CSVValidator extends ValidatorBase Inheritance of properties for converters and validators are not supported (in my concept there is no sense to allow this, but if there is a strong reason we can study the impact and change it), so all properties defined on the parent (in that case ValidatorBase) should be defined again with inheritedTag=true. I guess I'd have to disagree that there's no sense in allowing inheritance of properties on validators and converters. The original goal of the ValidatorBase class was to provide a message properties to all subclasses. Why would you extend a validator or converter if you weren't planning on using the same properties of the parent? ValidatorBase is the only case of inheritance for validators. But from this point of view is valid allow inheritance for validators. Checking the code, a change only affects tomahawk, so there is no problem. On sandbox, all validators do not use detailMessage and summaryMessage on its tld (this fact makes me feel strange about ValidatorBase), so this could be a side effect. I'll try it in deep and commit it. I'm not found yet a practical usage for inheritance for converters, so I'll let it as is Thanks for your suggestions Leonardo Uribe
Re: [myfaces commons] discussion about reorganization of this project is required!
I'd recommend not migrating t:validateEqual across to myfaces-commons. t:validateEquals is a special case of t:validateCompareTo, and, if I recall correctly, the code in validateEquals is not as flexible as the code in validateCompareTo. There's no point in maintaining the inferior limited version in the reorganization. On 6/6/08, Leonardo Uribe [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer [EMAIL PROTECTED] wrote: Leonardo Uribe wrote: Hi I'll start to upgrade component from sandbox to tomahawk. The first item on my list of todos is move this converters and validators (first check and solve possible issues on JIRA) s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl Please note that long time ago this upgrade was approved, but this was not applied due to code generation discussion. file:///C:/GSOC/workspace/tomahawk-compgen/oldsandbox-site/tlddoc/s/validateUrl.html Actually on tomahawk exists this validators: t:validateCreditCard t:validateEmail t:validateEqual t:validateRegExpr The idea is that all this converters and validators be on myfaces-commons. But originally tomahawk is 1.1 compatible, and there was comments about commons should have 1.1 and 1.2 converters and validators. If this is true, tomahawk should refer myfaces commons converters and validators on its tld, and have dependecies to commons (if false this is valid only for 1.2). +1 for true. The thought of maintaining 2 sets of converts/valdiators is unnerving. The new unpack plugin allow us to manage this issues more easily, enforcing just the necessary files to maintain. In order to be consistent with this intentions my first approach would be: 1. Use this layout for myfaces-commons: myfaces-commons-converters myfaces-commons-converters12 myfaces-commons-validators myfaces-commons-validators12 myfaces-commons-utils 2. Use myfaces-builder-plugin for this stuff. 3. Refer converters and validator from commons to tomahawk tld (the intention is avoid changes on existing applications). I suggest deprecating the existing converters/validators. Good idea but needs some concensus about this. Deprecate means do not exclude it but refer the users to myfaces commons. Suggestions are welcome o What is the impact on the other components, i.e. Trinidad/Tobago/...? no impact, myfaces commons does not have any release yet and does not have dependencies with anything (the idea of this discussion is organize this stuff and make a release of this!). o Is this to be included in Tomahawk 1.1.7? yes o How long do you expect this to take, i.e. days/weeks/months/... ? (I am only asking to set expectation on release schedules) days, at max weeks o Where is the new unpack plugin documented? http://myfaces.apache.org/build-tools/plugins/myfaces-builder-plugin/unpack-mojo.html There is more doc on the source code (the site has not been updated, but this doc is fine). This is a work in progress. regards Leonardo Uribe Paul Spencer
Re: [VOTE] promoting the subform component to Tomahawk
+1 to promoting subform. +1 to everything Volker said. On 6/11/08, Volker Weber [EMAIL PROTECTED] wrote: Hi Hazem, i think you are a bit to fast. You started the vote at 9. Juni 2008 17:54 start committing the changes 44:20 hours:minutes (if i count correct) later at 11. Juni 2008 14:14. You should wait at least 72 Hours after starting the vote. See http://www.apache.org/foundation/voting.html. BTW: Great, we have now 2 positive votes. I will start promoting it after waiting another 24 hours. You neet at last 3 positive votes, you got 4 in the meantime :-) . Regards, Volker 2008/6/11 Hazem Saleh [EMAIL PROTECTED]: Promotion is done :). Now we can see :- t:subform ... /t:subform in Tomahawk :). On Tue, Jun 10, 2008 at 1:09 PM, Manfred Geiler [EMAIL PROTECTED] wrote: +1 On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Team, I wish to promote this subForm component to the next Tomahawk release. [+1] for agreeing with promoting the component to the next Tomahawk release. [-1] for disagreeing with promoting the component to the next Tomahawk release. Thanks all very much! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
Re: NumberConverter has issue with BigDecimal
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
BigDecimal converter could solve this problem, maybe this value is
converted
as double or float as is.
ok, the demo was a little bit to simple.
We want currency formatting etc. Means what the convertNumber actually does.
-Matthias
regards
Leonardo Uribe
On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
perhaps someone of you knows a workaround for this:
Take this JSP code:
h:inputText value=#{bean.number}
f:convertNumber /
/h:inputText
For instance, when the entered value is 333.111 the actual stored
value is 333.11099899955582804977893829345703125
I think the mathematic explanation for that in here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
My users want to have 333.111 instead of the accurate value...
Any ideas?
Thanks!
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: NumberConverter has issue with BigDecimal
For what it's worth, I've been using a precursor version of a similar
component (which only supported BigDecimal types) in a production
project for a couple of years with the currency parser patch and none
of the users have ever complained of issues with it.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
thanks!
will have a look
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
BigDecimal converter could solve this problem, maybe this value is
converted
as double or float as is.
ok, the demo was a little bit to simple.
We want currency formatting etc. Means what the convertNumber actually
does.
-Matthias
regards
Leonardo Uribe
On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf [EMAIL
PROTECTED]
wrote:
Hi,
perhaps someone of you knows a workaround for this:
Take this JSP code:
h:inputText value=#{bean.number}
f:convertNumber /
/h:inputText
For instance, when the entered value is 333.111 the actual stored
value is 333.11099899955582804977893829345703125
I think the mathematic explanation for that in here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
My users want to have 333.111 instead of the accurate value...
Any ideas?
Thanks!
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: where to get trinidad complete source?
http://myfaces.apache.org/trinidad/download.html If it's not in a pre-build download, you can check it out from svn by following the instructions on the same link above. On 6/13/08, Ivan Li [EMAIL PROTECTED] wrote: I download the source code from apache, but the the core component's source code does not exist for example: the package org.apache.myfaces.trinidad.component.core.* does not exist in source code, but it's class do exist in the jar file. -- myBlog: http://ivanl.javaeye.com
Re: NumberConverter has issue with BigDecimal
Yes, I believe that the sandbox uses Java 1.4.
There's still other pitfalls to avoid with standard java parsing, though:
http://www.ibm.com/developerworks/java/library/j-numberformat/index.html
I thought this was covered in Tomahawk 610, but apparently not.
Adding a comment about it.
On 6/16/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn that guy on. So, that fixes it.
Sandbox still still requires Java1.4, right?
-matthias
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
BigDecimal converter could solve this problem, maybe this value is
converted
as double or float as is.
ok, the demo was a little bit to simple.
We want currency formatting etc. Means what the convertNumber actually
does.
-Matthias
regards
Leonardo Uribe
On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf [EMAIL
PROTECTED]
wrote:
Hi,
perhaps someone of you knows a workaround for this:
Take this JSP code:
h:inputText value=#{bean.number}
f:convertNumber /
/h:inputText
For instance, when the entered value is 333.111 the actual stored
value is 333.11099899955582804977893829345703125
I think the mathematic explanation for that in here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
My users want to have 333.111 instead of the accurate value...
Any ideas?
Thanks!
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: NumberConverter has issue with BigDecimal
Sounds like you're on the right track. I brought this up a year or
two ago when the article came out, but never really got any feedback.
The short solution from the URL, which I use in my custom converter:
--
To summarize, the steps for proper input processing are:
1. Get an appropriate NumberFormat and define a ParsePosition variable.
2. Set the ParsePosition index to zero.
3. Parse the input value with parse(String source, ParsePosition
parsePosition).
4. Perform error operations if the input length and ParsePosition
index value don't match or if the parsed Number is null.
5. Otherwise, the value passed validation.
--
On 6/16/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Mon, Jun 16, 2008 at 6:21 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Jun 16, 2008 at 6:19 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Yes, I believe that the sandbox uses Java 1.4.
There's still other pitfalls to avoid with standard java parsing, though:
http://www.ibm.com/developerworks/java/library/j-numberformat/index.html
I thought this was covered in Tomahawk 610, but apparently not.
Adding a comment about it.
I had to work around something similar already in the past:
http://matthiaswessendorf.wordpress.com/2007/12/03/javas-numberformat-bug/
-Matthias
thanks!
-Matthias
On 6/16/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn that guy on. So, that fixes it.
Sandbox still still requires Java1.4, right?
-matthias
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe [EMAIL PROTECTED]
wrote:
BigDecimal converter could solve this problem, maybe this value
is converted
as double or float as is.
ok, the demo was a little bit to simple.
We want currency formatting etc. Means what the convertNumber
actually does.
-Matthias
regards
Leonardo Uribe
On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf [EMAIL
PROTECTED]
wrote:
Hi,
perhaps someone of you knows a workaround for this:
Take this JSP code:
h:inputText value=#{bean.number}
f:convertNumber /
/h:inputText
For instance, when the entered value is 333.111 the actual
stored
value is 333.11099899955582804977893829345703125
I think the mathematic explanation for that in here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
My users want to have 333.111 instead of the accurate value...
Any ideas?
Thanks!
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [myfaces commons] discussion about reorganization of this project is required!
It should be deprecated because it adds nothing over validateCompareTo and does not do the job of locating/computing/comparing two equal input component values as well as validateCompareTo does. Or to look at it another way, defining a validateEquals jsp or facelet tag handler that points to the validateCompareTo code instead of the validateEquals code will provide better functionality. validateCompareTo will become the plain jsf component, and validateEquals will continue to be a tomahawk component (until such time support for it is totally dropped). On 6/17/08, Volker Weber [EMAIL PROTECTED] wrote: Hi, validateEqual should be deprecated because validateCompareTo it is better (according to the suggestion of Mike), so this validator should stay on tomahawk. The rest of converters and validators only be referenced by if validateEqual works in non tomahawk environment why make it deprecated? Even if tomahawk contains a better alternative, a tomahawk component is no alternative for a plain jsf component. Regards, Volker -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
Re: [VOTE] layout for myfaces-commons project
Let's not forget that working on open source software is quite different than working on proprietary software. For open source, you work on what you need and you share what you've done with others. Some people need JSF 1.1 and will be working there. Some people need JSF 1.2 and will be working there. Some will need 2.0. Keeping it all consistent would be ideal, but realistically, everyone needs to work on what they need. To say that no work will be allowed on JSF 1.1 is not helpful. Yes, it'd be great if everything applied to one branch can be applied to another, but if someone is still working on JSF 1.1 fixes and features, they may not have access to JSF 1.2 or 2.0. My suggestion is that we keep this in mind and allow for some flexibility. It may be that some work committed to 1.1 remains as a JIRA item until someone needs it in JSF 1.2 or 2.0. And a bug fix to 1.2 may remain as a JIRA item for 1.1 until it's needed. As an example, I'm doing a lot of work with a legacy app these days (which is why I'm not actively doing JSF development) and it uses Cayenne 1.1. That's now 4 versions old as Cayenne has transitioned from 1.1 to 1.2 to 2.0 to 3.0. I don't expect the cayenne community to support my needs by back-porting all bug fixes, but I do have the ability to back-port and maintain those fixes myself as a developer, even though the branch is not officially supported by the project. And at the same time, if the problem I fix is still an issue in 3.0, I'm not expected (or required) to make sure that every version of Cayenne after 1.1 has that fix applied. I would open a JIRA issue, but since the architecture is quite different for later versions, it would be up to someone using a newer version to solve and apply it (with or without the code I used to fix it). On the other hand, I would typically try to also fix it for 1.2 since the ease of applying such a patch is greatly reduced. Myfaces Core and Tomahawk has always been very weak on providing bug fixes for older versions. If anything we should be trying to make that task easier rather than more difficult.
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: s:validateCompareTo And all that code about independently converting a component's submitted value makes me a little nervous. It looks ok, but has anyone properly reviewed it? The code was pretty much copied verbatim from the Myfaces JSF core. In any case, the component has been used by several people for several years now, and no one has complained. If it's a problem down the road, I'm sure someone will open a JIRA issue and we can address it at that time. In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. I don't like the idea of tomahawk1.x having these components internally, while tomahawk2.x uses the version from commons. It's ugly and confusing. While code duplication is never nice, I think it would be better for tomahawk 1.1.x and 1.2.x to continue to have these components internally, and for commons to have a separate version. It also means that commons can clean up the API without breaking tomahawk users. Yes, it does mean having to apply fixes in two places (tomahawk, commons) but so does the alternative (tomahawk 1.x, commons). I say we mark the tomahawk validator and converter components as deprecated, leaving them as they are and where they are, and copy everything to commons. No one is forced to upgrade unless they need something fixed or enhanced, but we don't maintain it in multiple places.
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
On 6/25/08, simon [EMAIL PROTECTED] wrote: On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote: On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: s:validateCompareTo And all that code about independently converting a component's submitted value makes me a little nervous. It looks ok, but has anyone properly reviewed it? The code was pretty much copied verbatim from the Myfaces JSF core. In any case, the component has been used by several people for several years now, and no one has complained. If it's a problem down the road, I'm sure someone will open a JIRA issue and we can address it at that time. It occurred to me after looking at the code that an alternative might be to queue an event from the validator. The event should be processed only at the end of the validation phase, at which time all conversion has already been done. That could simplify the converter - and it does feel more elegant to me than having one validator poking around inside another one. Yes, that idea sounds better. I admit that it's a bit scary that the component has to rely on the implementation code from MyFaces. Even though it uses public APIs, in practice, it might break on another implementation. In tomahawk core, the related files should be moved from sandbox/core to core. In tomahawk core12, a new dependency to myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x should be added, so the tomahawk core12 tld reference validators and converters from these projects. This introduce a change because the validatorId and converterId for this components changes (because this converters are defined on myfaces-commons) only on core12. I don't like the idea of tomahawk1.x having these components internally, while tomahawk2.x uses the version from commons. It's ugly and confusing. While code duplication is never nice, I think it would be better for tomahawk 1.1.x and 1.2.x to continue to have these components internally, and for commons to have a separate version. It also means that commons can clean up the API without breaking tomahawk users. Yes, it does mean having to apply fixes in two places (tomahawk, commons) but so does the alternative (tomahawk 1.x, commons). I say we mark the tomahawk validator and converter components as deprecated, leaving them as they are and where they are, and copy everything to commons. No one is forced to upgrade unless they need something fixed or enhanced, but we don't maintain it in multiple places. I've lost track now. Is there going to be a commons 1.1.x version or not? If there is a commons-1.1.x then I agree my suggestion was completely wrong. These are just sandbox components. So we could move them directly into commons, and not promote them into tomahawk at all. Or possibly leave the original in the sandbox for a while, marked as deprecated so people have some time to migrate. But I'm not sure that is needed for sandbox features. And there would be no dependency from tomahawk to commons. If people want these, they add the commons lib to their path. The commons libs do contain their own tld (with its own namespace), yes? Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast approaching the end of its lifecycle. Leave it deprecated in Tomahawk 1.1 (and sandbox). We would want to do that anyway for backwards compatibility. Drop it from Tomahawk post-1.1 (and sandbox).
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
On 6/26/08, Volker Weber [EMAIL PROTECTED] wrote: Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast approaching the end of its lifecycle. Yes, it does. At least to me. Commons1.1 is not a tomahawk1.1 extension, it should contain things for jsf1.1 application developpers. As long as there is active development in jsf1.1 applications, there is a need for a commons1.1 version. We are just going in production with a tobago/jsf1.1 application, developed within the last three years, and i can't see the time to switch to jsf1.2 in the next months while we need to add extensions for specific customers. Volker, I'm not saying we shouldn't have a commons 1.1. I think we should. What I'm saying is that even if we do not have a commons 1.1, we should stop maintaining the validators and converters as part of Tomahawk. If someone thinks they are worth supporting in 1.1, they should so as part of commons 1.1.
Re: [VOTE] promoting the selectOneRow component to Tomahawk
If I understand correctly, the current state of the component is such that it works with any UIData component. I'm +1 for keeping that status. It'd be great if we could do something similar with many of the other t:dataTable functionality. On 6/27/08, simon [EMAIL PROTECTED] wrote: I'm +1 to promoting the component in its current state (which I think is your -1 option below). Thanks for looking into that. Regards, Simon On Fri, 2008-06-27 at 15:24 +0300, Hazem Saleh wrote: Hi Simon, I found it possible to use it with the h:dataTable as it depends only on (UIData). We have now two paths: [+1] for merging this component as an attribute in t:dataTable .../. [-1] for promoting the component to Tomahawk in its current state. Me -1 now. On Mon, Jun 16, 2008 at 10:04 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think it would be useful to have an answer to my question first. *Is* it possible to do this? h:dataTable ... s:selectOneRow/ /h:dataTable If so, then moving from the current approach to using an attribute will remove existing functionality. Ok, with a sandbox component that is allowed but the above looks useful. Unfortunately I'm really busy on other things at the moment, and don't have time to look myself. Regards, Simon Hazem Saleh schrieb: Any new votes ? On Sun, Jun 15, 2008 at 4:13 PM, simon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I only suggested leaving it as it is *if* it is possible to use this component with tables other than t:dataTable. On Sun, 2008-06-15 at 15:57 +0300, Hazem Saleh wrote: OK Let's make this as a vote : we now have : - 2 votes for supporting the feature inside the t:dataTable. - 1 vote for leaving the current component as is. On Sun, Jun 15, 2008 at 3:13 PM, simon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: A separate component would be nice if it could be applied to any table, eg the h:dataTable. On Sun, 2008-06-15 at 13:40 +0300, Hazem Saleh wrote: +1 for Matzew idea. I think that the old component syntax was suitable for the component when it was in the sandbox phase. I will implement this idea, it is good. Thanks Matzew! On Sun, Jun 15, 2008 at 11:16 AM, Matthias Wessendorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Jun 14, 2008 at 6:16 PM, Hazem Saleh [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Team, After updating the selectOneRow component's documentation. just curious, what is this component about? Using it like this ? t:table . s:selectOneRow / /t:able If so, how to declare multiple row selection ? Trinidad's table doesn't treat that as a special case. It just has an attribute for that, where you specify via an enum the selection type (single:mulit) Greetings, Matthias I wish to promote it to the next Tomahawk release. [+1] for agreeing with promoting the component to
Re: t:graphicImage doesnot generate XHTML complaint code
I agree with Simon in that where the image usage is not under our control (like t:graphicImage), we should not output an alt tag unless the end-user specifies an alt tag. On Mon, Jun 30, 2008 at 4:50 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, Jun 30, 2008 at 12:15 AM, Hazem Saleh [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Team, Simon and me made a discussion about making the (t:graphicImage) component XHTML complaint. Here is the thread discussion : https://issues.apache.org/jira/browse/TOMAHAWK-1143 We need to take your opinion about that, Have we have to make the components XHTML complaint or leave this to the user's usage with warnings ? Hazem Saleh schrieb: Sorry the thread discussion is here : https://issues.apache.org/jira/browse/TOMAHAWK-1291 Manfred commented on the jira issue: [I moved this to the email thread, so we don't have half the discussion here and half on the issue] +1 for a strict (but sweet-tempered) behaviour that means: - log a nag warning - render a non-empty alt attribute with a meaningful default text if the developer omits the attribute (or provides an empty one) The thing is that for h:graphicImage and t:graphicImage we have **no idea** what a meaningful text would be. This is some arbitrary image that the user has chosen. For what purpose? We don't know - unless we embed AI software and do image recognition on the referenced file. So for h:graphicImage and t:graphicImage we have **only** these choices: (a) don't output ALT. This screws all blind users, but in an obvious way so that QA departments can easily detect it and tell their developers to add the needed alt attributes. And it is not our code that is at fault. (b) output empty ALT. This screws all blind users, but it cannot be detected by validation. And it is our code that is at fault as well as the user code. (c) output ALT with ha ha no description. See (b). For cases where myfaces components are generating the image references for their own purposes, they *know* what that purpose is. Always. So they are always capable of attaching a valid ALT description. Regards, Simon
Re: [VOTE] Upgrade s:limitRendered to tomahawk
What Simon proposed makes a lot of sense to me.
On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this
component.
Can you please describe it?
The same as all usages of c:choose /. The index based or more than
one are just added benefits I threw in. I can provide examples, but I
shouldn't have to.
I certainly think all new components should have to provide proper
use-cases. Having very rarely used components in Tomahawk:
* makes it hard for users to find what they want (steeper learning curve)
* increases the maintenance burden
* increases the jarfile size
So components should only go in if they are useful to a reasonable number of
people.
Just because someone can't think of when it would
be needed, doesn't mean it never would be useful, but I can appease
you curiosity.
It's not curiosity. There is a vast amount of crap in Tomahawk right now, to
the point where Tomahawk is close to dying. There hasn't been a release for
a year. The number of open bugs is vast. So everyone *should* be watching
carefully to see that we don't increase the problems.
That doesn't mean that good components cannot be added. But new stuff does
need to be evaluated for usefulness.
And the author of a component is often too close to the code to see whether
it can be improved (that applies equally to me). Having other people look
critically at the purpose and API is very useful. You are free to point out
any issues with components I write (eg Orchestra stuff).
I created the component so that people would stop using
c:choose and c:if in JSF pages and complain that they don't work in
tables and such.
1) default c:choose functionality (render the first match):
s:limitRendered
h:outputText value=#{person.first} #{person.last}
rendered=#{prefs.firstThenLast} /
h:outputText value=#{person.last}, #{person.first}
rendered=#{prefs.firstThenLast} /
/s:limitRendered
Yep, this is a good use case. As you demonstrate later in your email,
writing mutually-exclusive rendered expressions for a set of components can
get nasty.
I'm not a JSTL user, so your reference to c:choose wasn't perhaps as clear
to me as it might be to others. I think this way:
if (cond1) render component 1
else if (cond2) render component 2
else if (cond3) render component 3
else render component 4
Expanding the javadoc for the component a bit would be good, mentioning that
it simplifies rendered expressions for mutually-exclusive components. The
current docs don't mention that the implicit condition associated with the
choose clauses is the rendered expression; it makes sense once I know what
the component is doing but wasn't obvious at first.
2) render index based. This behaves much like the tr:switcher
component. But instead of using facets and facet names, it uses
s:limitRendered value=#{wizard.currentStep} type=index
h:panelGroup
h:outputText value=This is wizard step 1 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 2 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 3 /
/h:panelGroup
/s:limitRendered
I'm not so sure about this. The tr:switcher makes sense to me; it chooses a
component to render by name which will not be easily broken by page changes,
and where the link between what the backing bean EL expression returns and
what facet is selected is clear (the name matches).
Selecting by index has a far smaller set of use-cases I think. And it can
promote code fragility; coupling an index returned by the backing bean with
an array defined in the page has potential for trouble. But the wizard
use-case is an example of a valid use of this functionality.
3) render multiple children. Can be used much like -v vs - can
be used for command line verbosity
s:limitRendered value=#{verbosity}
h:outputText value=#{title} /
h:outputText value=#{usage} /
h:outputText value=#{description} /
/s:limitRendered
Equivalent to this:
h:outputText value=#{title} rendered=#{verbosity =1}/
h:outputText value=#{usage} rendered=#{verbosity =2}/
h:outputText value=#{description} rendered=#{verbosity =3}/
Yes, the limitRendered approach is a little more efficient; only one EL
expression evaluated rather than 3. But any JSF developer understands the
latter, while no-one can understand the limitRendered approach without
looking up the docs first. And a pretty rare use case I would think. Worth
including perhaps if it didn't have any other negatives, but I think it
does: it forces the name of the component to be generic and the
documentation to be complex.
Now I cannot tell you all the reasons they may be useful, but I can
say that many time in Trinidad authors chose to only provide
functionality that they themselves could think of, making the
component useless for every use case they could not think of.
Re: svn commit: r674871 - /myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java
This will still crash if rc.getAgent() ever returns null. I don't
know if that's a possibility.
On 7/8/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Tue Jul 8 09:41:52 2008
New Revision: 674871
URL: http://svn.apache.org/viewvc?rev=674871view=rev
Log:
TRINIDAD-1146 - NPE from Google Bot (unknown agent)
Change order of equals(), to avoid NPE from platformName.
Modified:
myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java
Modified:
myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java?rev=674871r1=674870r2=674871view=diff
==
---
myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java
(original)
+++
myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/skin/MacOSSwitcherIcon.java
Tue Jul 8 09:41:52 2008
@@ -101,10 +101,9 @@
// Returns the Icon to use
private Icon _getIcon(RenderingContext arc)
{
-return (arc.getAgent().getPlatformName().equals(
- Agent.PLATFORM_MACOS)) ?
- _macOSIcon :
- _icon;
+return (Agent.PLATFORM_MACOS.equals(arc.getAgent().getPlatformName())) ?
+ _macOSIcon :
+ _icon;
}
private Icon _icon;
Re: [Core] MyFaces 1.2 NumberConverter fix (was Re: NumberConverter has issue with BigDecimal)
Maybe I am misunderstanding what you are asking, but if you're asking
if Java 1.5's DecimalFormat.parse(String) method incorrectly accepts
bad input and silently truncates it, I believe that it is true, and
will probably continue to be true through 6, 7, etc. After all, Sun
wouldn't want to break backwards compatability :-)
On 7/8/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Tue, Jul 8, 2008 at 12:24 PM, Martin Marinschek
[EMAIL PROTECTED] wrote:
sure, we should.
Leonardo, can you eventually take care of this (or ask Paul eventually
to take care of this ;)?
@Matze: In MyFaces 1.2, the fix is easy - just calling the setter
method, but in 1.1, this ParsePosition thing has to be used? Or is
this ParsePosition thing to be used all over?
well, in 1.2 I am only interested in the fix.
SInce that guy is using Java5.
The RI already made my suggested fix.
Since I haven't got feedback here,
I haven't committed it.
In MyFaces 1.2.x (trunk) I am doing it now.
Thanks,
Matthias
regards,
Martin
On 6/17/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
please check:
https://issues.apache.org/jira/browse/TRINIDAD-1124
since myfaces 1.2 is running on Java5, do we want the above fix in
f:convertNumber / as well ?
Sure, we have to double-check with the TCK, but just curious.
-Matthias
On Mon, Jun 16, 2008 at 6:03 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn that guy on. So, that fixes it.
Sandbox still still requires Java1.4, right?
-matthias
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe [EMAIL PROTECTED]
wrote:
BigDecimal converter could solve this problem, maybe this value is
converted
as double or float as is.
ok, the demo was a little bit to simple.
We want currency formatting etc. Means what the convertNumber actually
does.
-Matthias
regards
Leonardo Uribe
On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf
[EMAIL PROTECTED]
wrote:
Hi,
perhaps someone of you knows a workaround for this:
Take this JSP code:
h:inputText value=#{bean.number}
f:convertNumber /
/h:inputText
For instance, when the entered value is 333.111 the actual stored
value is 333.11099899955582804977893829345703125
I think the mathematic explanation for that in here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
My users want to have 333.111 instead of the accurate value...
Any ideas?
Thanks!
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: Update regarding FlexFaces/Alchemy project and request to place a link to the project from MyFaces Wiki page
Sure, that's what the section is for. On 7/14/08, Jihoon Kim [EMAIL PROTECTED] wrote: So that is the update and I was hoping if I could modify the Frameworks related to JSF section within the MyFaces Wikipage to include a link to FlexFaces project in order to increase the exposure of the project to the mass.
Re: [Idea] reCAPTCHA JSF component
I think what Manfred is suggesting is that we implement a reCAPTCHA component specifically rather than captcha in general. For those people who want to secure their applications and promote digital book scan correcting at the same time :-) On 8/14/08, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Manfred, I already implemented one http://myfaces.apache.org/tomahawk/tagdoc/t_captcha.html :). On Thu, Aug 14, 2008 at 11:03 PM, Manfred Geiler [EMAIL PROTECTED] wrote: Just came across the http://recaptcha.net/ website and wondered if anyone is willing to develop (and contribute) a reCAPTCHA JSF component for Tomahawk? From the website: reCAPTCHA is a free CAPTCHA service that helps to digitize books. A CAPTCHA is a program that can tell whether its user is a human or a computer. You've probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from bots, or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs. Shouldn't be that difficult. There are already some implementations for different languages/systems but none yet for JSF: http://recaptcha.net/resources.html So, when beijing08 bores you - this is your opportunity! ;-) --Manfred -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
RFC: Fundamental Failing of JSF -- binding your domain objects to your UI
Rob Williams describes some of the pain I've experienced in the past with JSF. You have complicated Domain dynamic hierarchies. You don't want to be trying to create a dynamic hierarchy of Data Transfer Objects that you then have to maintain, populate and transfer. So what do you do? Ryan chimed in that if we don't come up with a solution for JSF 2.0, we'll be living with the current situation for the next 3-4 years... Fundamental Failing of JSF, Some Ideas for Overcoming http://www.jroller.com/robwilliams/entry/fundamental_failing_of_jsf_some Who's got some ideas? My only idea up to this point has been to generate the DTOs with similar templates I use for generating my ORM (Cayenne or JPA) objects, then manually doing the transfer. Or, in other cases, cripple the app usability and simplify the input pages. Example: Customer can have multiple addresses, emails, phone numbers, lists of accounts, etc.
Re: [VOTE] Having a component module in MyFaces commons
+1 only for components that don't render anything, like t:saveState
Re: [orchestra] clirr-orchestra-1.2-to-1.3.txt
On Fri, Oct 24, 2008 at 5:27 AM, Simon Kitching [EMAIL PROTECTED] wrote: The latest maven-clirr-report plugin unfortunately crashes on orchestra, but I have created a report using clirr trunk; please see here: http://people.apache.org/~skitching/orchestra-core-1.3/clirr-orchestra-1.2-to-1.3.txt I took a look at this since I wasn't sure what it was. I'm guessing it's some kind of api changelog report. Unfortunately, it's in German (at least, that's my guess). -Mike
http://myfaces.apache.org/tomahawk/source-repository.html has broken online svn link
http://myfaces.apache.org/tomahawk/source-repository.html incorrectly gives the online svn repository link as follows: http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/tomahawk-site I'm guessing it should be: http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk
Re: Incorrect versions for MyFaces on http://www.apache.org/licenses/exports/
Manfred, You still need to take action on this. Nothing has changed on this issue except the url. It's been 18 months. Since the code is in myfaces-shared, I'm guessing it affects both MyFaces Core and Tomahawk. There's some other stuff in Tomahawk now that might qualify it too, but I haven't evaluated it. On Tue, Feb 20, 2007 at 10:52 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: Does this help? #Generated by Maven #Thu Apr 13 14:18:08 EDT 2006 version=2.0.0 groupId=org.apache.myfaces.shared artifactId=myfaces-shared-impl So perhaps the change that needs to be made is to have it say myfaces-shared 2.0 rather than simply 2.0? http://www.apache.org/licenses/exports/ On 2/20/07, Dennis Byrne [EMAIL PROTECTED] wrote: I'm not sure why 2.0 is there. Perhaps I was thinking the version of the shared lib. Anyone know which version of the shared lib we had when encryption was brought in? Dennis Byrne On 2/20/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Manfred, The crypto page contains the incorrect version numbers for MyFaces. Apache MyFaces Project Product NameVersionsECCNControlled Source Apache MyFaces development 5D002 ASF 2.0 and later 5D002 ASF I'm not sure where 2.0 came into this, but we started allowing cryptography as of Myfaces version 1.1.2. See http://issues.apache.org/jira/browse/MYFACES-742 for details. As pmc-chair, you should have the karma to update this page according the instructions at this url: http://www.apache.org/dev/crypto.html#sources -- Dennis Byrne
Re: Promoting the s:limitRendered component as t:renderOne
What about Simon's suggestion that we promote it to commons instead of Tomahawk? Any reason not to go down that path? On Wed, Nov 12, 2008 at 8:21 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Refactoring is done. Tomorrow will promote the component to Tomahawk. On Wed, Nov 12, 2008 at 11:00 PM, Hazem Saleh [EMAIL PROTECTED] wrote: We are one team. On Wed, Nov 12, 2008 at 8:47 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Hazem, I have been really busy, thank you for volunteering to promote my component, I really appreciate it. -Andrew On Wed, Nov 12, 2008 at 9:12 AM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Simon, I can work on this task. On Wed, Nov 12, 2008 at 5:20 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, There was a discussion a while ago on this list about promoting the sandbox s:limitRendered component (written by Andrew Robinson) into tomahawk. There seemed to be general agreement that it was useful, but that some rework should be done, including: * renaming to t:renderOne * simplifying so that it only supports rendering one child, not N. * improving the documentation. There was also discussion about whether it should go into Tomahawk or into the new commons-components module (as it doesn't actually render any html). Although it was agreed to promote into Tomahawk, it looks like nothing actually happened. I was reminded of this today, as I found a situation where it would have been very useful... I'm just reminding people that it exists. I'm off on holiday soon for a few weeks so won't be able to do anything in the near future, but if no-one has dealt with it before I'm back then I intend to do the agreed work to get it ready for promotion. Cheers, Simon -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
Re: Promoting the s:limitRendered component as t:renderOne
It'd make a lot more sense to have the vote be to promote the component to Commons since that's the consensus so far, instead of voting against it being promoted to Tomahawk. On Thu, Nov 13, 2008 at 4:29 PM, Hazem Saleh [EMAIL PROTECTED] wrote: In the old discussion, there was a vote that was already done, and the vote determined promoting the component to Tomahawk. Should I make a new voting and suspend the component promotion to Tomahawk ? On Thu, Nov 13, 2008 at 10:15 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: sounds good to me. regards, gerhard 2008/11/13 Andrew Robinson [EMAIL PROTECTED] Since it doesn't render anything, perhaps it should? On Thu, Nov 13, 2008 at 12:27 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: What about Simon's suggestion that we promote it to commons instead of Tomahawk? Any reason not to go down that path? On Wed, Nov 12, 2008 at 8:21 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Refactoring is done. Tomorrow will promote the component to Tomahawk. On Wed, Nov 12, 2008 at 11:00 PM, Hazem Saleh [EMAIL PROTECTED] wrote: We are one team. On Wed, Nov 12, 2008 at 8:47 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Hazem, I have been really busy, thank you for volunteering to promote my component, I really appreciate it. -Andrew On Wed, Nov 12, 2008 at 9:12 AM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Simon, I can work on this task. On Wed, Nov 12, 2008 at 5:20 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, There was a discussion a while ago on this list about promoting the sandbox s:limitRendered component (written by Andrew Robinson) into tomahawk. There seemed to be general agreement that it was useful, but that some rework should be done, including: * renaming to t:renderOne * simplifying so that it only supports rendering one child, not N. * improving the documentation. There was also discussion about whether it should go into Tomahawk or into the new commons-components module (as it doesn't actually render any html). Although it was agreed to promote into Tomahawk, it looks like nothing actually happened. I was reminded of this today, as I found a situation where it would have been very useful... I'm just reminding people that it exists. I'm off on holiday soon for a few weeks so won't be able to do anything in the near future, but if no-one has dealt with it before I'm back then I intend to do the agreed work to get it ready for promotion. Cheers, Simon -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
Re: [VOTE] promote the s:renderOne to Commons
+1 On 11/14/08, Grant Smith [EMAIL PROTECTED] wrote: +1 On Fri, Nov 14, 2008 at 7:41 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On Fri, Nov 14, 2008 at 4:36 PM, Andrew Robinson [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 4:21 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: +1 2008/11/14 Cagatay Civici [EMAIL PROTECTED] +1 On Thu, Nov 13, 2008 at 11:06 PM, Hazem Saleh [EMAIL PROTECTED] wrote: +1. On Fri, Nov 14, 2008 at 1:05 AM, Hazem Saleh [EMAIL PROTECTED] wrote: [ ] +1 - Yes, promote it to Commons. [ ] +0 - I do not know. [ ] -1 - No, do not promote it to Commons. Thanks, -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Grant Smith
Re: [Trinidad] move NullChangeManager to public API
I'd say that there's no reason to deprecate a class clearly packaged as trinidadinternal. On 11/14/08, Jeanne Waldman [EMAIL PROTECTED] wrote: Actually, I decided to be on the safe side to deprecate it, even if it is just for one release. Jeanne Jeanne Waldman wrote, On 11/14/2008 9:03 AM PT: You know this class best, Prakash, so I will remove it. Jeanne Prakash Udupa wrote, On 11/13/2008 3:46 PM PT: I support moving it to public package, but instead of deprecating the internal copy can we just remove it ?. * NullChangeManager is default ChangeManager when there is none explicitly registered. * The only use is in org.apache.myfaces.trinidadinternal.context.RequestContextImpl, very very very unlikely there are any external usages. Thanks, Prakash Simon Lessard wrote: Sounds acceptable to me. On Thu, Nov 13, 2008 at 6:03 PM, Jeanne Waldman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: adding [Trinidad] to the subject for those of you filtering. Jeanne Jeanne Waldman wrote, On 11/13/2008 2:23 PM PT: Hi there, I'd like to move the import org.apache.myfaces.trinidadinternal.change.NullChangeManager class from the internal package to the public package. I can leave the internal copy there and deprecate it, like I see we've done //FastMessageFormat/./ It is a generally useful class and our framework that includes Trinidad jars uses it. Let me know your thoughts. Thanks, Jeanne
Re: svn commit: r720358 - in /myfaces/portlet-bridge/core/tags/portlet-bridge-1.0.0-alpha-3: api/src/main/resources/META-INF/NOTICE.txt impl/src/main/resources/META-INF/NOTICE.txt
Just a comment that Sameo isn't useful if someone doesn't see this in the context of the previous commit. On Mon, Nov 24, 2008 at 7:02 PM, [EMAIL PROTECTED] wrote: Author: sobryan Date: Mon Nov 24 16:02:10 2008 New Revision: 720358 URL: http://svn.apache.org/viewvc?rev=720358view=rev Log: Sameo
Re: [VOTE] Support new JSR for the Portlet 2.0 Bidge for JavaServer Faces 1.2
+1 On Tue, Jan 20, 2009 at 4:04 PM, Scott O'Bryan darkar...@gmail.com wrote: Hey community, Oracle is trying to open up a new JSR for the Portlet 2.0 Bridge. Originally this was part of the JSR-301 but there was a slight misunderstanding of the intentions of the specs regarding release dates. To make a long story short, instead of doing both the specifications for Portlet 1.0 and 2.0 as part of the JSR, it's being split up. The Project lead will be Michael Freedman who is a MyFaces committer and has been very active on the Apache MyFaces Portlet Bridge project and he was also the spec-lead for the JSR-301. The Apache implementations of these specifications are being written as the eventual R.I.'s for the bridge projects. In any case, should Apache MyFaces put its vote in for the formation of this JSR? Understand that this is not a vote for a project or spec, just to allow the JCP to start a JSR to support this project. I have gotten word from Apache that this can be done if a community decides to support it. Since the Apache MyFaces Portlet Bridge is being developed as the eventual R.I. and Oracle has been very open to aiding the OpenSource development of this bridge here at Apache, I think it's a good opportunity for us to support the JCP and, in particular, the Portlet Bridge Projects. Vote: [ ] +1 to support the formation of a new JSR for the Portlet Bridge 2.0 [ ] +0 don't really care, it's just a silly green checkmark on the ballot [ ] -1 don't put the green checkmark on the ballot, Apache shouldn't support the JCP Thanks, Scott O'Bryan
Re: [MFCOMMONS-3] mc:exportActionListener does not work with Facelets
Make sure you're doing all work in the JSF component, and none in a JSP tag handler. The tag handler should simply assign properties set on the tag to the component. That will take care of the problem in general. There are specific cases where no component exists that have to be handled by writing an equivalent facelet tag handler (such as updateActionListener). On Wed, Jan 28, 2009 at 12:40 PM, Hazem Saleh haz...@apache.org wrote: Hello, I was digging in the exporter defect with Facelets[1], After a little investigation, I found that Facelets needs a special implementation for the listener tag handler[2]. Is this correct? and Are there any possible better ways for solving this defect? Thanks! [1] https://issues.apache.org/jira/browse/MFCOMMONS-3 [2] https://facelets.dev.java.net/source/browse/*checkout*/facelets/src/java/com/sun/facelets/tag/jsf/core/ActionListenerHandler.java?rev=1.3.2.1. -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
Re: [Core] Annotation processing discussion (attn: Jan Kees)
A simple pluggable API sounds like a reasonable approach to me. For
some situations, a pure reflection scanner might work better. For
others, it won't scale. You might need to temporarily switch to a
different scanner to determine if it's the cause of some particular
bug. Or perhaps the target appserver itself provides some form of
high-optimized scanner.
On Fri, Feb 27, 2009 at 4:31 PM, Curtiss Howard
curtiss.how...@gmail.com wrote:
Hi all,
I'd like to take this opportunity to address some concerns I have with
the way annotation processing is done. I take interest in this
subject due to the extensive amount of work I have done in this area,
and I feel that I can shed some light on possible performance issues.
This message is mainly addressed to Jan-Kees van Andel as he is doing
the work on the MyFaces annotation processing engine, but of course
community input is always welcome. I will address some points that JK
raised in a previous thread on the user mailing list:
- Currently, I'm using the xbean-finder library from Geronimo for the
processing stuff. This library uses ASM under the hood which worries
me, since ASM is a widely used library and it has lead to many
classloading issues because of other frameworks packaging different
versions of ASM.
I would strongly recommend that MyFaces does NOT move away from doing
class scanning with ASM (or some other bytecode scanning library) as
the only other alternative is pure reflection and the performance in
that case does not scale well at all.
- I have also created an annotation scanner of my own, which is
actually quite fast and doesn't have a dependency on any library,
except Java.
Since this scanner has no external dependencies, I'm tempted to
believe this is a reflective scanner. If not, did you write a
bytecode scanning library?
I don't think that making the annotation scanning code pluggable is
very useful since the xbean-finder library is already very easy to
use.
The one major concern with the xbean-finder library is that it
assembles a list of all the JARs on the classpath and scans all of
them. This is bad for a number of reasons:
1. The number of JARs to scan is _enormous_ in a typical customer
application running on a typical (i.e., bloated) appserver.
2. By indiscriminately scanning JARs that are on the classpath but not
necessarily part of the application you open yourself up to
potentially pulling in random annotations that could have negative
effects on the application.
Now, xbean-finder has a way for you to specify that you only want to
include JARs up to a certain point in the Classloader hierarchy, but
FaceConfigurator is not currently doing this :) and there is at least
one appserver I know of where even that approach wouldn't work since
applications are allowed to reference shared libraries that sit
apart from the normal classloader hierarchy. At a minimum, I think
FacesConfigurator would need to allow pluggability for integrators to
decide how to populate xbean-finder with its set of Classloaders.
In terms of pluggability, what I'd like to see is a simple interface
that abstracts away annotation scanning. This would be good for two
reasons: first, appservers that integrate MyFaces would be able to
take advantage of performance benefits that may arise from tight
coupling with their runtime (not to mention that they may need to
customize the classpath that xbean-finder or the like searches). And
second, this is a good practice in general as MyFaces shouldn't
necessarily be tied to xbean-finder. There may very well be better
solutions, and being able to plug them in would help in the long run.
My proposal for such an interface is this:
public interface AnnotationScanner {
public CollectionClass getAnnotatedClasses (Class annotationClass);
public CollectionMethod getAnnotatedMethods (Class annotationClass);
public CollectionField getAnnotatedFields (Class annotationClass);
public CollectionPackage getAnnotatedPackages (Class
annotationClass);
}
This interface is very similar to xbean-finder, and with good reason:
as you stated, it's a simple API to work with. FacesConfigurator
would need minimal changes to adapt to this interface. The advantage
here is, again, more freedom in how annotation scanning is performed.
Also, I would propose a factory that creates these instances with the
FacesContext (that should be enough context for implementers to work
with).
Please let me know what you think. Thanks,
Curtiss Howard
Re: [VOTE] MyFaces 2.0 optimization options
Unfortunately, I don't have any knowledge about the ajax work you are all doing. However, I am -1 on anything that tries to intentionally break spec compatibility, such as reusing the f: namespace. Even if it's not explicitly spelled out, we know that it's against the spirit of the spec. I find it impossible to believe that there are not better approaches. And the reality is that the actual tags used in the namespace are under the control of the user anyway. If someone wanted to map mfx: as f:, it's trivial to do so in both jsp and in facelets. But why would we encourage that behavior? On Mon, Apr 27, 2009 at 9:25 AM, Matthias Wessendorf mat...@apache.org wrote: ok, let's start with t:ajax We can always add a new JAR, for mfx:ajax... But to get this started, I am fine with the following: 1.) +1 2.) +1 3.) -0 4.) +1 (I will do that some when later) I think this now we have some kinda agreement, right ? On Mon, Apr 27, 2009 at 3:20 PM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 27, 2009 at 3:17 PM, Ganesh gan...@j4fry.org wrote: Hi, The mf:ajax solution is the only one that completely breaks compatibility with Mojarra. Applications using mf:ajax would simply fails on Mojarra. None not when that is an extra JAR, that is just shipped with the myfaces core release. -M of solutions [1] to [3] would do so. Alex and me don't have a binding vote, but it'll be us implementing this and we are both -1 on mf:ajax. mf:ajax is also worse than t:ajax because it doesn't bring myfaces Javascript to Mojarra users. The Mojarra Javascript needs a lot of improvement... Best Regards, Ganesh -1 b/c that adds an odd dependency to tomahawk... mfx:xyz does make sense to be the home for myfaces core improvements. -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [source control] git and the ASF ...
I don't know much about git, but I know that other committers on Apache Cayenne use git to commit to the Cayenne svn, so it's certainly possible to do what Andrew suggests. From my limited git understanding, that's the typical practice of using git -- as a front-end to svn or cvs. On Fri, May 15, 2009 at 4:08 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2.0] an experiment ?
Yes, I looked at this library for GWT work a couple weeks ago. It's compatible in theory, but not in practice. On Wed, May 27, 2009 at 6:23 AM, Ganesh gan...@j4fry.org wrote: AFAIK ExtJS may not be altered and resold commercially - they have a 2nd commercial license. The whole thing is developed commercially. IMHO they use OS just to get their excellent product into the market, but they don't have the OS spirit.
Re: [jira] Created: (TOMAHAWK-1426) Next and Previous facets
Is this really a bug? I'd say it's a feature. Some design experts insist that buttons merely be greyed out rather than removed when inactive. That would not be possible if the next/previous facets are not rendered at all times. I'd say that the children of that facet should be able to determine if they should render themselves (or grey themselves out), not the facet itself. On Thu, Jun 4, 2009 at 6:11 AM, Gerhard Visagie (JIRA) dev@myfaces.apache.org wrote: Next and Previous facets Key: TOMAHAWK-1426 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1426 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Environment: All env Reporter: Gerhard Visagie When the next and previous facets are rendered, they get rendered regardless if there is aa next or previous screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: slf4j and myfaces
I'd strongly prefer to see JUL instead of something else (including JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL, -0.9 slf4j On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario
Re: [VOTE] jul instead of commons-logging
+1 On Tue, Jun 9, 2009 at 2:56 PM, Curtiss Howardcurtiss.how...@gmail.com wrote: On Tue, Jun 9, 2009 at 2:32 PM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html +1 Curtiss Howard
Link to sandbox snapshots points to Nov 2008 version
I was looking for a 1.1.9 sandbox snapshot prebuilt. Our link to the maven repository points to a Nov 2008 version. http://wiki.apache.org/myfaces/FAQ#download-other-stuff I looked around for a bit trying to find something more current, but I wasn't able to do so. Do we no longer produce sandbox snapshots?
Re: Issues with the Facelets implementation
For awhile, 2.0 changes for facelets were being committed to the JSF_2_0_0_from_HEAD_20080606_BRANCH facelets branch. I'm not sure if that's still the case or if the branch was forked elsewhere. On Wed, Aug 5, 2009 at 9:11 AM, Matthias Wessendorfmat...@apache.org wrote: On Wed, Aug 5, 2009 at 3:03 PM, Curtiss Howardcurtiss.how...@gmail.com wrote: Hi, I just wanted to let everyone know that with a couple tweaks to the Facelets implementation I've been able to get the Mojarra Guess Number 2.0 custom taglib working, which does some client-side JS validation. It looks like the 2.0 codepath is looking very good so far! However, in the process I've noticed that the Facelets implementation we're using is a bit... out of date, at least with respect to the Facelets taglib parser. It seems to be geared towards version 1.0 documents, and the demo app I'm working with ships a 2.0 version document. Due to the parser only understanding 1.0 documents, it turns on DTD validation and turns off namespace handling. The problem, of course, with recent versions of the Facelets taglib document is that it does schema validation and is namespace-aware. So what's the deal with the Facelets implementation we're using? I'm guessing it's out of date, or at least portions of it are. Is it going to be upgraded or should I try to make the taglib parser do a dual-parsing approach? If so, I've got a few more questions :). Let I am pretty sure that all new Facelets stuff has been only added to the JSF RI. Perhaps one from the EG could state on that... me know what you guys think. Thanks, Curtiss Howard -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Issues with the Facelets implementation
Probably in the facelets repository, if it's not part of the JSF 2.0 implementation. :pserver:user@cvs.dev.java.net:/cvs Branches include: JSF_2_0_0_AJAX JSF_2_0_0_AJAX_20080713_BRANCH JSF_2_0_0_from_HEAD_20080606_BRANCH On Thu, Aug 6, 2009 at 9:26 AM, Curtiss Howardcurtiss.how...@gmail.com wrote: Can anyone point me to where the Facelets 2.0 repository is? I'd like to get a copy of the facelets 2.0 taglib schema, but can't seem to find it... Thanks, Curtiss Howard
Re: MyFaces 2.0 f:ajax question
Looking at someone else's code and then writing your own version is a no-no. However, there's a legal way to deal with it. Clean-room reverse engineering. Here's an example of how it was done with wireless driver support for linux -- good overview of the proper process. http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess Werner can write specs of how it should work (which it sounds like he has already done). Just be careful not to say how to implement the behavior. On Thu, Sep 3, 2009 at 8:53 AM, Jan-Kees van Andeljankeesvanan...@gmail.com wrote: +1. Same opinion as Michael. 2009/9/3 Michael Concini mconc...@gmail.com: +1. Better to be safe than sorry here in my opinion. Matthias Wessendorf wrote: On Thu, Sep 3, 2009 at 12:29 PM, Curtiss Howardcurtiss.how...@gmail.com wrote: an interesting note from the Apache Harmony project, we got on legal@: snip Harmony, OTOH, says that they have been extremely cautious and have not allowed any developer to work on any part which they have previously been exposed to. This is largely precautionary beyond necessity. /snip perhaps we should also ensure a policy like that ?! +1. I can't speak for everyone, but that is definitely how my company operates. IANAL, but I've been lectured by several and my concern is that if MyFaces developers take the attitude that seeing how the RI does it isn't a big deal then my role on this project may be in jeopardy because I won't know if I've been inadvertantly exposed to a copy-but-not-really-a-copy-and-paste of Sun code and it could expose my company to all sorts of unforeseen legal implications. +1 I know it seems silly to be so paranoid about code that's available freely, but the reality is that MyFaces is shipped in commercial products and it would be unethical to leave those products vulnerable to legal attack because they may be violating Sun's IP unknowingly. There is precedent here... remember SCO? unfortunately yes... So, in this case I strongly suggest that MyFaces contributors follow the advice of the legal lowest common denominator (or in this case perhaps it's the greatest common denominator :D) and not look at RI code AT ALL. +1 Apache had a (similar) issue in the past. JBoss sent a *letter* to Apache, as they thought some code from JBoss container was looking identically... [1] Sure we aren't about copying code here, but I attach this _resource_ more as an FYI. -Matthias [1] http://markmail.org/message/5v6kuqp7rgmn35fo Thanks, Curtiss Howard
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for jul -- it's not ideal, but it's the standard and doesn't require any dependencies. On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith work.gr...@gmail.com wrote: +1 java.util.logging.Logger On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote: +1 for JUL Antonio Petrelli wrote: 2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio -- Grant Smith
Deprecating t:updateActionListener in 1.2, removing in 2.0?
Should we consider deprecating t:updateActionListener in 1.2 and removing it in 2.0 now that f:setPropertyActionListener exists? Perhaps for 1.2, we should consider making the tag an alias for f:setPropertyActionListener component rather than a separate component. As far as I know, there is no intentional difference in behavior between the tomahawk component and the core component. I know for facelets that f:setPropertyActionListener is facelets-aware and works better for passing objects between template fragments. I'm pretty sure that you can change the underlying object using f:setPropertyAL and have it reflected in the caller, but you cannot do so with t:updateAL as this was why I ended up switching over all of my code a few years back.
Re: [jira] Resolved: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
Really?
I'd think if the direct child t:dataList isn't rendered, we probably
shouldn't output the tag.
But it's our own component, so we can make whatever rules we want.
On Wed, Feb 3, 2010 at 2:31 PM, Leonardo Uribe (JIRA)
dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TOMAHAWK-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1485.
--
Resolution: Not A Problem
Assignee: Leonardo Uribe
t:dataList iterate over a list without check for rendered property on the
component. The fact that the component is not rendered does not means that
the value is skipped. t:dataList works as expected.
t:dataList should not render li element when iterated element is not
rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9,
commons-el 1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging
1.1.1
Reporter: Bauke Scholtz
Assignee: Leonardo Uribe
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Ext-CDI] additional project name
Jodi is too similar to Joda time in my opinion. http://joda-time.sourceforge.net On Mon, Feb 8, 2010 at 4:29 AM, Hazem Saleh haz...@apache.org wrote: in case of JODI it's: J ... JSF O ... cOntext DI ... Dependency Injection. I can feel the musical tone in this name more :). On Mon, Feb 8, 2010 at 11:18 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: in case of CODI it's: CO ... context DI ... dependency injection. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/8 Mark Struberg strub...@yahoo.de JODI and CODI both seem nice, but what does theystand for (especially the 'O')? LieGrue, strub --- Hazem Saleh haz...@apache.org schrieb am Mo, 8.2.2010: Von: Hazem Saleh haz...@apache.org Betreff: Re: [Ext-CDI] additional project name An: MyFaces Development dev@myfaces.apache.org Datum: Montag, 8. Februar 2010, 10:02 I suggest JODI (pronounced like the name). On Mon, Feb 8, 2010 at 10:59 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we decide to use an additional project name:+1 for MyFaces CODI regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/8 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, we have collected some ideas [1] for a cdi extensions module for jsf applications. the next version of seam will provide portable cdi extensions as well.since the extensions are portable i hope both projects will be compatible. so they aren't competitors. anyway, i think people will start to compare them.so it would be nice to have a fancy project name. it's more or less clear that we will use ext-cdi internally (jira module,...). however, ext-cdi might sound a bit strange for some users. there are some name suggestions in the wiki - 2 examples:#1 CODI (pronounced like the name)#2 CoJack it would be nice to hear your opinions about an additional name as well as about the mentioned examples.(for sure) you are welcome to add further name and/or feature suggestions to the wiki. regards,gerhard [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Drafts http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.ibm.com/developerworks/library/wa-aj-gmaps/ __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.ibm.com/developerworks/library/wa-aj-gmaps/
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
Never mind. I see in the jira issue that it's possible to drop in the old facelets implementation. That seems like the right approach to me. On Tue, Feb 9, 2010 at 1:27 PM, Mike Kienenberger mkien...@gmail.com wrote: Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] Introducing implee6 - MYFACES-2579
I agree with Leonardo that changes which affect our base requirements (jdk 6 instead of jdk 5) and which could compromise our certification warrant discussion rather than a commit-and-hope-no-one-complains attitude. Otherwise, without discussion, how would we know that Mojarra allows it? On Thu, Mar 11, 2010 at 4:24 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? The position from jsr-314-open mail list is as long as TCK test pass we could do it, and if mojarra has something similar, we could do the same. If something happens we could remove it and that's all (that means if something happens we'll be forced to remove this feature from myfaces and that is risky), since this is not part of the standard, but users should be aware of that implication. Note from this change, myfaces requires JDK 1.6 to be compiled, but the classes inside api and impl modules requires JDK 1.5. Please don't make this problem bigger as it is... I believe it is important to discuss the possible implications of a change before commit it and make it clear to people (that's one idea about opensource, give the people the power to know what's happening behind courtains and the tools to change it). Just put some code because you like it, or it is cool not always is enough. That's common sense, right?. Also you have to keep into account this is a standard of some spec, not just a custom library, so a lot of care is required before add a new feature outside the spec. So, the idea is not make a problem bigger or start a bizantine war that leads to nowhere, just benefit the community throught constructive discussion, but for a discussion it is necessary a clear and rational position, possible courses of action before start and a open mind, that means, give yourself the possibility of change of opinion anytime. Please note the benefit of this exercise, if someone wants to check why this stuff is done in this or that way, there is a source of knowledge through the mailing list. Please think carefully about what opensource word means. regards, Leonardo Uribe Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk
Re: myfaces wiki
I'm happy with the current wiki, and I haven't enjoyed working with confluence. We also seem to have a lot of assorted problems with it on the Cayenne project. But I'm not opposed to switching if that's what everyone else really wants. On Wed, Mar 24, 2010 at 2:35 PM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Proposal - Automated webapp tests
You might want to consider Selenium http://seleniumhq.org/ Apache 2.0 license On Thu, Mar 25, 2010 at 8:25 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, As we currently only have normal JUnit tests for automated testing in MyFaces Core, it would be really great to have a way to test MyFaces Core automatically in a real webapp at build time with maven. Of course, we currently have the test-webapp, but we still have to check each page manually here, if we want to test everything, which is long-winded. To accomplish something like that we could use test frameworks like e.g. Canoo WebTest or HttpUnit + Jetty or something similar. I also want to mention JSFUnit here, although we won't be able to use it since it is LGPL licensed. The goal of this GSoC project would be to find alternatives and also to find the best-fitting test framework for MyFaces Core. Then the goal would be to integrate it with MyFaces Core, to define rules and provide how-tos and to write a bunch of test cases. This would help us enormously in ensuring and improving the quality of MyFaces Core by getting a far bigger test coverage and more possibilities to test. What do you think? Are there any students who are interested in working on this? Regards, Jakob
Re: How do you partition SVN commits in myfaces
I'm not an expert on svn so I can't answer your specific question, but if you can't find a solution, you could commit everything to a branch, then merge to trunk individually. On Sun, Apr 4, 2010 at 7:08 AM, Mark Struberg strub...@yahoo.de wrote: Hi! I have a really fu SVN problem. I did a lot changes to EXTCDI, and wrote a few tests. Now I don't like to commit the whole core/src/test in one commit but split it into single commits to match the Jirs issues. But once I svn add core/src/test, I cannot commit the files beneath it independently because whenever I try to commit solo files beneath the tree, I always get a SVN failure this file is not currently under SVN control which is completely wrong as svn status clearly showes a 'A'. So, am I now forced to commit the whole soup in one big checkin? This did even work in CVS... oki, any tips out there how to resolve this issue? LieGrue, strub __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
