myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Aranda <brunoara...@gmail.com>
Subject Re: dynamic styles in IE for MyFaces AJAX?
Date Mon, 13 Jul 2009 11:47:51 GMT
Being naive and not understanding the details of this issue, I want
just to comment on breaking compatibility. I think that at this
particular moment is not that bad if what we get is a better
implementation, because this is what users want. If you say that it
makes life easier for component developers this should be a good
change, and creating new components was never the best thing in the
previous versions. Is it breaking the spec? Or an
implementation/interpretation of the spec issue? If it is the latter,
there are good chances that mojarra will be updated as well, no? And
if the spec is not clear, it should be fixed.

Keep up the good work,

Bruno

2009/7/13 Werner Punz <werner.punz@gmail.com>:
> Ganesh schrieb:
>>
>> Hi,
>>
>> My problem with the attributes and eval sections of the xhr response (as
>> well as with insert and delete) is that the JSR-314 specs jsdocs define
>> them, but Mojarra 2.0 doesn't use them. Mojarra 2.0 sends an
>> eval/attributes/insert/delete/extensions xhr response under *no*
>> circumstances. Also the main spec PDF document doesn't mention them at all.
>> If you read the PDF, you'd think, only the updates section of the xhr
>> response is relevant. Also, Mojarras implemetation of
>> eval/attributes/insert/delete is rudimentary. I frequently wondered why they
>> defined this at all.
>>
>> Do we want to have identical xml data exchange in MyFaces 2.0 xhr as in
>> Mojarra 2.0? Will the users rely on the XML data format? The spec only
>> defines the syntax of the XMLSchema, so we are spec compliant, even if we
>> send the scripts and styles via the eval or extensions (or other) sections.
>> On the other hand I was trying to maintain Mojarra compatibility on the
>> transport layer and until now and I'm using the MyFaces script togther with
>> Mojarra 2.0 successfully. Please comment on this: Do we want 100%
>> compatibility on the xhr transport layer between Mojarra 2.0 and MyFaces 2.0
>> or do we want to enhance transport beyond Mojarra along the lines the specs
>> draw?
>>
>> If we decide for the second (enhance transport):
>> Why would you put <script>...</script> inside the attributes section?
The
>> spec says it is used to >>update the DOM element attribute value (whose name
>> matches attribute name), with attribute value<<. I can't see in which way
>> this is connected to replacing scripts.
>>
>> Best regards,
>> Ganesh
>>
>>
>
> Well I have been sending a commend regarding the eval/ upate etc... to the
> comments mailing list I hope it will be read (my last mail regarding auto
> eval obviously again was read by that /dev/null guy since I did not get any
> answer).
>
> My personal guess is lets wait if we get a response before doing further
> discussions. I have somewhat mixed feelings about it as well.
>
> But the question also arises do we really break compatbility on protocol
> level, I dont think so, but we clearly break it on component level, but only
> if it is used, so I´d rather have this extension being implemented on both
> implementations before going alone in this regard.
>
> I am not very eager to allow component authors behavior which works on
> myfaces alone on this level, but on the other hand I think the
> implementation is clearly broken and makes life miserable for the components
> authors if we dont cover this corner case.
>
>
>

Mime
View raw message