Ganesh schrieb:
Hi Werner,
I've been reading the current MyFaces 2.0 AJAX code. I want to try and
share my concerns on 4 subjects:
1. The collecting of form parameters will need some refinement:
getFormMap doesn't care for upper/lower case of tagname and type though
differ per browser and between HTML/XHTML.
getFormMap contains the comment "todo: do not post values for
non-triggering submit buttons"
Yes bug here, carried over from Trinidad (the entire encoding part was
straightly ported over from the Trinidad core), that needs to be fixed...
2. Response processing not implemented:
The complete PPR part is still missing. Different trinidad functions
exist to process XML and Text, but the code doesn't say anything yet
about the format of the XML response that is to be sent back.We probably
cannot rely on valid XML here, because the response may contain parts of
a JSP that aren't valid XML (like, for example,
<f:verbatim><br></f:verbatim>). Have you already defined a XML format we
could use for transport? I think it could be good idea to use the same
format as the RI does to make the AJAX libraries exchangeable.
Not done yet, the entire response handling is specified by the RI and
the spec, from what I have seen it uses XML as a core
with CDATA for areas where tags are embedded
but as I said that is a spec/RI issue, the latest public spec did not
have too much information yet, but the RI already has an implementation
so I would try to be as close as possible to the RI in this regard...
3. dojo cross-port:
The JSF2Utils class consists mostly of copied dojo code.
About 40% dojo code 30% ported Trinidad code and 30% other utils written
by me!
>Doesn't this
pose a licensing problem if you put it under the apache 2 license? I had
a look into the dojo licenses: They dual-license under bsd and afl and
both have different requirements if you want to copy and change their
source code. Here's what I found:
bsd: Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
afl: Licensor hereby agrees to provide a machine-readable copy of the
Source Code of the Original Work along with each copy of the Original
Work that Licensor distributes.
That needs further cleanup on the legal side, have in mind i am not a
legal expert. My opinion was that a clear license.txt and cross
references should be enough which states that parts of the code are from
dojo and under BSD license.
(as well as probably header information that the code under this header
is from dojo and under BSD license)
Since it is dual licensed it means that the dojo code is as well under
BSD as under AFL!
I am probably right with my assumption:
The first line of the dojo license states:
Dojo is available under *either* the terms of the modified BSD license
*or* the
Academic Free License version 2.1
And the modified BSD license just says that the license has to be
bundled and can be reproduced in source and binary form which is met by
a license.txt file added to the final binary and the sources
regarding the parts ported over from dojo with clear markers that this
part originates from dojo!
If anyone has a better legal knowledge please clarify this. But I am
pretty sure that we are on the legal side here! Since BSD is more or
less a no brainer and dojo has a dual license under both ASL and BSD!
4. Trinidad code needs further cleanup:
There are lots of functions like
myfaces._TrRequestQueue.prototype._doRequestThroughIframe that refer to
the old AJAX over IFRAME of ADF Faces which is not required for JSF 2.0.
Well the idea is that the Trinidad code is phased out, because the
entire thing would need an overhaul which basically spoken makes a
reimplementation probably easier and less time consuming than
cleaning up the old Trinidad codebase. The core idea was simply to
recycle Trinidas as being working code, I dropped the idea but left the
code in for now as reference to my own code to make testing easier!
(There is an internal switch in jsf.js which allows to switch between
both layers via framework adapters)
As for the iframe issue. It is not required, but I would
isolate the transport layers enough so that we can readd it.
The entire problem is that jsf2 basically leaves out the iframe while
not explicitely enforcing xhr instead of doing it implicitely.
(Afair they state, that the values have to be send queued and
asynchronously and the values have to be encoded via javascript from
the form values to be sent, which opens a huge can of worms regarding
file upload controls)
The iframe however is necessary to implement fileuploads as state above.
So in the long run we might need it again, but then definitely not
intermixed in the core codebase with xhr but as its own isolated
implementation to keep the maintainability!
In my understanding of the code it consists of 4 major parts:
- Trinidad RequestQueue
Will be dropped there is my own implementation acting as a full
replacement for the parts covered by the jsf2 spec.
As you can see two separate packates basically doing the same
the second one significantly smaller and packed into single classes for
every usecase!
- Dojo Javascript fiddling
Minor parts, mainly just a crossport for the hitch api, which is needed
for scope remapping, afair!
- OpenAjax
Yes enforced by the spec you cannot avoid that, the entire namespacing
is due to spec enforcements based on the OpenAjax namespacing API
- JSF2.0 spec. impl. parts
Yes that is the outer layer of everything basically the public api
exposed to the user!
What I want to suggest is to replace the trinidad and dojo parts with
repackaged J4Fry. It would take me less work to get the repackaged J4Fry
stuff running instead of trying to squeeze it into the dojo/trinidad
code. Would this be an appropriate and acceptable approach for you? Alex
and me could try and get this done within a few days.
Definitely a viable approach, we can rework the parts again in where it
definitely makes sense to reduce code...
My other point is: Why do you use a servlet for testing?
This was just internal development code, never to be committed, the
final tests once I had done it would have been against the RI anyway.
And in the long run probably a set of selenium tests should have kept
the testing part against myfaces!
So no big deal there. I just gave you the code to give you a short
quickstart on everything.
The servlet approach was just chosen because I wanted to stay on the
myfaces side, but I could not test it properly as long as I did not have
a responseWriter, so my idea was to simulate a mockup response for the
response handling part before moving over to the RI.
That way I would have at least a working core before moving over to
another moving target.
Another issue simply was that I did not have time to check out if the RI
already was working as expected in that area. So I preferred to do
mockups first before going against the RI (just a personal choice)
I did pretty much the same with the parts I had implemented where I
switched after thinking having things done right between my
implementation and the RI to check out if there were differences on post
protocol level!
