Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Hello everyone regarding the MyFaces 2.0 xmlhttprequest layer!
As I posted earlier, I wanted to recycle the Trinidad code because it is 
tested!

Ok i have the post sufficiently running, and also the event callbacks, 
as far as  I can gather it from the specs and the RI.

But there is an issue, currently I have a small compatibility layer
which basically hides the namespaced Trinidad xmlhttprequest code away 
to make that compatibility, for now this is sufficient, but.
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 
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

Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Ups please ignore the mail, first of all it was an older draft,
secondly the second part is not valid anymore, the ri has clear 
mechanisms on eval by having an eval command in the xml!...
I accidentally sent that and cannot revoke it anymore.

Werner


Werner Punz schrieb:
> Matthias Wessendorf schrieb:
>>> 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).
>>
> I would not be so harsh all this currently is a huge work in progress as
> I could see from the differences between the spec and the RI...
> 
> Well there are two things, currently, since I am not in the EG I have
> only info from what I can gather from the released pdfs and javadocs
> and from the RI. The RI always seems to be ahead from the released PDFs
> so I usually take it as my core reference.
> 
> a) I am aware of the upload issue and that you can only do it via
> iframes if you want to stay on a clean html side. I will give a short
> info on what I could gather from the spec and RI:
> 
> Sending a form is, that you have to gather the viewstate and you have to
> send it as encoded String!
> also you have to add various parameters and you can define a map of
> passthrough values which have to be encoded similarily on the client side!
> 
> The request must be queued and it must be send asynchronously.
> It is not clearly stated that you have to use xmlhttprequest for
> sending, the RI however currently uses xmlhttprequest only!
> 
> Not sure if you can say an iframe post is an asynchronous post, but I
> assume so...
> 
> 
>> 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
> 
> At the current state of the RI is not, and I am not sure if the spec has
> this loophole open, but as it is this needs to be clearly specified one
> way or the other!
> Otherwise we will have the next mess on our hands!
> 
> The spec is rather vague on all this and the issue is that the RI as
> core reference at the last public release (which funnily is not the same
> as the last public released specs, the RI clearly is from mid december
> while the pdfs are from november), does not cover it yet, either means
> they are not aware of those issues or they simply do not have tackled it.
> 
> There is another things, maybe I missed here something, but the response
> data format, is an xml crud format with explicitely stated create update
> delete comments, which is ok, but it does not seem to enforce the split
> between raw html and script code.
> The problem with this is, that browsers must!!!! evaluate the
> javascripts in ppr cases after all the dom updates via innerHTML are
> done. The problem is, modern browsers do not do an auto execution of
> embedded scripts in xhr cases (the last one doing this was ie5 afair, it
> was omitted due to security issues)!
> 
> The workflow usually is .... xhr state finished -> push in the new html
> code via innerHTML, eval all the scripts after the innerHTML is done so
> that they again can work on a stable dom tree.
> 
> Trinidad does this splitting via the responseWriter to get a good
> performance. As I see it for now, the dataformat leaves this hole wide
> open. But as I said this information stems mostly from looking at the
> dataformat itself, I might have missed some info here (I have yet to
> look at the RI how they do it)
> 
> 
> 

Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Matthias Wessendorf schrieb:
>> 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).
> 
I would not be so harsh all this currently is a huge work in progress as
I could see from the differences between the spec and the RI...

Well there are two things, currently, since I am not in the EG I have
only info from what I can gather from the released pdfs and javadocs
and from the RI. The RI always seems to be ahead from the released PDFs
so I usually take it as my core reference.

a) I am aware of the upload issue and that you can only do it via
iframes if you want to stay on a clean html side. I will give a short
info on what I could gather from the spec and RI:

Sending a form is, that you have to gather the viewstate and you have to
send it as encoded String!
also you have to add various parameters and you can define a map of
passthrough values which have to be encoded similarily on the client side!

The request must be queued and it must be send asynchronously.
It is not clearly stated that you have to use xmlhttprequest for
sending, the RI however currently uses xmlhttprequest only!

Not sure if you can say an iframe post is an asynchronous post, but I
assume so...


> 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

At the current state of the RI is not, and I am not sure if the spec has
this loophole open, but as it is this needs to be clearly specified one
way or the other!
Otherwise we will have the next mess on our hands!

The spec is rather vague on all this and the issue is that the RI as
core reference at the last public release (which funnily is not the same
as the last public released specs, the RI clearly is from mid december
while the pdfs are from november), does not cover it yet, either means
they are not aware of those issues or they simply do not have tackled it.

