> The Trinidad request queue has about 1000 lines of code, 80% of it(the > entire iframe part, multi part form posts, the abstractions to hide
regarding iframe: that is needed when you do an "ppr for a form that contains an upload". XHR does not support that. So, you are saying the spec does only support XHR for ajax form submits ? That would be sweet... But that would fit the current ignorance of Java EE land to generally (out of the box) not support (out of the box) the upload case at all (meaning, there is no standard API for processing uploads, every framework has its own). So, wouldn't that also mean there is no chance in doing "PPR form submit" for upload cases, in a standard way? Wouldn't that cause forks, different APIs etc for different toolkits (=> Tomahawk, Tobago, Trinidad, you name it) Please tell me, that I am wrong :-) -Matthias > different transport mechanisms, etc...) is not needed for the jsf2 spec! To > the worse some parts really need a serious cleanup which I do not dare to > touch. Other parts I already have cleaned up somewhat, like the entire > logging. > And probably due to running over some abstraction layers it might behave > differently to the ri in some vital areas which then need to be nailed down > and fixed (one area definitely being the alerts in the codebase > and some internal error messages)! > > I have started to pick up the work on I had done before on a simple > transport layer (basically just a queue and a hook into xmlhttprequest) > which currently has about 130 locs and in the end will have about 200 which > is trimmed down to the absolute core of what we seem to need for the current > state of the spec! > > What I would propose is following, once I am done with it I will commit it > as well, and for now I will make the transports switchable, > people in the long run should decide which transport we will use. > I am not too eager to drag all the trinidad code around,especially > if Trinidad wants to become jsf2 compatible anyway it has to reroute its own > communication layer for the ppr stuff over the official apis or provide its > own anyway for the things which cannot be covered by the current spec. It > does not make too much sense to fix the Trinidad codebase down to the level > to become fully compatible to the ri in every detail! Too much work and I > would probably break Trinidad that way anyway! > > The transport definitely will be pluggable, this is javascript afterall, > and I do not have any intention to hardwire anything since it is rather easy > in javascript to make things very dynamic! > > Comments anyone? > > > Werner > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
