Re: [VOTE] release for myfaces builder plugin 1.0.2
Any PMC community member who wants to vote? We have two PMC +1 (Grant and me), just one more to continue this release. regards Leonardo Uribe On Thu, Oct 23, 2008 at 1:12 PM, Grant Smith [EMAIL PROTECTED] wrote: +1. Sorry it took so long... On Thu, Oct 23, 2008 at 10:52 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 6:02 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi Here's how any developer can help us test the distribution. Add this to your pom.xml (a node inside project ) pluginRepositories pluginRepository idtest-builder-plugin-1.0.2/id nameTest repository for myfaces-builder-plugin 1.0.2/name urlhttp://people.apache.org/~lu4242/m2-plugins-102 http://people.apache.org/%7Elu4242/m2-plugins-102/url /pluginRepository /pluginRepositories then use myfaces-builder-plugin: plugins plugin groupIdorg.apache.myfaces.buildtools/groupId artifactIdmyfaces-builder-plugin/artifactId version1.0.2/version . some stuff /plugin plugins myfaces core 1.1.x, 1.2.x and tomahawk use myfaces-builder-plugin so the most easy way is modify its pom (api/pom.xml, impl/pom.xml for example) for use it (just add the pluginRepository and change version to 1.0.2), then mvn install and check the generated artifacts. I have already tested it as proposed and everything seems to be fine. Someone with time to test this artifacts? Help is most welcome. regards Leonardo Uribe regards Leonardo Uribe On Tue, Oct 21, 2008 at 11:58 AM, Grant Smith [EMAIL PROTECTED]wrote: Ooops that sounded ungrateful. It's a wonderful plugin, and I appreciate the hard work gone into it, but I honestly have no time to test :( On Tue, Oct 21, 2008 at 9:56 AM, Grant Smith [EMAIL PROTECTED]wrote: +0 sorry no time to learn how to test this. On Tue, Oct 21, 2008 at 9:25 AM, Hazem Saleh [EMAIL PROTECTED]wrote: +1. On Tue, Oct 21, 2008 at 2:47 AM, Leonardo Uribe [EMAIL PROTECTED]wrote: +1 regards Leonardo Uribe On Mon, Oct 20, 2008 at 7:47 PM, Leonardo Uribe [EMAIL PROTECTED]wrote: Hi, I was running the needed tasks to get the 1.0.2 release of Apache MyFaces Builder Plugin out. This artifacts are necessary to release myfaces core 1.2.5 (the first myfaces 1.2.x version to fully use myfaces builder plugin). Note that a snapshot version is used for build myfaces core 1.2.x and 2.0.x branch. Several bug fixes has been done on some java annotations and on plugins. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.2 (only myfaces-builder-plugin, myfaces-builder-annotations, myfaces-plugin-parent) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-plugins-102http://people.apache.org/%7Elu4242/m2-plugins-102 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- 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 -- Grant Smith -- Grant Smith -- Grant Smith
AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I don't want to hear anything about certain workarounds that I could have used in these cases as I think that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as by design ;-) However, the missing flow part is nearly there and already usable. Summarizing it can be stated that I'd propose you to rewrite conversation handling for the next major release and I'd be willing to contribute. Note that I don't want to drop support for these named conversations, but I think that this usecase is not the default one for conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the naming-conversation-way optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
persistence operations within the persistence context associated with
the caller. In the case of a search type page, that means that the
search dialog just returns the *key* of the record that the user
selected and the caller must then load that object again by key. We
don't find that any major inconvenience.
I actually think this design is an advantage; when a java method calls a
method on a different class, the called code cannot mess with the
private members of the caller, and this is *good*. Equally, when a JSF
view calls another, I don't think that allowing the called view to
mess with the conversation-state of the caller is good. JSF already is
such a loose programming language that we are losing all the benefits
of a strictly-typed programming language; JSF apps can easily degenerate
into spaghetti code and I think allowing free access to
conversation-state from anywhere makes things more dangerous (though
possibly more convenient in the short term).
Mario's reply mentioned the new orchestra flow stuff that I have been
working on. However that works in the same way, just a little more
convenient: the called view(s) still run in their own environment
without access to the caller except for parameters that are explicitly
passed in. In fact, orchestra-flow isolates things even more strongly as
the called flow runs not just in a new conversation, but in a completely
different conversation-context so cannot access existing beans in other
conversation-contexts at all.
An alternative approach might be for the called view to require some
kind of helper object to be passed to it. You can do this via
f:setPropertyActionListener in the calling page. The helper object can
provide methods to do persistence operations, and they will run in
whatever conversation the helper object is in, regardless of what
conversation the called view's backing bean is in. Of course the
helper object could be the backing bean for the calling view itself.
Note that I haven't tried this; however I can't see any reason why it
wouldn't work.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view doesn't
change for these usecases at all, but the logic of the backing bean
does. My first approach was to determine the specific page bean at
runtime in the action method that navigates to this view. This action
method was supposed to register the specific page bean under a common
name. So somehow it can be said that I wanted to use polymorphic beans.
///
public String action() {
Conversation conversation = getCurrentConversation();
switch (criterium) {
case CASE_A:
conversation.setAttribute(commonBean, specificBeanA);
break;
case CASE_B:
conversation.setAttribute(commonBean, specificBeanB);
break;
case CASE_C:
conversation.setAttribute(commonBean, specificBeanC);
break;
default:
throw new IllegalStateException(); // shouldn't occur anway
}
return outcome;
}
view.xhtml
h:commandButton action=#{commonBean.save} /
\\\
However, that wouldn't work for two reasons:
- Orchestra only knows how to resolve Spring beans as the bean
definition determines the conversation being used (well, Orchestra
doesn't know how to resolve anything, actually it's the
EL-/VariableResolver of Spring that does this job in this case). It's
only possible to resolve such
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
hello, are the wiki pages [1] and [2] up-to-date? regards, gerhard [1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1 [2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2 2008/10/27 Mario Ivankovits [EMAIL PROTECTED] Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I don't want to hear anything about certain workarounds that I could have used in these cases as I think that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as by design ;-) However, the missing flow part is nearly there and already usable. Summarizing it can be stated that I'd propose you to rewrite conversation handling for the next major release and I'd be willing to contribute. Note that I don't want to drop support for these named conversations, but I think that this usecase is not the default one for conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the naming-conversation-way optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Mario Ivankovits schrieb: Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Documentation is partially there, on the website and on the wiki. But as the code is changing rapidly the docs are lagging somewhat behind. However I think it likely that that things will stabilise into their final form during this week. However (as noted in my other email) flow won't solve this issue. In fact it sets up even more strict isolation between caller and called views - deliberately. The called view cannot access any conversation-scoped data except its own - and whatever parameters it gets explicitly passed. Of course it is possible to pass as a parameter a helper object that *can* access conversation-scope elsewhere. But that is also possible to do without using orchestra-flow. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I'm not sure how the new Conversationutils.bindToCurrent would help here.. It is very useful when a conversation-scoped backing bean wants to pass one of its member objects to some other object. But I don't see how it applies to this caller/callee situation. Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... The SingleConversationScope class was recently deleted from Orchestra - as discussed on the list. Partly because there did not seem to be any use-case that it was useful for. We can resurrect it if such a use-case is found. But I don't understand the above description...how exactly does it solve the two issues that Bernhard had? Regards, Simon
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Link [1] is obsolete; it is there only for historical purposes. Link [2] is mostly up-to-date. There have been a few changes to the code that are not reflected here, but it is 95% correct and certainly good enough for a general understanding of orchestra-flow. Regards, Simon Gerhard Petracek schrieb: hello, are the wiki pages [1] and [2] up-to-date? regards, gerhard [1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1 [2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow won't solve this issue. In
fact it sets up even more strict isolation between caller and called
views - deliberately. The called view cannot access any
conversation-scoped data except its own - and whatever parameters it
gets explicitly passed.
I thought Bernhard is searching a way how to do solve this problem, and
Orchestra Flow clearly shows how to solve the search-flow-use-case without
having to build your own parameter passing framework.
For me it was clear that passing entities between conversations is a no-go; as
with any framework which allows multiple persistence context.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view
doesn't
You might treat it as workaround (which you don't want to hear),
but the latest Orchestra provides the method
convObject = ConversationUtils.bindToCurrent(object)
which allows you to attach all the aspects to any bean you'd like to.
Allowing to use that from within the spring configuration is on our
todo list.
I'm not sure how the new Conversationutils.bindToCurrent would help
here..
In your main bean you can have this switch/case to create the bean and put it
into a specific conversation, your main bean then provides a method like
getImplementation.
In your view then you write #{mainBean.implementation.xyz}.
The SingleConversationScope class was recently deleted from Orchestra -
as discussed on the list. Partly because there did not seem to be any
use-case that it was useful for.
We can resurrect it if such a use-case is found. But I don't understand
the above description...how exactly does it solve the two issues that
Bernhard had?
From discussions in the past with Bernhard I got the feeling that he don't
like the multiple-conversations per request approach. Which forced us to
create something like the view-controller scope, however, I still see no way
around that. Having the request conversation defined by the view controller
is the best we can do I think.
Ciao,
Mario
Swing Renderer
hi what is your idea about Swing Render kit? benefits may include: 1) same programming model for both desktop and web 2) ability to test programs much faster on desktop outside of web container Arash
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello,
Any new ideas that could improve Orchestra would be great.
I'm not sure at the moment exactly what this rewrite
would do; what exactly are you proposing?
Well, basically I'd refactor the ConversationContext so that it's
actually the main conversation of Orchestra. The conversation itself is
almost independent of Spring (of course, there's still an according
implementation of the Scope interface, but it will be implemented way
easier). It's possible to nest conversations, i.e. a there's a certain
hierarchy of conversations.
Each conversation has got it's own lifecycle and therefore it's possible
to register so-called conversation listeners in order to hook logic
into such lifecycle phases.
- listener.conversationStarted(ConversationEvent event);
This method will be called once a conversation starts as the name
implies. The default implementation requires the user to start
conversations explicitly, for example by calling
manager.startConversation() where manager is a ConversationManager
that you can inject into your beans (or lookup via an EL-expression).
- listener.conversationResumed(ConversationEvent event);
This method will be called once the user accesses a URL with the
according request parameter of the conversation, i.e. if the user
accesses the URL http://localhost:8080/something.jsf?conversationId=1;.
- listener.conversationSuspended(ConversationEvent event);
This method will be called once such a request as above has been processed.
- listener.conversationEnded(ConversationEvent event);
This method will be called once the user invalidates a conversation.
The following example describes the most obvious usecase:
JpaPersistenceListener
- listener.conversationStarted():
Create the persistence context and put it into the conversation.
- listener.conversationResumed():
Bind the persistence context of the conversation
- listener.conversationSuspended():
Unbind the persistence context of the conversation
- listener.conversationEnded():
Close the persistence context
No additional proxy class is needed in that case and a persistence
context is available to the whole application (you don't have to call
DAO methods through conversation-scoped beans). If you don't persistence
context support, then just don't configure the JpaPersistenceListener.
Those who know Spring Web Flow will think that I'm just proposing to do
it like Spring Web Flow does - and yeah, they're right as I think that's
the way to go. However, there's still the need for a persistence
interceptor as you're still able to use the current conversation model
of Orchestra. The difference is that such conversations will be nested
within the main conversation of Orchestra and not within a
ConversationContext.
In doing so, it's not required to specify the conversation you'd like to
use on your bean definitions, as there's just one conversation: the
current one and Orchestra is responsible for determining that one. Of
course, this approach doesn't allow you to use two different
conversations on the same view, but then you can still use the previous
conversation model of Orchestra.
The SpringSingleConversationScope (or whatever it was called like) was a
start in the right direction, but I think it's wrong to implement a
single conversation-model on a named conversation-model. I'd propose to
do it the other way around.
regards,
Bernhard Huemer
On 10/27/2008 +0100,
Simon Kitching [EMAIL PROTECTED] wrote:
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a per-scope-configuration basis! Still, the beauty of Orchestra is that it supports use-cases like: 1) Doing Order-Processing 2) Suspend task 1 and do some different things like, update customers master-data 3) Go back to Order-Processing and continue All this works without a single line of flow-description and by nicely separate the persistence contexts, so the memory of task 2 has been freed while task 1 is stil there. Also no user-interaction is required (pause, restart, etc) and no other sort of convention. On top of THAT we built the flow, so each flow separates even more by still keeping the easy-to-use multiple conversation feature. Where a flow is required (e.g. search-pages) you can use them now. So, it is not only using two conversations during the same render-request, no, it is about using different parallel conversations for different tasks without additional configuration on view level. In fact, if one finds a method how Orchestra can determin what is the CURRENT conversation we could get rid of the viewController-scope, but since Orchestra talks about beans and not about views in its innerst, that is hard to find. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Sorry, at all it is hard for me to see what is better to do it like Spring WebFlow. Ciao, Mario
[jira] Created: (TRINIDAD-1279) If ppr is enabled (vis autosubmit) on a inputtext field i have to click my submit button twice
If ppr is enabled (vis autosubmit) on a inputtext field i have to click my
submit button twice
--
Key: TRINIDAD-1279
URL: https://issues.apache.org/jira/browse/TRINIDAD-1279
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Environment: ie
Reporter: johnny petersen
If ppr is enabled (vis autosubmit) on a inputtext field i have to click my
submit button twice with the following code (which i created with the new
jdeveloper 11g)
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
%@ page contentType=text/html;charset=windows-1252%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
%@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
f:view
tr:document title=Title 1
trh:body firstClickPassed=true
tr:form
tr:inputText label=Label 1 autoSubmit=true/
tr:commandButton text=commandButton 1
action=#{test.commandButton_action2}
partialSubmit=true/
/tr:form
/trh:body
/tr:document
/f:view
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1279) If ppr is enabled (vis autosubmit) on a inputtext field i have to click my submit button twice
[
https://issues.apache.org/jira/browse/TRINIDAD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-1279.
--
Resolution: Duplicate
If ppr is enabled (vis autosubmit) on a inputtext field i have to click my
submit button twice
--
Key: TRINIDAD-1279
URL: https://issues.apache.org/jira/browse/TRINIDAD-1279
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Environment: ie
Reporter: johnny petersen
If ppr is enabled (vis autosubmit) on a inputtext field i have to click my
submit button twice with the following code (which i created with the new
jdeveloper 11g)
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
%@ page contentType=text/html;charset=windows-1252%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
%@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
f:view
tr:document title=Title 1
trh:body firstClickPassed=true
tr:form
tr:inputText label=Label 1 autoSubmit=true/
tr:commandButton text=commandButton 1
action=#{test.commandButton_action2}
partialSubmit=true/
/tr:form
/trh:body
/tr:document
/f:view
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello, The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. Well, no, you don't have to use a flow definition. Managing the conversation from a user's perspective is clearly defined as an according API will be provided. If the user doesn't call a method like conversation.invalidate() the conversation won't end. For example, I'm thinking of creating a configurable artifact that manages the lifecycle of a conversation - a so-called ConversationManager. The basic implementation would require the user to call the method manager.startConversation(), i.e. the user would have to configure the beans so that a ConversationManager will be injected. However, another ConversationManager could possibly know how to deal with annotations like @Create or @End. It would be even possible to configure a special ConversationManager that automatically creates a new conversation if you try to access it (i.e. just as it is now) and of course there's the possibility of using a flow definition for that purpose. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. Well, I'm not particularly against named conversations. I'm just saying that neither the view nor a Spring bean is responsible for determining the name of this conversation, but a special flow logic is (and I'm still not talking about flow definitions). For example, in this case I'd prefer to write a NavigationHandler for my application that knows how to deal with this usecase. Basically it uses the according API to suspend the current conversation and resume the according one. Of course, Orchestra could only do that automatically if there was something like a flow definition, but I'd prefer to expose an API so that the user is able to write such a NavigationHandler on his own. However, this approach enables you to control conversations in a more fine-grained way. For example, if you've got a master-/detail-view being surrounded by global navigation menus, you could use the exposed API so that you'll resume the conversation for the detail you've choosen previously if you select it again (of course, assuming that you only have suspended the conversation, i.e. you've clicked on a global menu entry before). Also no user-interaction is required (pause, restart, etc) and no other sort of convention. Well, of course you could say that this is a burden for the user, but it comes with great flexibility too (see my master-/detail-view example). Convenient default implementations could then reduce the complexity without limitating the user's flexibility. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Simply said, yes that's true, but the flow description doesn't have to be an XML flow definition. What I'd like to see, is an Orchestra API that allows me to describe my flows programmatically at runtime as this is a much more powerful approach for managing conversations. regards, Bernhard On 10/27/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a
[jira] Created: (TRINIDAD-1280) tr:inputFile IE javascript error
tr:inputFile IE javascript error -- Key: TRINIDAD-1280 URL: https://issues.apache.org/jira/browse/TRINIDAD-1280 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.9-core Environment: Windows XP, Internet Explorer 7 Reporter: Jim Dolinski Priority: Minor The tr:inputFile input box is not disabled on Internet Explorer. When a user enters text that does not resolve to a valid path to a file a javascript error occurs and the page is unable to process any actions until the text is removed. The problem does not occur on firefox, the input box is disabled forcing the user to enter a file path using the browse button. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-1135) Flush Cached Model for UIXCollection during broadcast
[ https://issues.apache.org/jira/browse/TRINIDAD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf reopened TRINIDAD-1135: -- Flush Cached Model for UIXCollection during broadcast - Key: TRINIDAD-1135 URL: https://issues.apache.org/jira/browse/TRINIDAD-1135 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.8-core, 1.2.9-core Environment: All Reporter: Venkata Guddanti Assignee: Matthias Weßendorf Fix For: 1.0.9-core, 1.2.9-core Attachments: trunk.patch If a UIXCollection component is used as a stamp inside another UIXCollection. The model for the collection can go stale during the broadcast of messages. This is because the model in the stamped UIXCollection could be pointing to the wrong one because of the stamp state processing during the decode/validate/update phase. The fix is to make sure that the stamped collection is using the right model based on the stamp state of the parent collection. This is done by simply calling _flushCachedModel(); at the beginning of the broadcast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1144) EL variable not set or get correctly
[
https://issues.apache.org/jira/browse/TRINIDAD-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-1144.
--
Resolution: Fixed
Fix Version/s: 1.0.10-core
1.2.10-core
Assignee: Matthias Weßendorf
reverted TRINIDAD-1135
EL variable not set or get correctly
Key: TRINIDAD-1144
URL: https://issues.apache.org/jira/browse/TRINIDAD-1144
Project: MyFaces Trinidad
Issue Type: Bug
Components: Archetype
Affects Versions: 1.2.9-core
Environment: JSF RI Mojarra (1.2_08-b06-FCS), JBoss Seam 2.0.2.SP1,
Facelets 1.1.14, Tomcat 6.0.14
Reporter: Mathias Walter
Assignee: Matthias Weßendorf
Priority: Blocker
Fix For: 1.2.10-core, 1.0.10-core
Attachments: testCase.zip
I'm using a facelet component which sets a variable to the row of a tr:table
(c:set var=entity value=#{row} /). This variable is then used in a
child table (which is also a facelet component) as source value.
In 1.2.9 this approach does not work anymore. The entity is set to the
current row of the child table and does not contain the row entity set before.
Up to 1.2.8, all works fine. I checked the fixes for 1.2.9, but could not
find a related one.
facelet tag code snippet:
ui:composition
c:choose
c:when test=${empty value}
c:set var=source value=${backingBean.list} /
/c:when
c:otherwise
c:set var=source value=${entity[value]} /
/c:otherwise
/c:choose
c:choose
c:when test=${empty eventBinding}
c:set var=binding value=${backingBean} /
/c:when
c:otherwise
c:set var=binding value=${eventBinding} /
/c:otherwise
/c:choose
tr:table value=${source} binding=${binding.model} var=row
c:set var=entity value=#{row} /
ui:insert /
tr:column headerText=Actions
tr:panelButtonBar
tr:commandLink action=#{backingBean.edit}
text=Edit partialSubmit=true rendered=#{!backingBean.editMode and
backingBean.visibleOnly} immediate=true /
tr:commandLink action=#{backingBean.save}
text=Save partialSubmit=true rendered=#{!backingBean.visibleOnly} /
tr:commandLink action=#{backingBean.cancel}
text=Cancel partialSubmit=true rendered=#{!backingBean.visibleOnly}
immediate=true
tr:resetActionListener/
/tr:commandLink
/tr:panelButtonBar
/tr:column
/tr:table
/ui:composition
xhtml code snippet:
i:ietable panelCaption=Samples backingBean=#{samples}
eventBinding=#{samplesBindings}
i:field label=ID name=id columns=6 readOnly=true/
f:facet name=detailStamp
i:ietable panelCaption=Findings value=findings
backingBean=#{findings} eventBinding=#{findingsBindings} parent=#{row}
nested=true
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1135) Flush Cached Model for UIXCollection during broadcast
[ https://issues.apache.org/jira/browse/TRINIDAD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1135. -- Resolution: Invalid Fix Version/s: (was: 1.0.9-core) (was: 1.2.9-core) this fix was not valid. Flush Cached Model for UIXCollection during broadcast - Key: TRINIDAD-1135 URL: https://issues.apache.org/jira/browse/TRINIDAD-1135 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.8-core, 1.2.9-core Environment: All Reporter: Venkata Guddanti Assignee: Matthias Weßendorf Attachments: trunk.patch If a UIXCollection component is used as a stamp inside another UIXCollection. The model for the collection can go stale during the broadcast of messages. This is because the model in the stamped UIXCollection could be pointing to the wrong one because of the stamp state processing during the decode/validate/update phase. The fix is to make sure that the stamped collection is using the right model based on the stamp state of the parent collection. This is done by simply calling _flushCachedModel(); at the beginning of the broadcast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Hi, I'm trying to release the MyFaces Portlet Bridge Master 1.0.0-alpha-3. This release was created in order to support the latest JSR-301 Public Review so that it may be tested by developers during the review process. This is still an alpha release because there is currently no testing of the R.I. I have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] release for myfaces builder plugin 1.0.2
+1 On Mon, Oct 27, 2008 at 7:43 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: Any PMC community member who wants to vote? We have two PMC +1 (Grant and me), just one more to continue this release. regards Leonardo Uribe On Thu, Oct 23, 2008 at 1:12 PM, Grant Smith [EMAIL PROTECTED] wrote: +1. Sorry it took so long... On Thu, Oct 23, 2008 at 10:52 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 6:02 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi Here's how any developer can help us test the distribution. Add this to your pom.xml (a node inside project ) pluginRepositories pluginRepository idtest-builder-plugin-1.0.2/id nameTest repository for myfaces-builder-plugin 1.0.2/name urlhttp://people.apache.org/~lu4242/m2-plugins-102/url /pluginRepository /pluginRepositories then use myfaces-builder-plugin: plugins plugin groupIdorg.apache.myfaces.buildtools/groupId artifactIdmyfaces-builder-plugin/artifactId version1.0.2/version . some stuff /plugin plugins myfaces core 1.1.x, 1.2.x and tomahawk use myfaces-builder-plugin so the most easy way is modify its pom (api/pom.xml, impl/pom.xml for example) for use it (just add the pluginRepository and change version to 1.0.2), then mvn install and check the generated artifacts. I have already tested it as proposed and everything seems to be fine. Someone with time to test this artifacts? Help is most welcome. regards Leonardo Uribe regards Leonardo Uribe On Tue, Oct 21, 2008 at 11:58 AM, Grant Smith [EMAIL PROTECTED] wrote: Ooops that sounded ungrateful. It's a wonderful plugin, and I appreciate the hard work gone into it, but I honestly have no time to test :( On Tue, Oct 21, 2008 at 9:56 AM, Grant Smith [EMAIL PROTECTED] wrote: +0 sorry no time to learn how to test this. On Tue, Oct 21, 2008 at 9:25 AM, Hazem Saleh [EMAIL PROTECTED] wrote: +1. On Tue, Oct 21, 2008 at 2:47 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: +1 regards Leonardo Uribe On Mon, Oct 20, 2008 at 7:47 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.2 release of Apache MyFaces Builder Plugin out. This artifacts are necessary to release myfaces core 1.2.5 (the first myfaces 1.2.x version to fully use myfaces builder plugin). Note that a snapshot version is used for build myfaces core 1.2.x and 2.0.x branch. Several bug fixes has been done on some java annotations and on plugins. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.2 (only myfaces-builder-plugin, myfaces-builder-annotations, myfaces-plugin-parent) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-plugins-102 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- 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 -- Grant Smith -- Grant Smith -- Grant Smith -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (TOBAGO-716) Content of tabgroup did not relayout on partial rendering
[ https://issues.apache.org/jira/browse/TOBAGO-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-716. - Resolution: Fixed Content of tabgroup did not relayout on partial rendering - Key: TOBAGO-716 URL: https://issues.apache.org/jira/browse/TOBAGO-716 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.19 Reporter: Volker Weber Assignee: Volker Weber Tabgroup content did not relayout to reflect changes of the size if reloaded by partial rendering -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1365) Input field id in error messages is not properly replaced with label text
Input field id in error messages is not properly replaced with label text - Key: TOMAHAWK-1365 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1365 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.8-SNAPSHOT Reporter: Val Blant When we have a label associated with an input field via the 'for' attribute on the label, the client id substitution is not properly handled by org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputId(). The problem is that when an error message is put together by a converter, javax.faces.convert._MessageUtils.getLabel() places the full clientId of the input component into the message text, whereas HtmlMessageRenderer replaces only the id with the label text. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1365) Input field id in error messages is not properly replaced with label text
[ https://issues.apache.org/jira/browse/TOMAHAWK-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Val Blant updated TOMAHAWK-1365: Status: Patch Available (was: Open) Input field id in error messages is not properly replaced with label text - Key: TOMAHAWK-1365 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1365 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.8-SNAPSHOT Reporter: Val Blant Attachments: TOMAHAWK-1365.patch When we have a label associated with an input field via the 'for' attribute on the label, the client id substitution is not properly handled by org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputId(). The problem is that when an error message is put together by a converter, javax.faces.convert._MessageUtils.getLabel() places the full clientId of the input component into the message text, whereas HtmlMessageRenderer replaces only the id with the label text. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1364) Preparing the exportActionListener to move from Tomahawk sandbox to MyFaces Commons
[ https://issues.apache.org/jira/browse/TOMAHAWK-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hazem Saleh resolved TOMAHAWK-1364. --- Resolution: Fixed Done in revision: 708284 Preparing the exportActionListener to move from Tomahawk sandbox to MyFaces Commons --- Key: TOMAHAWK-1364 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1364 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.8-SNAPSHOT Reporter: Hazem Saleh Assignee: Hazem Saleh Original Estimate: 24h Remaining Estimate: 24h -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hi, I'm trying to release the MyFaces Portlet Bridge Master 1.0.0-alpha-3. This release was created in order to support the latest JSR-301 Public Review so that it may be tested by developers during the review process. This is still an alpha release because there is currently no testing of the R.I. I have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Result (was Re: [VOTE] release for myfaces builder plugin 1.0.2)
Hi Thanks to all people who vote We have 5 +1 Grant Smith Hazem Saleh Werner Punz Matthias Wessendorf Leonardo Uribe so we can continue with the necessary steps to release myfaces builder plugin 1.0.2 regards Leonardo Uribe
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm trying to release the MyFaces Portlet Bridge Master 1.0.0-alpha-3. This release was created in order to support the latest JSR-301 Public Review so that it may be tested by developers during the review process. This is still an alpha release because there is currently no testing of the R.I. I have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3 http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
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
[VOTE] release for myfaces builder plugin and annotations 1.0.2
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Builder Plugin and Annotations 1.0.2. Apache MyFaces Builder Plugin is a maven plugin, used internally in other projects like myfaces core and tomahawk for generate component classes, tag classes, faces-config files, .tld files and facelets taglib files. In other words, its several maven goals provide a component kit for generate jsf components with minimal effort. Apache Myfaces Builder Annotations is a set of annotations used by Myfaces Builder Plugin to define the metadata. Apache MyFaces Builder Plugin and Annotations is available in the central Maven repository under Group ID org.apache.myfaces.buildtools. Enjoy! regards Leonardo Uribe
Re: [orchestra] clirr-orchestra-1.2-to-1.3.txt
ERROR: 7002: org.apache.myfaces.orchestra.conversation.spring._SpringUtils: Method 'public java.lang.Object getRealBean(java.lang.Object)' wurde entfernt = public java.lang.Object getRealBean(java.lang.Object) was removed -M On Mon, Oct 27, 2008 at 9:57 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (EXTVAL-4) Create junit tests cases (using shale-test) for extval
[ https://issues.apache.org/jira/browse/EXTVAL-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved EXTVAL-4. - Resolution: Fixed Fix Version/s: 1.2.1-SNAPSHOT 1.0.1-SNAPSHOT Create junit tests cases (using shale-test) for extval -- Key: EXTVAL-4 URL: https://issues.apache.org/jira/browse/EXTVAL-4 Project: MyFaces Extensions Validator Issue Type: Task Affects Versions: 1.0.1-SNAPSHOT, 1.2.1-SNAPSHOT Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.0.1-SNAPSHOT, 1.2.1-SNAPSHOT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Having a component module in MyFaces commons
The exportActionListener now depends only on MyFaces APIs, and now it is ready to move to MyFaces-common-components. On Sat, Oct 25, 2008 at 4:11 AM, Hazem Saleh [EMAIL PROTECTED] wrote: The vote has passed with the following results: +1 Glauco P. Gomes Grant Smith Matthias Wessendorf Gerhard Petracek Mike Leonardo Volker Andrew Cagatay So, we will have a (non-rendering) component module in myfaces-commons. Thanks all! On Wed, Oct 22, 2008 at 3:20 PM, Cagatay Civici [EMAIL PROTECTED]wrote: +1 to non rendering stuff only On Wed, Oct 22, 2008 at 2:14 AM, Hazem Saleh [EMAIL PROTECTED] wrote: OK. Let's then start empowering it ;). On Wed, Oct 22, 2008 at 2:42 AM, Grant Smith [EMAIL PROTECTED]wrote: So is the plan then to take ALL non-rendering components and listeners from ALL myfaces subprojects and dump them in here ? If that is the case, then +1. Having stuff scattered about unnecessarily because we didn't finish the job would be an unacceptable situation. I would also propose calling the module something which identifies it as containing the type of component it holds. Myfaces commons components is just too obscure. On Tue, Oct 21, 2008 at 4:08 PM, Andrew Robinson [EMAIL PROTECTED] wrote: +1 on Mike's reply On Tue, Oct 21, 2008 at 12:52 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: +1 only for components that don't render anything, like t:saveState -- Grant Smith -- 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
[jira] Created: (TRINIDAD-1281) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent()
Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent() --- Key: TRINIDAD-1281 URL: https://issues.apache.org/jira/browse/TRINIDAD-1281 Project: MyFaces Trinidad Issue Type: New Feature Components: Documentation Affects Versions: 1.2.10-core Environment: Not applicable Reporter: Prakash Udupa N Currently JSF RI does not provide any API to generate absolute or scoped id's that can be safely used in calls to UIComponent.findComponent(). This enhancement request is for providing such a utility method in Trinidad. Many frameworks that extend Trinidad could have need for such a utility method as is the case for us. Providing such method in top level framework like Trinidad helps avoid duplicate and/or incorrect implementations around. This method could go in org.apache.myfaces.trinidad.util.ComponentUtils class. I can provide a patch for this soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1281) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent()
[ https://issues.apache.org/jira/browse/TRINIDAD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1281: -- Status: Patch Available (was: Open) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent() --- Key: TRINIDAD-1281 URL: https://issues.apache.org/jira/browse/TRINIDAD-1281 Project: MyFaces Trinidad Issue Type: New Feature Components: Documentation Affects Versions: 1.2.10-core Environment: Not applicable Reporter: Prakash Udupa N Original Estimate: 2h Remaining Estimate: 2h Currently JSF RI does not provide any API to generate absolute or scoped id's that can be safely used in calls to UIComponent.findComponent(). This enhancement request is for providing such a utility method in Trinidad. Many frameworks that extend Trinidad could have need for such a utility method as is the case for us. Providing such method in top level framework like Trinidad helps avoid duplicate and/or incorrect implementations around. This method could go in org.apache.myfaces.trinidad.util.ComponentUtils class. I can provide a patch for this soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
