Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Hi,
the most important question for me is actually:
1) How much should we really mix actions with facelets rendering?
There are s many things to consider. As you already said in your specs
post: viewstate, windowid, viewscoped,
For me the most important things are actually:
1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL
$('#input').autocomplete({
source: #{action('myBean', 'myAction', params...)}
});
@Named(myBean)
@RequestScoped
public class MyBean {
@Action
// userId param with automatic converter lookup
public String myAction(String myUrlParam, User userId) {
return response;
}
}
4) Allow action rendering in in a normal lifecycle:
ui:renderAction action=#{myBrean.myAction(bean.value, 1)} /
5) Action + facelets rendering - question 1
Currently no idea how a integration should look like.
2014-04-22 18:24 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
In few word, the difficulty in this stuff is the context. If you take a
look
at the example proposed:
@Named(myBean)
@RequestScoped
public class MyBean implements Serializable {
@RequestMapping(value = /form1b.xhtml)
public String form1() {
String inputText1 = (String) FacesContext.getCurrentInstance().
getExternalContext().getRequestParameterMap().get(inputText1);
setValue(We set inputText1 manually to - + inputText1);
return /form1b.xhtml;
}
}
To call the method you need to restore the context first of the parent
bean and also there is a call to FacesContext.getCurrentInstance(),
so at that point it should be a valid FacesContext instance.
In JSF 2.2 the lifecycle has 3 methods:
//JSF 2.2: attach window
_lifecycle.attachWindow(facesContext);
// If this returns false, handle as follows:
// call Lifecycle.execute(javax.faces.context.FacesContext)
_lifecycle.execute(facesContext);
// followed by
Lifecycle.render(javax.faces.context.FacesContext).
_lifecycle.render(facesContext);
The idea is create a LifecycleWrapper that on lifecycle.execute()
implements a front controller pattern, doing the necessary steps to
get the bean from the underlying CDI container and call the method.
If no method is called, continue as usual.
The idea is not replicate all the features that an action source framework
provides, just the important ones to deal with the cases we have found
where this can be useful for JSF, or try to reutilize what's already
available in JSF. It will take some time to get it out, but I think if
we can solve the use cases proposed, the final result will be something
valuable.
regards,
Leonardo
2014-04-22 16:03 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
+1 To the idea
On 22 April 2014 15:53, Leonardo Uribe lu4...@gmail.com wrote:
Hi Thomas
Yes, the idea is do something similar. The only thing we need to find
out is how to do it in a way that fits better with JSF.
There are different people interested in this:
- Some people wants to use JSF as a template engine, because
Facelets with JSF 2 Resource Handling and JSF 2.2 Resource Library
Contracts can be an effective solution for server side templating.
- Some people want to use a JSF component library but they need to
fill some gaps, like for example create a custom component and on
the way they need to create a JSON endpoint. An mixed JSF-MVC
approach can be an effective solution.
I think the mentioned example is just half of the solution. That's
the reason why I'm gathering the use cases where this can be
useful. The plan is write a prototype and discuss it, to see how far
can we go with this.
regards,
Leonardo
2014-04-22 15:21 GMT+02:00 Thomas Andraschko
andraschko.tho...@gmail.com:
Hi Leo,
+1 for the idea.
Would it be similiar to:
https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra
?
Regards,
Thomas
2014-04-22 15:13 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
Over the time, with the new javascript libraries out there that makes
easier to make reliable code on the client side, there are more and
more people interested in an approach that can take advantage of
the good parts that JSF 2.2 already has, but without get into the JSF
lifecycle complexities. It could be good if we provide a new module
inside MyFaces Commons that allow to do things like in Spring MVC or
JAX-RS but also integrated with JSF.
For example:
- Create a JSON response from a managed bean and bind it to a
component
using javascript.
- Define
[jira] [Created] (TOBAGO-1387) Missing Sourcemap for jQuery leads to warning: Unsupported mime type
Udo Schnurpfeil created TOBAGO-1387: --- Summary: Missing Sourcemap for jQuery leads to warning: Unsupported mime type Key: TOBAGO-1387 URL: https://issues.apache.org/jira/browse/TOBAGO-1387 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.0-beta-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Logging message: Unsupported mime type of resource='org/apache/myfaces/tobago/renderkit/html/standard/standard/script/jquery-1.10.2.min.map' (because of security reasons) This occures only in production mode, when the browsers developer tool tries to load meta data for the minified jQuery JS file. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Hi
2014-04-23 11:54 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com:
TA Hi,
TA
TA the most important question for me is actually:
TA
TA 1) How much should we really mix actions with facelets rendering?
TA
TA There are s many things to consider. As you already said in your specs
TA post: viewstate, windowid, viewscoped,
TA
I think the best way to deal with facelets rendering is use the standard ajax.
I know in an action source framework people have to do the ajax stuff
by hand, which means use the template framework to calculate a fragment
of the response. That's a step back.
Instead, this is for the case when you have a page in the client and you need
to communicate with the server to get some information, but the page structure
does not change. For example, an autocomplete component or a datatable
component. In that case, you only need the data usually in json format, and
there is a javascript already in place to deal with that data and change the
state of the client.
The point is deal with the context in general. So if you send a POST from the
client, and you provide the windowid and the viewstate token, it should be
processed, and the response should update the viewstate if necessary.
That's why we need some javascript on the client to wire things up.
It could be possible a complex case, where we need a json response but
the response triggers an ajax update from the server. It can be done, with
some javascript code.
For me the most important things are actually:
1) possibility to use a normal JSF lifecycle for the first GET request
I agree with you, because in the first request you are just building the view,
no special things there.
2) allow action handling and custom response for POST actions
Yes.
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL
$('#input').autocomplete({
source: #{action('myBean', 'myAction', params...)}
});
@Named(myBean)
@RequestScoped
public class MyBean {
@Action
// userId param with automatic converter lookup
public String myAction(String myUrlParam, User userId) {
return response;
}
}
Yes, that's one good point. I have seen too. It could be good to have
an EL function that renders the endpoint url automatically. In this case,
you don't really care how the endpoind url is generated, as long as
when the javascript on the client side invokes the url you get the
pointed method executed.
You could also want to bind the url to the component itself. The case is
you are writing a composite component and the component requires
the url, so you annotate a method in the base component class to
deal with this. In the GET case you don't have the view state, so the
component state is not restored, but in the POST case you can
submit the view state (for example calling a defined javascript function)
and the code will execute an invokeOnComponent call on the server.
4) Allow action rendering in in a normal lifecycle:
ui:renderAction action=#{myBrean.myAction(bean.value, 1)} /
Could you please describe better this case? So you execute the action,
but the lifecycle goes on as usual?
5) Action + facelets rendering - question 1
Currently no idea how a integration should look like.
I still don't have clear this point, but I can imagine you can return
XML from the server and parse it on the client somehow. Obviously
we need to find out how to do it.
regards,
Leonardo Uribe
2014-04-22 18:24 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
In few word, the difficulty in this stuff is the context. If you take a
look
at the example proposed:
@Named(myBean)
@RequestScoped
public class MyBean implements Serializable {
@RequestMapping(value = /form1b.xhtml)
public String form1() {
String inputText1 = (String) FacesContext.getCurrentInstance().
getExternalContext().getRequestParameterMap().get(inputText1);
setValue(We set inputText1 manually to - + inputText1);
return /form1b.xhtml;
}
}
To call the method you need to restore the context first of the parent
bean and also there is a call to FacesContext.getCurrentInstance(),
so at that point it should be a valid FacesContext instance.
In JSF 2.2 the lifecycle has 3 methods:
//JSF 2.2: attach window
_lifecycle.attachWindow(facesContext);
// If this returns false, handle as follows:
// call
Lifecycle.execute(javax.faces.context.FacesContext)
_lifecycle.execute(facesContext);
// followed by
Lifecycle.render(javax.faces.context.FacesContext).
_lifecycle.render(facesContext);
The idea is create a LifecycleWrapper that on lifecycle.execute()
implements a front controller pattern, doing the necessary steps to
get the bean from the underlying CDI container and call the method.
If
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
LU 4) Allow action rendering in in a normal lifecycle:
LU
LUui:renderAction action=#{myBrean.myAction(
LUbean.value, 1)} /
LU
LU
LUCould you please describe better this case? So you execute the action,
LU but the lifecycle goes on as usual?
It's just a component, which renders the returned html string from the
action into the ResponseWriter.
Something like a include for the action return value.
This would be also helpful if we combine facelet rendering + actions.
In ASP.NET MVC, the action could also return a View/PartialView:
@Named(myBean)
@RequestScoped
public class MyBean {
@Action
// userId param with automatic converter lookup
public PartialView myAction(String myUrlParam, User userId) {
return new
PartialView(/META-INF/mylib/myincludes/myfile.xhtml);
}
}
It would load the xhtml, renders the xhtml and return the rendered html
string - called via ui:renderAction or via URL.
I think we could also completely rebuild the GET functionality for actions.
Maybe could just render the startRegistration.xhtml via a normal JSF
lifecycle after the action call.
@Named(myBean)
@RequestScoped
public class MyBean {
@Action(mapping = /actions/do/something)
// userId param with automatic converter lookup
public View myAction() {
return new
View(/views/registration/startRegistration.xhtml);
}
}
Just some ideas for a more complete add-on.
That would cover the view and controller. The model are actually the
beans via EL.
Don't know if it really fits JSF or if there are better concepts - but that
are almost all core features of ASP.NET MVC.
2014-04-23 13:40 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
2014-04-23 11:54 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com
:
TA Hi,
TA
TA the most important question for me is actually:
TA
TA 1) How much should we really mix actions with facelets rendering?
TA
TA There are s many things to consider. As you already said in your
specs
TA post: viewstate, windowid, viewscoped,
TA
I think the best way to deal with facelets rendering is use the standard
ajax.
I know in an action source framework people have to do the ajax stuff
by hand, which means use the template framework to calculate a fragment
of the response. That's a step back.
Instead, this is for the case when you have a page in the client and you
need
to communicate with the server to get some information, but the page
structure
does not change. For example, an autocomplete component or a datatable
component. In that case, you only need the data usually in json format, and
there is a javascript already in place to deal with that data and change
the
state of the client.
The point is deal with the context in general. So if you send a POST from
the
client, and you provide the windowid and the viewstate token, it should be
processed, and the response should update the viewstate if necessary.
That's why we need some javascript on the client to wire things up.
It could be possible a complex case, where we need a json response but
the response triggers an ajax update from the server. It can be done, with
some javascript code.
For me the most important things are actually:
1) possibility to use a normal JSF lifecycle for the first GET request
I agree with you, because in the first request you are just building the
view,
no special things there.
2) allow action handling and custom response for POST actions
Yes.
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL
$('#input').autocomplete({
source: #{action('myBean', 'myAction', params...)}
});
@Named(myBean)
@RequestScoped
public class MyBean {
@Action
// userId param with automatic converter lookup
public String myAction(String myUrlParam, User userId) {
return response;
}
}
Yes, that's one good point. I have seen too. It could be good to have
an EL function that renders the endpoint url automatically. In this case,
you don't really care how the endpoind url is generated, as long as
when the javascript on the client side invokes the url you get the
pointed method executed.
You could also want to bind the url to the component itself. The case is
you are writing a composite component and the component requires
the url, so you annotate a method in the base component class to
deal with this. In the GET case you don't have the view state, so the
component state is not restored, but in the POST case you can
submit the view state (for example calling a defined javascript function)
and the code will execute an invokeOnComponent call on the server.
4) Allow action rendering in in a normal lifecycle:
ui:renderAction action=#{myBrean.myAction(bean.value, 1)} /
Could
[jira] [Created] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
Adam Balazs created MYFACES-3886: Summary: SerializedViewCollection does not update it's _keys list when _serializedViews contains key Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Hi
2014-04-23 14:16 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com:
LU 4) Allow action rendering in in a normal lifecycle:
LU
LUui:renderAction action=#{myBrean.myAction(
LUbean.value, 1)} /
LU
LU
LUCould you please describe better this case? So you execute the action,
LU but the lifecycle goes on as usual?
TA It's just a component, which renders the returned html string from the
TA action into the ResponseWriter.
TA Something like a include for the action return value.
TA
TA
TA This would be also helpful if we combine facelet rendering + actions.
TA In ASP.NET MVC, the action could also return a View/PartialView:
TA
TA
TA @Named(myBean)
TA @RequestScoped
TA public class MyBean {
TA @Action
TA // userId param with automatic converter lookup
TA public PartialView myAction(String myUrlParam, User userId) {
TA return new
TA PartialView(/META-INF/mylib/myincludes/myfile.xhtml);
TA }
TA }
TA
TA It would load the xhtml, renders the xhtml and return the rendered html
TA string - called via ui:renderAction or via URL.
TA
So you mean use JSF as a template engine to render some html fragments.
I think it can be done.
This feature is something controversial, because it could be used wrongly.
For example, you have a page fragment and you want to update it using
this stuff and some javascript. Since you are bypassing JSF, the results
can be unexpected, because JSF is no longer in control of the view state
anymore. The right way is affect the component state (or the model state),
so when it is rendered it gets updated. The best way to do it, is with ajax,
because ajax knows about the relationship between different components.
Also, you could have situations when the ids are not correctly generated,
and at the end have duplicate ids. Again, the solution is add or remove the
component from the component tree programmatically, so JSF can have
the change to deal with this problem properly.
More than a PartialView, I think in this case JSF is used as a raw html or
xml generator. For example, the html in this case could be a formatted
message and so on.
I think it is better if we avoid the term PartialView and instead we provide
something more abstract like Response or MarkupFragment or
something like that. Something that indicates that this is not part of the
view itself, and instead is part of the client state.
I think we could also completely rebuild the GET functionality for actions.
Maybe could just render the startRegistration.xhtml via a normal JSF
lifecycle after the action call.
@Named(myBean)
@RequestScoped
public class MyBean {
@Action(mapping = /actions/do/something)
// userId param with automatic converter lookup
public View myAction() {
return new
View(/views/registration/startRegistration.xhtml);
}
}
It can be done. In fact, it works like a url rewriting. Maybe it is more
straighforward for users after all, because with f:viewAction, you can't
control the page, but with this, you can add some logic before the
final page is processed, like for example a conditional and so on.
Just some ideas for a more complete add-on.
That would cover the view and controller. The model are actually the
beans via EL.
Don't know if it really fits JSF or if there are better concepts - but that
are almost all core features of ASP.NET MVC.
I think what we are doing here instead is take the best we found from the
things we know that works. The challenge is integrate in a coherent way.
For example, JSF as a component oriented framework has the concept
of clientIds associated with components. This is very helpful when you
move code from one place to another, because the generated ids on
the client side are updated properly. In an action oriented framework, that's
a complete mess. The idea is preserve the JSF abstraction, that means
components that can be assembled in a hierarchical way, and that also
means this tree has a similar structure on the client.
We can find workarounds. For example, bind the html generation to
a component, so we say ... generate an html fragment, but keep in mind
that chunk will be used in this component or a component with this
client id ... So, the fragment is encapsulated in a jsf component that
implements NamingContainer and generates the specified clientId.
That could work. But I suppose it should be MyFaces Core implementation
specific, because we need to indicate to facelets the way how the ids
should be generated.
regards,
Leonardo Uribe
2014-04-23 13:40 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
2014-04-23 11:54 GMT+02:00 Thomas Andraschko
andraschko.tho...@gmail.com:
TA Hi,
TA
TA the most important question for me is actually:
TA
TA 1) How much should we really mix actions with facelets rendering?
TA
TA There are s many things to consider. As you already said in your
specs
TA post:
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978203#comment-13978203 ] Leonardo Uribe commented on MYFACES-3886: - In your case this web config para is useful: org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION See the documentation at: http://myfaces.apache.org/core22/myfaces-impl/webconfig.html By default this is set to 0, but if you have more than one window/tab/dialog in your application, you should increase the number, so the views are not discarded. It should work, because the algorithm was designed to keep track of upcoming POST request and keep them in sequence. Let us know if the param works for you to close this issue, or review it further. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978238#comment-13978238 ] Adam Balazs commented on MYFACES-3886: -- Hi Leonardo, I've already set this context param to 2. These are a related context params i have set: context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value10/param-value /context-param context-param param-nameorg.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION/param-name param-value2/param-value /context-param context-param param-nameorg.apache.myfaces.FLASH_SCOPE_DISABLED/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION/param-name param-valuetrue/param-value /context-param My original issue(not this) has been solved by setting the numbder sequential views to 2 (this way the dialog framework won't discard my original view). But if I open this dialog frequently (which will generete a new view every time), the mentioned issue still exists. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978249#comment-13978249 ] Leonardo Uribe commented on MYFACES-3886: - Well, if primefaces does not assign a client window id to the dialog, there is no way that MyFaces can chain the request as a conversation or in other words, maintain the precedence tree. The related algorithm is here: http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/viewstate/SerializedViewCollection.java The solution is make an even more clever choice of which view should be discarded, but I don't have any idea how to do it. If all pages has a windowId, the ones without clientId should be discarded first. The easy way is assign a windowId to the dialog, after all, that's the expected way to do it. The thing is that algorithm should take care of the size of the structure, because that is stored into session. You should ask to primefaces guys for this. Or you can propose a patch and try to change the algorithm. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978284#comment-13978284 ] Thomas Andraschko commented on MYFACES-3886: We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978284#comment-13978284 ] Thomas Andraschko edited comment on MYFACES-3886 at 4/23/14 3:10 PM: - From PrimeFaces perspective: We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. was (Author: tandraschko): We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TOBAGO-1388) Wandering popup
Bernhard Stadler created TOBAGO-1388:
Summary: Wandering popup
Key: TOBAGO-1388
URL: https://issues.apache.org/jira/browse/TOBAGO-1388
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 2.0.0-beta-1
Environment: Custom Theme
Reporter: Bernhard Stadler
I have a tc:page containing a tc:popup with a tc:sheet inside. For the sheet,
paging is enabled. I'll attach an example.
Every time the page is changed, the popup changes its position for some amount.
We have a custom theme and I was able to isolate the following definitions in
our tobago.css file which lay open the problem:
{code}
.tobago-page {
border: 1px solid #EE;
width: 90%;
height: 99%;
// ...
}
{code}
Each of these lines alone causes some amount of popup movement. Removing all of
them makes the problem disappear.
I also was able to isolate the JavaScript code where the actual repositioning
happens:
tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-utils.js
Tobago.Utils.keepElementInVisibleArea line 98f (SVN trunk):
{code}
/**
* fix position, when the element it is outside of the current page
* @param elements is an jQuery Array of elements to be fixed.
*/
Tobago.Utils.keepElementInVisibleArea = function(elements) {
elements.each(function() {
var element = jQuery(this);
var page = jQuery(.tobago-page-content:first);
var left = element.offset().left;
var top = element.offset().top;
// fix menu position, when it is outside of the current page
left = Math.max(0, Math.min(left, page.outerWidth() -
element.outerWidth()));
top = Math.max(0, Math.min(top, page.outerHeight() -
element.outerHeight()));
element.css('left', left);
element.css('top', top);
});
};
{code}
The left and top variables are not changed by the max/min assignment, but
because of (both!) the border and the changed width of the tobago-page class,
element.offset().left and element.offset().top seem to return a different value
than actually needed. Even the following code causes the same behavior:
{code}
Tobago.Utils.keepElementInVisibleArea = function(elements) {
elements.each(function() {
var element = jQuery(this);
element.css('left', element.offset().left);
element.css('top', element.offset().top);
});
};
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978305#comment-13978305 ] Leonardo Uribe commented on MYFACES-3886: - Ok, now I get the problem. In JSF 2.2 we added some code to reuse the key on ajax. See MYFACES-3804. But the new logic does not ensure the key is added at last of the precedence list each time it is reused. It is a bug. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978313#comment-13978313
]
Adam Balazs commented on MYFACES-3886:
--
I think that is the expected behavior from PF to assign new windowID to every
opened dialog.
As a fix, I suggest to modify the SerializedViewCollection.java class at the
line 87 as the followings:
Replace this:
if (_serializedViews.containsKey(key))
{
// Update the state, the viewScopeId does not change.
_serializedViews.put(key, state);
return;
}
By this:
if (_serializedViews.containsKey(key))
{
// Update the state, the viewScopeId does not change.
_serializedViews.put(key, state);
_keys.remove(key);
_keys.add(key);
return;
}
This way the view will be at the end of the list, and the _keys will hold the
views in 'touching' order. So the _keys[0] will be the oldest view which has
not been modified.
Patch attached.
SerializedViewCollection does not update it's _keys list when
_serializedViews contains key
---
Key: MYFACES-3886
URL: https://issues.apache.org/jira/browse/MYFACES-3886
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.2
Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs
Attachments: SerializedViewCollection.java.patch
When I use DialogFramework (of PrimeFaces), it's adds a new view to the
session every time. The problem is that when I post an AJAX request to the
original view, the _keys list is not updated, only the view get updated in
the _serializedViews map.
After I reach the limit defined with the
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the
first element in the _keys list (which is the container view) - assuming that
this is the oldest view in the session - and remove the corresponding view
from the _serializedViews map by the key. But clearly it is not, as I already
posted some AJAX requests to it.
I think the optimal behavior would be the following: when a view gets an ajax
request the code should remove the the key from the _keys list and than add
it as a last element.
The related class is
org.apache.myfaces.application.viewstate.SerializedViewCollection at the if
condition started at line 87.
My question is if it is an intended behavior or if it's a bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Balazs updated MYFACES-3886: - Status: Patch Available (was: Open) SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs Attachments: SerializedViewCollection.java.patch When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Balazs updated MYFACES-3886: - Status: Open (was: Patch Available) SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Balazs updated MYFACES-3886: - Status: Patch Available (was: Open) SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-3887) UIDebug is alwas rendered=true (no ValueExpression evaluation)
Martin Kočí created MYFACES-3887:
Summary: UIDebug is alwas rendered=true (no ValueExpression
evaluation)
Key: MYFACES-3887
URL: https://issues.apache.org/jira/browse/MYFACES-3887
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: myfaces core trunk
Reporter: Martin Kočí
Priority: Minor
ui:debug rendered=#{facesContext.application.projectStage eq 'Development'}/
does nothing : in UIDebug constructor is now hardcoded setRendered(true) and
therefore takes local value precedence over ValueExpression.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MYFACES-3887) UIDebug is alwas rendered=true (no ValueExpression evaluation)
[
https://issues.apache.org/jira/browse/MYFACES-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kočí updated MYFACES-3887:
-
Status: Patch Available (was: Open)
UIDebug is alwas rendered=true (no ValueExpression evaluation)
--
Key: MYFACES-3887
URL: https://issues.apache.org/jira/browse/MYFACES-3887
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: myfaces core trunk
Reporter: Martin Kočí
Priority: Minor
Attachments: MYFACES-3887.patch
ui:debug rendered=#{facesContext.application.projectStage eq
'Development'}/
does nothing : in UIDebug constructor is now hardcoded setRendered(true) and
therefore takes local value precedence over ValueExpression.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
Paresh Kumar Acharya created TRINIDAD-2469: -- Summary: trinidad date picker selects previous day when using lightweight dialogs Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