There is another things, maybe I missed here something, but the response
data format, is an xml crud format with explicitely stated create update
delete comments, which is ok, but it does not seem to enforce the split
between raw html and script code.
The problem with this is, that browsers must!!!! evaluate the
javascripts in ppr cases after all the dom updates via innerHTML are
done. The problem is, modern browsers do not do an auto execution of
embedded scripts in xhr cases (the last one doing this was ie5 afair, it
was omitted due to security issues)!

The workflow usually is .... xhr state finished -> push in the new html
code via innerHTML, eval all the scripts after the innerHTML is done so
that they again can work on a stable dom tree.

Trinidad does this splitting via the responseWriter to get a good
performance. As I see it for now, the dataformat leaves this hole wide
open. But as I said this information stems mostly from looking at the
dataformat itself, I might have missed some info here (I have yet to
look at the RI how they do it)

Re: Myfaces 2.0 and xhr transport

[Matthias Wessendorf <ma...@apache.org>]

On Mon, Feb 9, 2009 at 1:04 PM, Werner Punz <we...@gmail.com> wrote:
> Matthias Wessendorf schrieb:
>
>> Also(on a side note) with JS you even can't reset the "value" of an
>> <input type:file ... > HTML element. Something like:
>> inputFileHTMLElement.value = null;
>>
> You can replace the entire element though via dom manipulation, which
> basically is a full blown reset in its outcome...
yes, that's what you usually do

> Anyway this becomes entirely off topic :-)

:-)
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Matthias Wessendorf schrieb:

> Also(on a side note) with JS you even can't reset the "value" of an
> <input type:file ... > HTML element. Something like:
> inputFileHTMLElement.value = null;
> 
You can replace the entire element though via dom manipulation, which 
basically is a full blown reset in its outcome...
Anyway this becomes entirely off topic :-)

Re: Myfaces 2.0 and xhr transport

[Matthias Wessendorf <ma...@apache.org>]

On Mon, Feb 9, 2009 at 11:10 AM, Simon Kitching <sk...@apache.org> wrote:
> Matthias Wessendorf schrieb:
>> On Mon, Feb 9, 2009 at 10:21 AM, Werner Punz <we...@gmail.com> wrote:
>>> Matthias Wessendorf schrieb:
>>>>> 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).
>>>>
>>> I would not be so harsh all this currently is a huge work in progress as
>>> I could see from the differences between the spec and the RI...
>>
>> sure, here we should just implement that. I don't think that the TCK
>> does check for "Iframe communication channel presen" :-)
>>
>>> Since I am not in the EG I have
>>> only info from what I can gather from the released pdfs and javadocs
>>> and from the RI. The RI always seems to be ahead from the released PDFs
>>> so I usually take it as my core reference.
>>>
>>> a) I am aware of the upload issue and that you can only do it via
>>> iframes if you want to stay on a clean html side. I will give a short
>>> info on what I could gather from the spec and RI:
>>>
>>> Sending a form is, that you have to gather the viewstate and you have to
>>> send it as encoded String!
>>> also you have to add various parameters and you can define a map of
>>> passthrough values which have to be encoded similarily on the client side!
>>>
>>> The request must be queued and it must be send asynchronously.
>>> It is not clearly stated that you have to use xmlhttprequest for
>>> sending, the RI however currently uses xmlhttprequest only!
>>
>> which would cause serious bugs when one uses uploads :-)
>>
>>> Not sure if you can say an iframe post is an asynchronous post, but I
>>> assume so...
>>>
>>>
>>>> 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
>>> At the current state of the RI is not, and I am not sure if the spec has
>>> this loophole open, but as it is this needs to be clearly specified one
>>> way or the other!
>>> Otherwise we will have the next mess on our hands!
>>> My per
>>>
>>> The spec is rather vague on all this and the issue is that the RI as
>>> core reference at the last public release (which funnily is not the same
>>> as the last public released specs, the RI clearly is from mid december
>>> while the pdfs are from november), does not cover it yet, either means
>>> they are not aware of those issues or they simply do not have tackled it.
>>
>> IMO it is not the fault of JSF, that there is this unhappy situation w/ uploads,
>> Java EE, or Servlet 3, should address that. If upload was supported as
>> first class
>> citizens in the JavaEE *umbrella* land, JSF spec would be more aware of it.
>>
>> Well, let's see what the final spec will contain.
>>
>> FYI. I pinged Andy Schwartz on this, how is Oracle's JSF spec dude.
>
> Just curious, but I don't see why you say this is a JEE/Servlet issue.


