[jira] Commented: (MYFACES-2259) Implement Partial State Saving feature
[ https://issues.apache.org/jira/browse/MYFACES-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724725#action_12724725 ] Leonardo Uribe commented on MYFACES-2259: - Committed implementation of StateHelper on all components including velocity template + junit tests. Pending facelets code! > Implement Partial State Saving feature > -- > > Key: MYFACES-2259 > URL: https://issues.apache.org/jira/browse/MYFACES-2259 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Leonardo Uribe > > Implement use of getStateHelper and partial state saving on all components > and the required code on facelets (StateManagerStrategy and invoke of > markInitialState on related ComponentTagHandler). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Caching the result of an EL expression evaluation with in a life cycle
Yes I absolutely agree, it has to be configurable in some way. It just seems
like such a common issue that I was hoping there was a general solution.
The ELResolver route will certainly work, though as you pointed out it will
have to be some sort of annotation which will look and feel "hacky", but I
think it would still be better then constantly writing "micro" caches
everywhere.
Thanks
-Sam
Manfred Geiler-2 wrote:
>
> A standard EL expression evaluator cannot and MUST never cache results.
> Imagine the following expression:
> #{someBean.nextCounterValue}>
> The app developer would not be very happy if EL caches that result, right?
>
> So caching can only be a matter for the model.
> OR: you write your own custom ELResolver that somehow "knows" which
> values to cache and which it should not cache. Perhaps by inspecting
> the annotations of your getters? I could imagine a custom @Cacheable
> annotation for that purpose.
>
> However, there is no magic config param. Sorry.
>
> --Manfred
>
>
>
> On Fri, Jun 26, 2009 at 03:36, Sam Witty wrote:
>>
>> If you have the following code:
>>
>> #{someBean.user.firstName}>
>> #{someBean.user.lastName}>
>> #{someBean.user.age}">
>>
>> and if SomeBean.user() is a call to the db then every one of the above
>> expressions will cause a trip to the db. Of course to get around this one
>> simply has to cache the value of user from the db (the first time) and
>> then
>> return the cached value instead of going to the db again.
>>
>> This is all well and good... however, I find myself writing a lot of this
>> type of caching code in various places. It would seem that a much elegant
>> solution would be to have the EL expression evaluator cache the result of
>> an
>> expression within a life cycle avoiding the need for every JSF developer
>> to
>> sprinkle caching code all over the place.
>>
>> Then again there maybe something out there that does this already
>> (magical
>> config param?) I just could not find anything.
>>
>> Thanks
>> -Sam
>> --
>> View this message in context:
>> http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
>> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24223523.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Reopened: (TRINIDAD-1515) Browser back button does not work
[ https://issues.apache.org/jira/browse/TRINIDAD-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-1515: --- > Browser back button does not work > -- > > Key: TRINIDAD-1515 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1515 > Project: MyFaces Trinidad > Issue Type: Wish > Components: Components >Affects Versions: 1.2.12-core > Environment: Trinidad 1.2.11, jsf ri 1.2.12, tomahawk 1.2.12, IE7 >Reporter: Dave >Priority: Minor > > When we use jsf ri and tomahawk, our jsf app works well for browser back > button. But after we use Trinidad, browser back button does not work. > Consider the following senario: > > 1. show a table of employees (backing bean data is a list of employees) > 2. click an employee A and show the employee,(backing bean data is now > changed to the employee) > 3. click browser back button > 4. click an employee B. Employee B will not be shown because the backing > data has been changed to employee A in stop 2. > > The same page is used and is used to keep backing bean data. > I looked the generated HTML viewState values in the steps above. They are > the same. That means that only the same view(stored view tree in server side) > is used. For jsf/tomahawk, I believe different view trees are used for the > senario above and thus back button works. > > Back button is often used by users. > Trinidad should add an option: save different view state for each request or > each differeant page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2260) Dom replacement code in javax.faces.ViewRoot und javax.faces.ViewBody is incorrect
[ https://issues.apache.org/jira/browse/MYFACES-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2260. -- Resolution: Fixed resolved with the last commit! the head section is a different issue, I am not sure if this can be covered at all! > Dom replacement code in javax.faces.ViewRoot und javax.faces.ViewBody is > incorrect > -- > > Key: MYFACES-2260 > URL: https://issues.apache.org/jira/browse/MYFACES-2260 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 > Environment: javascript >Reporter: Werner Punz > > The problem here is that the old code with document.documentElement.innerHtml > respectively > the replaceElement does not work out neither on head nor on body. > This issue will receive a fixup immediately! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2260) Dom replacement code in javax.faces.ViewRoot und javax.faces.ViewBody is incorrect
Dom replacement code in javax.faces.ViewRoot und javax.faces.ViewBody is incorrect -- Key: MYFACES-2260 URL: https://issues.apache.org/jira/browse/MYFACES-2260 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Environment: javascript Reporter: Werner Punz The problem here is that the old code with document.documentElement.innerHtml respectively the replaceElement does not work out neither on head nor on body. This issue will receive a fixup immediately! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Caching the result of an EL expression evaluation with in a lifecycle
Use JPA to get the data. You'll need a service and an entity object.
Then your backing bean can use the service layer to retrieve the
entire object.
This approach handles caching for you and is much more scalable
-Alan via iPhone
On Jun 26, 2009, at 5:56 AM, "Jeremy Wilson"
wrote:
--Original Message--
From: Sam Witty
To: dev@myfaces.apache.org
ReplyTo: MyFaces Development
Sent: Jun 25, 2009 9:36 PM
Subject: Caching the result of an EL expression evaluation with in a
lifecycle
If you have the following code:
#{someBean.user.firstName}>
#{someBean.user.lastName}>
#{someBean.user.age}">
and if SomeBean.user() is a call to the db then every one of the above
expressions will cause a trip to the db. Of course to get around
this one
simply has to cache the value of user from the db (the first time)
and then
return the cached value instead of going to the db again.
This is all well and good... however, I find myself writing a lot of
this
type of caching code in various places. It would seem that a much
elegant
solution would be to have the EL expression evaluator cache the
result of an
expression within a life cycle avoiding the need for every JSF
developer to
sprinkle caching code all over the place.
Then again there maybe something out there that does this already
(magical
config param?) I just could not find anything.
Thanks
-Sam
--
View this message in context:
http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Jeremy Wilson
CTO
ESRG Technologies Group
Office 757-965-5963
Cell 814-241-4500
Re: Myfaces 2.0 javascript javax.faces.viewRoot response need some feedback from others
Werner Punz schrieb:
Werner Punz schrieb:
Curtiss Howard schrieb:
Forgive me if I'm missing some important details, but why even use
innerHTML in the first place? It should be possible to parse the
incoming text into a DOM node (there's some JS function for it, I
can't remember which), then import that node as a sibling of the
element (for example) and delete the first element.
Wouldn't that work?
It was one of my testcases to do that since I shun innerHTML (we dont
do it anyway normally)
Does not work either on safari...
You can do dom manipulation on the contents of the body element but
you cannot delete the body element in most browsers under xhtml
conditions as it seems!
Ah ok mea culpa, again a message.
What does work is document createElement("body") and then set that one
one way or the other.
What is problematic as it seems is to use the range functionality to
achieve the same by a contextual fragment which should replace the body,
this does not work in some cases, but would be the cleaner solution for
non ie cases!
(having the browser parse the entire tag including its attributes)
I will do some final testing regarding this, but as it seems, I have to
parse the body tag attributes from the string coming from the server and
have it assigned programatically in any case.
It was probably a little bit to early to send first mail regarding this
problem ;-)
Anyway one way or the other I want to have embedded body tag attributes
assigned if they come from the server!
Btw. the last time which has been months ago mojarra had in this part
absolutely broken code. They used regular expressions which failed in
many cases (like tags embedded into comments etc...)
and they simply ignored any tag attributes, they just created a body tag
and then pushed the content in via innerHTML also ignoring embedded
scripts (which they seem to ignore entirely)
not sure if they have changed that! Hazem pointed them I think towards
not doing anything about embedded scripts I am not sure if they have
fixed it already. This might become a problem for ajax libraries unless
they add the script parsing needed via listeners!
ok just in case if someone reads this.
head element does not work out on some browsers, it probably is better
to skip this entirely,
body replacement this works out somewhat differently we cannot
use our replacement code directly on the body, this does not work in any
browser (firefox drops the body element directly while others fail with
an error in this case), instead we have to work around that by
a) creating a body element via document.createElement
b) adding a placeHolder div as dummy child
c) assign the defakto empty body via replaceElement
d) then use our replacement code as is on the dummy child and the new
body content
e) then assign all pending attributes from the old body to our new one
to preserver styleClasses and styles!
I have this one now working via a new parsing code which also parses the
attributes from the tag which has to be parsed and will commit it the
next days!
I am not sure if we have to deal in similar manners with the special
cases of head and body being sent as
own entities in javax.faces.head and javax.faces.body,I have to what
data we get in those cases from the server, but I assume the head or
body tags...
Werner
Re: Caching the result of an EL expression evaluation with in a lifecycle
--Original Message--
From: Sam Witty
To: dev@myfaces.apache.org
ReplyTo: MyFaces Development
Sent: Jun 25, 2009 9:36 PM
Subject: Caching the result of an EL expression evaluation with in a lifecycle
If you have the following code:
#{someBean.user.firstName}>
#{someBean.user.lastName}>
#{someBean.user.age}">
and if SomeBean.user() is a call to the db then every one of the above
expressions will cause a trip to the db. Of course to get around this one
simply has to cache the value of user from the db (the first time) and then
return the cached value instead of going to the db again.
This is all well and good... however, I find myself writing a lot of this
type of caching code in various places. It would seem that a much elegant
solution would be to have the EL expression evaluator cache the result of an
expression within a life cycle avoiding the need for every JSF developer to
sprinkle caching code all over the place.
Then again there maybe something out there that does this already (magical
config param?) I just could not find anything.
Thanks
-Sam
--
View this message in context:
http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Jeremy Wilson
CTO
ESRG Technologies Group
Office 757-965-5963
Cell 814-241-4500
