myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: MyFaces 2.0 J4Fry first comments
Date Fri, 03 Apr 2009 09:23:45 GMT
Ganesh schrieb:
> Hi,
> - Fine, lets go for namespace myfaces.
> - I think I have to clarify on the parameters render, execute and 
> (optional) myfaces.submit:
> render, I think we are d'accord on this, will affect the components 
> triggered for rendering during render response on the Java side and it 
> will determine the HTML elements to replace on the Javascript side (this 
> is PPR).

> execute will determine, which links or buttons action and 
> actionsListeners will be triggered. It add the buttons or links 
> name=value to the POST params on the Javascript side and influences the 
> invoke application phase on the Java side (this is neither PPR nor PPS, 
> it's a JSF specificum).
execute is more than just the actions and listeners but on the 
javascript side we do not have to bother with it. From the javascript 
perspective it is just an array of ids of existing elements which has to 
be transformend into a blank deliminated string which then has to be 
passed with a certain key (jsf.ajax.partial.execute or so) with the request!

The spec to my knowledge says that the execute ids are the ones being 
processed during execution nothing more...
Anyway it is not the biggest concern for now to me what has to happen on 
the server side.

The issue with execute and render is that certain transformations have 
to be performed upfront before being passed down.
Like values like @all or @none have to be processed (not in the last 
public spec but in the ri) or @form and @this have to be replaced!
The key has to be changed from execute to the jsf.ajax.partial.execute 

> myfaces.submit influences the way POST parameters are collected on the 
> Javascript side. Instead of merely piling up all the parameters of a 
> form it recurses through the DOM tree and adds only those branches that 
> are designated in the myfaces.submit parameter through their parent 
> element. On the Java side this reduce apply request values and update 
> model to the branches of the component tree that where submitted before 
> (this is PPS).
This is ok with me sounds reasonable lets add that one as well I will 
check the last public specs if we can do that...
We probably can keep this under the myfaces umbrella of additional 
options which have to be filtered out!

> - Where do I find the extensions package? I think this would be a great 
> place for the view params disable, loadingbar and postJSFuntion to go.
Extensions is a subproject of myfaces, lets keep all this stuff for now 
in the core codebase and then move it over in the final cleanup phase.
The important part is to push the entire rendering aspect of j4fry into 
respective listener classes which then can be registered by standard jsf 

View raw message