Well.. there is NO unified API for doing file uploads. Every framework
like Struts, Wicket, or any JSF extension (Tomahawk, Trinidad) has do
build a more natural API for doing file uploads. In vanilla Servlet land all
you do is reading bytes. I think (perhaps it is only me) there should be
a better support for that on the Servlet layer.


>
> As I understand it, XmlHttpRequest works by manually iterating over the
> html DOM to find the input widgets, fetch their name+value, and then add
> the name+value to the XmlHttpRequest.
>
> But it is simply not possible to "fetch the value" (file contents) of a
> file upload widget from javascript; therefore it is never possible to
> send the contents of a file within an XmlHttpRequest.

nobody said that this is possible. And yes you are right.

Also(on a side note) with JS you even can't reset the "value" of an
<input type:file ... > HTML element. Something like:
inputFileHTMLElement.value = null;

does not work as well.

>
> I would guess that Mojarra just ignores any file-upload widgets when
> building an XmlHttpRequest, ie partial-submit works fine except that any
> specified file is ignored. That doesn't seem to unreasonable to me
> considering the html limitations and that file-upload is fairly rare;
> just *don't* use them with partial submit. Is the extra complication of
> a whole iframe-based solution *just* to handle this case really worth it?

I think yes. A good framework should just help the user (-> page
developer) here.

-Matthias

>
> Regards,
> Simon
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Simon Kitching schrieb:

> I would guess that Mojarra just ignores any file-upload widgets when
> building an XmlHttpRequest, ie partial-submit works fine except that any
> specified file is ignored. That doesn't seem to unreasonable to me
> considering the html limitations and that file-upload is fairly rare;
> just *don't* use them with partial submit. Is the extra complication of
> a whole iframe-based solution *just* to handle this case really worth it?
> 

Well besides the fact that HTML in its current state is
entirely broken for user interfaces,
one component which is really broken is the file upload. I prefer to 
have that stuff done by flash or by applets, but personal opinion and 
preferences aside. The problem I see is simply that we are a base 
framework, can we simply ignore the broken fileupload or not for ppr?
Although I shy the extra mile of work and I agree mostly, I cannot say I 
would ignore it.

Well besides the fileuploads there are other uses for iframes, for 
instance it is one technique to do comet stuff (that and long running 
xhr requests) but that for now is probably out of the scope of the spec!

Re: Myfaces 2.0 and xhr transport

[Simon Kitching <sk...@apache.org>]

Matthias Wessendorf schrieb:
> On Mon, Feb 9, 2009 at 10:21 AM, Werner Punz <we...@gmail.com> wrote:
>> Matthias Wessendorf schrieb:
>>>> 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).
>>>
>> I would not be so harsh all this currently is a huge work in progress as
>> I could see from the differences between the spec and the RI...
> 
> sure, here we should just implement that. I don't think that the TCK
> does check for "Iframe communication channel presen" :-)
> 
>> Since I am not in the EG I have
>> only info from what I can gather from the released pdfs and javadocs
>> and from the RI. The RI always seems to be ahead from the released PDFs
>> so I usually take it as my core reference.
>>
>> a) I am aware of the upload issue and that you can only do it via
>> iframes if you want to stay on a clean html side. I will give a short
>> info on what I could gather from the spec and RI:
>>
>> Sending a form is, that you have to gather the viewstate and you have to
>> send it as encoded String!
>> also you have to add various parameters and you can define a map of
>> passthrough values which have to be encoded similarily on the client side!
>>
>> The request must be queued and it must be send asynchronously.
>> It is not clearly stated that you have to use xmlhttprequest for
>> sending, the RI however currently uses xmlhttprequest only!
> 
> which would cause serious bugs when one uses uploads :-)
> 
>> Not sure if you can say an iframe post is an asynchronous post, but I
>> assume so...
>>
>>
>>> 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
>> At the current state of the RI is not, and I am not sure if the spec has
>> this loophole open, but as it is this needs to be clearly specified one
>> way or the other!
>> Otherwise we will have the next mess on our hands!
>> My per
>>
>> The spec is rather vague on all this and the issue is that the RI as
>> core reference at the last public release (which funnily is not the same
>> as the last public released specs, the RI clearly is from mid december
>> while the pdfs are from november), does not cover it yet, either means
>> they are not aware of those issues or they simply do not have tackled it.
> 
> IMO it is not the fault of JSF, that there is this unhappy situation w/ uploads,
> Java EE, or Servlet 3, should address that. If upload was supported as
> first class
> citizens in the JavaEE *umbrella* land, JSF spec would be more aware of it.
> 
> Well, let's see what the final spec will contain.
> 
> FYI. I pinged Andy Schwartz on this, how is Oracle's JSF spec dude.

