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).
Yes...
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
parameter!
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
mechanisms!