Just curious, but I don't see why you say this is a JEE/Servlet issue.

As I understand it, XmlHttpRequest works by manually iterating over the
html DOM to find the input widgets, fetch their name+value, and then add
the name+value to the XmlHttpRequest.

But it is simply not possible to "fetch the value" (file contents) of a
file upload widget from javascript; therefore it is never possible to
send the contents of a file within an XmlHttpRequest.

I would guess that Mojarra just ignores any file-upload widgets when
building an XmlHttpRequest, ie partial-submit works fine except that any
specified file is ignored. That doesn't seem to unreasonable to me
considering the html limitations and that file-upload is fairly rare;
just *don't* use them with partial submit. Is the extra complication of
a whole iframe-based solution *just* to handle this case really worth it?

Regards,
Simon

Re: Myfaces 2.0 and xhr transport

[Matthias Wessendorf <ma...@apache.org>]

On Mon, Feb 9, 2009 at 10:21 AM, Werner Punz <we...@gmail.com> wrote:
> Matthias Wessendorf schrieb:
>>>
>>> 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).
>>
> I would not be so harsh all this currently is a huge work in progress as
> I could see from the differences between the spec and the RI...

sure, here we should just implement that. I don't think that the TCK
does check for "Iframe communication channel presen" :-)

>
> Since I am not in the EG I have
> only info from what I can gather from the released pdfs and javadocs
> and from the RI. The RI always seems to be ahead from the released PDFs
> so I usually take it as my core reference.
>
> a) I am aware of the upload issue and that you can only do it via
> iframes if you want to stay on a clean html side. I will give a short
> info on what I could gather from the spec and RI:
>
> Sending a form is, that you have to gather the viewstate and you have to
> send it as encoded String!
> also you have to add various parameters and you can define a map of
> passthrough values which have to be encoded similarily on the client side!
>
> The request must be queued and it must be send asynchronously.
> It is not clearly stated that you have to use xmlhttprequest for
> sending, the RI however currently uses xmlhttprequest only!

which would cause serious bugs when one uses uploads :-)

>
> Not sure if you can say an iframe post is an asynchronous post, but I
> assume so...
>
>
>> 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
>
> At the current state of the RI is not, and I am not sure if the spec has
> this loophole open, but as it is this needs to be clearly specified one
> way or the other!
> Otherwise we will have the next mess on our hands!
> My per
>
> The spec is rather vague on all this and the issue is that the RI as
> core reference at the last public release (which funnily is not the same
> as the last public released specs, the RI clearly is from mid december
> while the pdfs are from november), does not cover it yet, either means
> they are not aware of those issues or they simply do not have tackled it.

IMO it is not the fault of JSF, that there is this unhappy situation w/ uploads,
Java EE, or Servlet 3, should address that. If upload was supported as
first class
citizens in the JavaEE *umbrella* land, JSF spec would be more aware of it.

Well, let's see what the final spec will contain.

FYI. I pinged Andy Schwartz on this, how is Oracle's JSF spec dude.

-Matthias

>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: Myfaces 2.0 and xhr transport

[Werner Punz <we...@gmail.com>]

Matthias Wessendorf schrieb:
>> 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).
> 
I would not be so harsh all this currently is a huge work in progress as
I could see from the differences between the spec and the RI...

Since I am not in the EG I have
only info from what I can gather from the released pdfs and javadocs
and from the RI. The RI always seems to be ahead from the released PDFs
so I usually take it as my core reference.

a) I am aware of the upload issue and that you can only do it via
iframes if you want to stay on a clean html side. I will give a short
info on what I could gather from the spec and RI:

Sending a form is, that you have to gather the viewstate and you have to
send it as encoded String!
also you have to add various parameters and you can define a map of
passthrough values which have to be encoded similarily on the client side!

The request must be queued and it must be send asynchronously.
It is not clearly stated that you have to use xmlhttprequest for
sending, the RI however currently uses xmlhttprequest only!

Not sure if you can say an iframe post is an asynchronous post, but I
assume so...


> 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

At the current state of the RI is not, and I am not sure if the spec has
this loophole open, but as it is this needs to be clearly specified one
way or the other!
Otherwise we will have the next mess on our hands!
My per

The spec is rather vague on all this and the issue is that the RI as
core reference at the last public release (which funnily is not the same
as the last public released specs, the RI clearly is from mid december
while the pdfs are from november), does not cover it yet, either means
they are not aware of those issues or they simply do not have tackled it.

Re: Myfaces 2.0 and xhr transport

[Matthias Wessendorf <ma...@apache.org>]

> 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