MyFaces 2.0 AJAX development path

[Ganesh <ga...@j4fry.org>]

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"

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.

3. dojo cross-port:
The JSF2Utils class consists mostly of copied dojo code. 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.

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.

In my understanding of the code it consists of 4 major parts:
- Trinidad RequestQueue
- Dojo Javascript fiddling
- OpenAjax
- JSF2.0 spec. impl. parts

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.

My other point is: Why do you use a servlet for testing? We could use
the RI to test the Javascript against and then move to the Java part
with pretested Javascript. This way we would also ensure full
compatibility of the XML formats used by both implementations. The only
point one could make is about size. If the RI's XML format turns out to
be quite talkative we could think about using a more performant format.
For this reason J4Fry was originally using JSON but the spec explicitly
dictates the use of XML here (god knows why ...). What do you think?

Best Regards,
Ganesh

Re: MyFaces 2.0 AJAX development path

[Hazem Saleh <ha...@apache.org>]

> " As I said I am not very much in favor of a full dojo dependency although
I personally love dojo."

+1.

On Wed, Apr 1, 2009 at 9:49 PM, Werner Punz <we...@gmail.com> wrote:

> Cool down guys :-)
> No seriously I have stated already why I personally would
> prefer not to get a direct dojo dependency into the myfaces core.
> However, I am fine with having ported useful code over from Dojo
> into the core.
>
> So my proposal is following:
>
> -1 to a dojo dependency in the myfaces core. I personally thing
> the dojo dependency in Tomahawk was evil enough and I am still working on
> getting it out into a separate component lib!
>
> Also the namespace in the core must be under the core javax and myfaces
> namespaces no external namespaces should be allowed to avoid namespace
> clashes. The namespacing also should follow the jsf2 conventions of using
> maps and using the openajax api!
>
> +1 if someone finds something useful we can take it from the dojo core lib
> but must adhere to the dojo license (license.txt with the dojo bsd license
> and references in the code should be suffice)
>
> Can anyone live with that? I personally for instance would love to have the
> dojo transport and logging layer being isolated out of dojo to be reused
> that stuff simply is phantastic but with a full dojo dependency for me this
> would be a no go...
>
> As I said I am not very much in favor of a full dojo dependency although I
> personally love dojo.
>
>
>
> Werner
>
>
>
>
> Ganesh schrieb:
>
>  Hi Michael,
>>
>> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
>> JSF solution from scratch I would certainly do this based on Dojo. I'm
>> currently making up some Facelets templates for Dojo JSF integration
>> (just a playground:
>> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
>> it's great fun! It's also good to hear that there are more people
>> willing to help with the MyFaces 2.0 AJAX.
>>
>> I think the primary problem is not doing some xhr in a queue and
>> processing of the callbacks. This has become standard stuff Trinidad and
>> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
>> is the way that J4Fry AJAX is integrated with JSF from scratch. In
>> detail there is:
>>
>>   * JSF ViewState processing
>>   * Component oriented processing of the HTML replacements
>>   * Submit parameters that trigger invoke application and render
>>     response phases
>>   * Parameters beyond the scope of the spec for PPS and several
>>     further features crucial for a good JSF AJAX experience
>>   * Javascript code is already ported to JSF 2.0 and has been tested
>>     against RI 2.0
>>   * Java code for server side processing has been running with JSF 1.2
>>     for a long time and waits for the JSF 2.0 port
>>   * JSR 168 portlet support
>>
>> I've also opened a jira for a list of features for JSF integration that go
>> far beyond the spec. These features weren't just implemented for JSF 2.0,
>> they have been productive in high performance business critical
>> applications for years.
>>
>> Implementing all of this from scratch based on dojo xhr is surely
>> possible, but it would probably take time to reach the necessary code
>> quality.
>>
>> Best Regards,
>> Ganesh
>>
>> Michael Concini schrieb:
>>
>>> Sorry I'm a little late to the discussion here, but I'm a little
>>> concerned with the direction here.  I'm not very familiar with the
>>> advantages or disadvantages of J4Fry, but I do know that we're not familiar
>>> with the state of the J4Fry code.  We do know Dojo is a mature release with
>>> top level performance and accessibility features.  In addition, Dojo is a
>>> very well known framework with a large and dedicated developer community
>>> surrounding it.  What does J4Fry offer that Dojo cannot?
>>>
>>> If the concern is developer resources, we have a team of developers at
>>> IBM who are very active in the Dojo community and who have offered their
>>> assistance to my team in porting the necessary code to MyFaces.  The license
>>> is really not a concern, as Dojo code is already being included in at least
>>> Apache project.  As long as you mention in your code comments that the code
>>> was ported from Dojo under the BSD license you shouldn't need to do anything
>>> else.
>>> I think it would be worthwhile to have a discussion among the community
>>> about which framework would be best to utilize going forward.
>>>
>>> Thanks,
>>> Mike
>>>
>>> Ganesh wrote:
>>>
>>>> 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"
>>>>
>>>> 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.
>>>>
>>>> 3. Dojo cross-port:
>>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>>
>>>> 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.
>>>>
>>>> In my understanding of the code it consists of 4 major parts:
>>>> - Trinidad RequestQueue
>>>> - Dojo Javascript fiddling
>>>> - OpenAjax
>>>> - JSF2.0 spec. impl. parts
>>>>
>>>> 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.
>>>>
>>>> My other point is: Why do you use a servlet for testing? We could use
>>>> the RI to test the Javascript against and then move to the Java part
>>>> with pretested Javascript. This way we would also ensure full
>>>> compatibility of the XML formats used by both implementations. The only
>>>> point one could make is about size. If the RI's XML format turns out to
>>>> be quite talkative we could think about using a more performant format.
>>>> For this reason J4Fry was originally using JSON but the spec explicitly
>>>> dictates the use of XML here (god knows why ...). What do you think?
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Hazem Ahmed Saleh Ahmed

Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

Web blog: http://www.jroller.com/page/HazemBlog

[Web 2.0] Google Maps Integration with JSF:
http://code.google.com/p/gmaps4jsf/
http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF

Re: MyFaces 2.0 AJAX development path

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

Btw. the same what I mentioned about dojo is also true for jquery and 
prototype and any other library.


Lets have in mind what we want to achieve:

a) Send queued asynchronous xhr requests on javascript encoded form data

b) Parse incoming xml

c) Use innerHTML for the incoming static content

d) Use eval for the incoming dynamic content in a safe way so that IE 
does not crash :-)

e) deal with incoming errors correctly

f) deal with listeners in a specified listener interface for various 
stages of the cycle

g) in the long run deal with browser inconsistencies on detail level and 
with portlets and iframe transports (for covering fileuploads)

Where in those areas do third party libs really help?
Almost nowhere except for the xhr request part and some logging, two 
areas too small to add another 50 kybte of code which 95% of it is not used!

My first choice as I said to cover all this was Trinidad but I gave up 
halfway because it simply was too much work to refactor the code down to 
the level I needed, it was basically the same work as to start from 
scratch and build a leaner more maintainable solution and reuse some 
parts of Trinidad!

J4fry in our Jira is similar currently to me as Trinidad was in the 
beginning (a possible candidate due to huge overlap of functionality) 
with the advantage that the developers seem to have done the adjustment 
work already so we just seem to have to do the integration work. But as 
I have to check the code first to see if it is viable for us. If it is 
it would be a good starting base and I could drop my own work! But then 
again I have to have a full integration in our namespace and probably 
some adjustments regarding jsf2!

In the end probably a few weeks of work would be safed for us (which 
wouldnt by using our old Trinidad core, and which would not by 
reimplementation from scratch!

So to give a short summary where I personally stand and why, and it is 
not performance we would not gain anything by using jquery and dojo 
because there are not too many areas where we even could apply their 
query apis (which really are fast)

Dojo: too much functionality we do not need, ripping out the core parts 
we need and integrating them if possible can and should be done. But to 
my experience some parts are hard to isolate due to intra function 
dependencies. Namespace mapping to our namespace for the parts we can 
reuse must be done!

JQuery: everything applies to jquery what was said about dojo, the 
functionality covered by jquery almost to 100% can be found in dojo as well!

Prototype: This is an absolute no go, the framework simply is too 
intrusive, hitchhiking the $ operator without any way out (jquery at 
least has a mode to switch that off), hitchhiking base objects extending 
them. This framework should not be touched with a 10 foot pole.

Trinidad: The overlap is almost 100% functionality wise, but the 
codebase is old and proven. But the core shows its age and needs serious 
cleanup and overhaul to be in line with the spec. Some work was done to 
clean it up, but in the end it was given up by me in favor of a lean 
small and maintainable codebase where parts of Trinidad which were 
needed by the spec were reused!

J4Fry: I will check the code today but the functionality overlap here 
also is almost 100%! And add to that that the maintainers basically did 
on a weekend a jsf2 compatible port of the codebase (which still 
probably needs some adjustments, and we probably get the needed 
undocumented stuff for portlets, fileupload etc...
(Btw. all things not covered by the RI at all)

So I guess everyone can see why my incentive currently goes towards 
dropping my homegrown/trinidad based codebase in favor of j4fry if the 
code quality is good! And why I rather would stay away from the 
integration of the javascript library of choice for now, although I am a 
dedicated fan of those frameworks myself (and use them extensively in my 
own projects: http://tutorials.irian.at/book_de/introduction.html)


Werner








Andrew Robinson schrieb:
> I have a different suggestion.
> 
> Each proponent(s) of a 3rd party AJAX solution, create a WIKI page on 
> the apache website with PROS and CONS for that library. In that WIKI, 
> include a gap analysis of the library vs. the JSF2 spec. requirements. 
> Also mention speed performance and download performance (size) and also 
> flexibility and maintainability.
> 
> Then once these WIKIs are complete enough, the dev@ community can use 
> them as a discussion point on one or another. I just think an email 
> thread for this is not the right solution until the full picture is seen 
> for each library.
> 
> I'm surprised no one has mentioned jQuery since Dojo keeps getting 
> mentioned, as jQuery currently has some of the fastest performing code 
> for XPath-like page lookups. Not to mention jQuery is 19KB where Dojo is 
> 80KB
> 
> -Andrew
> 
> On Wed, Apr 1, 2009 at 3:31 PM, Ganesh <ganesh@j4fry.org 
> <ma...@j4fry.org>> wrote:
> 
>     Hi,
> 
>     I'm sorry if I was sounding "hot". It's just that I'd really love
>     the JSF AJAX code we've been crafting and refining for years at
>     J4Fry to go into MyFaces and I think there are reasonable arguments
>     for this. I'm only trying to bring them forward with the hope of
>     convincing everyone ;-)
> 
>     Dojo code is cool and it's hype, so if there is anything we can use
>     from it that'll be great. License is probably a minor issue here.
>     What exactly do you mean: "transport and logging layer"?
> 
>     My understanding of transport is that it is hardly more that
>     instantiating an xmlhttprequest and queueing the callback. I'm
>     afraid "crossporting" the dojo code wouldn't do a great deal of
>     change to the code as it's pretty much the same in many AJAX
>     implementations including J4Fry and trinidad (please correct me of
>     the parts if I'm overseeing here).
> 
>     The logging part in dojo in really good - but it depends on firebug!
>     Would you want to include firebug lite with MyFaces??? I'm not quite
>     sure of the size of it and it certainly needs lots of improvement
>     and bugfixing and the state we put into MyFaces would be frozen - we
>     would need to crossport new releases as they evolve.
> 
>     As you see there are several doubts on my side, but I would be happy
>     if you enlightened me in understanding the exact meaning of what you
>     where suggesting.
> 
>     Best Regards,
>     Ganesh
> 
> 
> 
>     Werner Punz schrieb:
> 
>         Cool down guys :-)
>         No seriously I have stated already why I personally would
>         prefer not to get a direct dojo dependency into the myfaces core.
>         However, I am fine with having ported useful code over from Dojo
>         into the core.
> 
>         So my proposal is following:
> 
>         -1 to a dojo dependency in the myfaces core. I personally thing
>         the dojo dependency in Tomahawk was evil enough and I am still
>         working on getting it out into a separate component lib!
> 
>         Also the namespace in the core must be under the core javax and
>         myfaces namespaces no external namespaces should be allowed to
>         avoid namespace clashes. The namespacing also should follow the
>         jsf2 conventions of using maps and using the openajax api!
> 
>         +1 if someone finds something useful we can take it from the
>         dojo core lib
>         but must adhere to the dojo license (license.txt with the dojo
>         bsd license and references in the code should be suffice)
> 
>         Can anyone live with that? I personally for instance would love
>         to have the dojo transport and logging layer being isolated out
>         of dojo to be reused that stuff simply is phantastic but with a
>         full dojo dependency for me this would be a no go...
> 
>         As I said I am not very much in favor of a full dojo dependency
>         although I personally love dojo.
> 
> 
> 
>         Werner
> 
> 
> 
> 
>         Ganesh schrieb:
> 
>             Hi Michael,
> 
>             Yes, I agree, Dojo is extremely cool. If I had to start of
>             with an AJX
>             JSF solution from scratch I would certainly do this based on
>             Dojo. I'm
>             currently making up some Facelets templates for Dojo JSF
>             integration
>             (just a playground:
>             http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml)
>             and
>             it's great fun! It's also good to hear that there are more
>             people
>             willing to help with the MyFaces 2.0 AJAX.
> 
>             I think the primary problem is not doing some xhr in a queue and
>             processing of the callbacks. This has become standard stuff
>             Trinidad and
>             Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The
>             difference
>             is the way that J4Fry AJAX is integrated with JSF from
>             scratch. In
>             detail there is:
> 
>               * JSF ViewState processing
>               * Component oriented processing of the HTML replacements
>               * Submit parameters that trigger invoke application and render
>                 response phases
>               * Parameters beyond the scope of the spec for PPS and several
>                 further features crucial for a good JSF AJAX experience
>               * Javascript code is already ported to JSF 2.0 and has
>             been tested
>                 against RI 2.0
>               * Java code for server side processing has been running
>             with JSF 1.2
>                 for a long time and waits for the JSF 2.0 port
>               * JSR 168 portlet support
> 
>             I've also opened a jira for a list of features for JSF
>             integration that go far beyond the spec. These features
>             weren't just implemented for JSF 2.0, they have been
>             productive in high performance business critical
>             applications for years.
> 
>             Implementing all of this from scratch based on dojo xhr is
>             surely possible, but it would probably take time to reach
>             the necessary code quality.
> 
>             Best Regards,
>             Ganesh
> 
>             Michael Concini schrieb:
> 
>                 Sorry I'm a little late to the discussion here, but I'm
>                 a little concerned with the direction here.  I'm not
>                 very familiar with the advantages or disadvantages of
>                 J4Fry, but I do know that we're not familiar with the
>                 state of the J4Fry code.  We do know Dojo is a mature
>                 release with top level performance and accessibility
>                 features.  In addition, Dojo is a very well known
>                 framework with a large and dedicated developer community
>                 surrounding it.  What does J4Fry offer that Dojo cannot?
> 
>                 If the concern is developer resources, we have a team of
>                 developers at IBM who are very active in the Dojo
>                 community and who have offered their assistance to my
>                 team in porting the necessary code to MyFaces.  The
>                 license is really not a concern, as Dojo code is already
>                 being included in at least Apache project.  As long as
>                 you mention in your code comments that the code was
>                 ported from Dojo under the BSD license you shouldn't
>                 need to do anything else.
>                 I think it would be worthwhile to have a discussion
>                 among the community about which framework would be best
>                 to utilize going forward.
> 
>                 Thanks,
>                 Mike
> 
>                 Ganesh wrote:
> 
>                     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"
> 
>                     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.
> 
>                     3. Dojo cross-port:
>                     The JSF2Utils class consists mostly of copied Dojo
>                     code. 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.
> 
>                     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.
> 
>                     In my understanding of the code it consists of 4
>                     major parts:
>                     - Trinidad RequestQueue
>                     - Dojo Javascript fiddling
>                     - OpenAjax
>                     - JSF2.0 spec. impl. parts
> 
>                     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.
> 
>                     My other point is: Why do you use a servlet for
>                     testing? We could use
>                     the RI to test the Javascript against and then move
>                     to the Java part
>                     with pretested Javascript. This way we would also
>                     ensure full
>                     compatibility of the XML formats used by both
>                     implementations. The only
>                     point one could make is about size. If the RI's XML
>                     format turns out to
>                     be quite talkative we could think about using a more
>                     performant format.
>                     For this reason J4Fry was originally using JSON but
>                     the spec explicitly
>                     dictates the use of XML here (god knows why ...).
>                     What do you think?
> 
>                     Best Regards,
>                     Ganesh
> 
> 
> 
> 
> 
> 
> 

Re: MyFaces 2.0 AJAX development path

[Andrew Robinson <an...@gmail.com>]

Whoops, wrong #, jquery is 56K not 19K.

GZip size is jQuery 19KB, Dojo 27K

-Andrew

On Wed, Apr 1, 2009 at 4:27 PM, Andrew Robinson <
andrew.rw.robinson@gmail.com> wrote:

> I have a different suggestion.
>
> Each proponent(s) of a 3rd party AJAX solution, create a WIKI page on the
> apache website with PROS and CONS for that library. In that WIKI, include a
> gap analysis of the library vs. the JSF2 spec. requirements. Also mention
> speed performance and download performance (size) and also flexibility and
> maintainability.
>
> Then once these WIKIs are complete enough, the dev@ community can use them
> as a discussion point on one or another. I just think an email thread for
> this is not the right solution until the full picture is seen for each
> library.
>
> I'm surprised no one has mentioned jQuery since Dojo keeps getting
> mentioned, as jQuery currently has some of the fastest performing code for
> XPath-like page lookups. Not to mention jQuery is 19KB where Dojo is 80KB
>
> -Andrew
>
>
> On Wed, Apr 1, 2009 at 3:31 PM, Ganesh <ga...@j4fry.org> wrote:
>
>> Hi,
>>
>> I'm sorry if I was sounding "hot". It's just that I'd really love the JSF
>> AJAX code we've been crafting and refining for years at J4Fry to go into
>> MyFaces and I think there are reasonable arguments for this. I'm only trying
>> to bring them forward with the hope of convincing everyone ;-)
>>
>> Dojo code is cool and it's hype, so if there is anything we can use from
>> it that'll be great. License is probably a minor issue here. What exactly do
>> you mean: "transport and logging layer"?
>>
>> My understanding of transport is that it is hardly more that instantiating
>> an xmlhttprequest and queueing the callback. I'm afraid "crossporting" the
>> dojo code wouldn't do a great deal of change to the code as it's pretty much
>> the same in many AJAX implementations including J4Fry and trinidad (please
>> correct me of the parts if I'm overseeing here).
>>
>> The logging part in dojo in really good - but it depends on firebug! Would
>> you want to include firebug lite with MyFaces??? I'm not quite sure of the
>> size of it and it certainly needs lots of improvement and bugfixing and the
>> state we put into MyFaces would be frozen - we would need to crossport new
>> releases as they evolve.
>>
>> As you see there are several doubts on my side, but I would be happy if
>> you enlightened me in understanding the exact meaning of what you where
>> suggesting.
>>
>> Best Regards,
>> Ganesh
>>
>>
>>
>> Werner Punz schrieb:
>>
>>  Cool down guys :-)
>>> No seriously I have stated already why I personally would
>>> prefer not to get a direct dojo dependency into the myfaces core.
>>> However, I am fine with having ported useful code over from Dojo
>>> into the core.
>>>
>>> So my proposal is following:
>>>
>>> -1 to a dojo dependency in the myfaces core. I personally thing
>>> the dojo dependency in Tomahawk was evil enough and I am still working on
>>> getting it out into a separate component lib!
>>>
>>> Also the namespace in the core must be under the core javax and myfaces
>>> namespaces no external namespaces should be allowed to avoid namespace
>>> clashes. The namespacing also should follow the jsf2 conventions of using
>>> maps and using the openajax api!
>>>
>>> +1 if someone finds something useful we can take it from the dojo core
>>> lib
>>> but must adhere to the dojo license (license.txt with the dojo bsd
>>> license and references in the code should be suffice)
>>>
>>> Can anyone live with that? I personally for instance would love to have
>>> the dojo transport and logging layer being isolated out of dojo to be reused
>>> that stuff simply is phantastic but with a full dojo dependency for me this
>>> would be a no go...
>>>
>>> As I said I am not very much in favor of a full dojo dependency although
>>> I personally love dojo.
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>>
>>> Ganesh schrieb:
>>>
>>>> Hi Michael,
>>>>
>>>> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
>>>> JSF solution from scratch I would certainly do this based on Dojo. I'm
>>>> currently making up some Facelets templates for Dojo JSF integration
>>>> (just a playground:
>>>> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
>>>> it's great fun! It's also good to hear that there are more people
>>>> willing to help with the MyFaces 2.0 AJAX.
>>>>
>>>> I think the primary problem is not doing some xhr in a queue and
>>>> processing of the callbacks. This has become standard stuff Trinidad and
>>>> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
>>>> is the way that J4Fry AJAX is integrated with JSF from scratch. In
>>>> detail there is:
>>>>
>>>>   * JSF ViewState processing
>>>>   * Component oriented processing of the HTML replacements
>>>>   * Submit parameters that trigger invoke application and render
>>>>     response phases
>>>>   * Parameters beyond the scope of the spec for PPS and several
>>>>     further features crucial for a good JSF AJAX experience
>>>>   * Javascript code is already ported to JSF 2.0 and has been tested
>>>>     against RI 2.0
>>>>   * Java code for server side processing has been running with JSF 1.2
>>>>     for a long time and waits for the JSF 2.0 port
>>>>   * JSR 168 portlet support
>>>>
>>>> I've also opened a jira for a list of features for JSF integration that
>>>> go far beyond the spec. These features weren't just implemented for JSF 2.0,
>>>> they have been productive in high performance business critical
>>>> applications for years.
>>>>
>>>> Implementing all of this from scratch based on dojo xhr is surely
>>>> possible, but it would probably take time to reach the necessary code
>>>> quality.
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>> Michael Concini schrieb:
>>>>
>>>>> Sorry I'm a little late to the discussion here, but I'm a little
>>>>> concerned with the direction here.  I'm not very familiar with the
>>>>> advantages or disadvantages of J4Fry, but I do know that we're not familiar
>>>>> with the state of the J4Fry code.  We do know Dojo is a mature release with
>>>>> top level performance and accessibility features.  In addition, Dojo is a
>>>>> very well known framework with a large and dedicated developer community
>>>>> surrounding it.  What does J4Fry offer that Dojo cannot?
>>>>>
>>>>> If the concern is developer resources, we have a team of developers at
>>>>> IBM who are very active in the Dojo community and who have offered their
>>>>> assistance to my team in porting the necessary code to MyFaces.  The license
>>>>> is really not a concern, as Dojo code is already being included in at least
>>>>> Apache project.  As long as you mention in your code comments that the code
>>>>> was ported from Dojo under the BSD license you shouldn't need to do anything
>>>>> else.
>>>>> I think it would be worthwhile to have a discussion among the community
>>>>> about which framework would be best to utilize going forward.
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>> Ganesh wrote:
>>>>>
>>>>>> 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"
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 3. Dojo cross-port:
>>>>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> In my understanding of the code it consists of 4 major parts:
>>>>>> - Trinidad RequestQueue
>>>>>> - Dojo Javascript fiddling
>>>>>> - OpenAjax
>>>>>> - JSF2.0 spec. impl. parts
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> My other point is: Why do you use a servlet for testing? We could use
>>>>>> the RI to test the Javascript against and then move to the Java part
>>>>>> with pretested Javascript. This way we would also ensure full
>>>>>> compatibility of the XML formats used by both implementations. The
>>>>>> only
>>>>>> point one could make is about size. If the RI's XML format turns out
>>>>>> to
>>>>>> be quite talkative we could think about using a more performant
>>>>>> format.
>>>>>> For this reason J4Fry was originally using JSON but the spec
>>>>>> explicitly
>>>>>> dictates the use of XML here (god knows why ...). What do you think?
>>>>>>
>>>>>> Best Regards,
>>>>>> Ganesh
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>

Re: MyFaces 2.0 J4Fry first comments

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

Ok additional comments,
once the listener interface is again integrated
we probably can move most of the visual code out of the core
into listeners reusable by the user.

(
input field disabling enabling
progress display etc...
)

The result would be that the core is reduced down to the xhr handling
and event handling,

the visual aspects then would be listeners usable within the
jsf2 api!



Werner




Werner Punz schrieb:
> Ok I have checked the j4fry code.
> So far it looks pretty good to me, well documented and clean and has 
> worked around a few pitfalls, however some things have to be changed.
> 
> I personally would recommend to move the connection between jsf2.js and
> the j4fry code into an adapter class, like I did with my code.
> 
> The reason is, the adapter class is needed to isolate jsf2 specifics 
> from the underlying implementation details. Stuff like progress displays 
> or invalidation of controls and custom options,
> should be handled within the adapters as long as they are not specified
> explicitely.
> 
> The adapter also can isolate jsf2 from the underlying transport and ppr 
> mechanisms to a certain degree and allows other frameworks to exchange 
> the transports if the need arises!
> (which again would give us an advantage over the RI which has everything 
> hardcoded into one big class)
> 
> So the calling hierarchy is jsf2 api <-> framework adapter with a clear 
> well defined interface <-> implementation
> 
> This also allows us to exchange the underlying frameworks with a simple 
> switch (like I did for Trinidad and my own implementation)
> The implementation can call back into jsf2 (it should not if possible
> the adapter should) but jsf2 should not call directly into the 
> implementation it should call the adapter!
> 
> Also not found in the public specs but in the latest ri is a listener
> mechanism which notifies the listeners in various stages of the 
> lifecycle, I assume since the RI has them as public APIs that those are 
> in later non public specs. I implemented those for exactly this reason, 
> you basically can copy paste it from me.
> 
> Also for the J4Fry specific additonal options, can anyone check in the 
> latest specs if frameworks are allowed to offer additional functionality 
> via custom options?
> 
> Those should be moved into one single submap under the myfaces namespace 
> to avoid namespace collissions with public options set by the user!
> Those can be processed and mapped on adapter level, I guess!
> 
> So far my first comments on the j4fry code :-)
> 
> And last but not least: Namespaces they should be moved over to the 
> myfaces umbrella, and the comments have to be translated to english.
> 
> 
> And please don´t get me wrong, the code quality is excellent! I really 
> like what I have seen so far...
> 
> 

Re: MyFaces 2.0 J4Fry first comments

[Michael Concini <mc...@gmail.com>]

My initial instinct is to +1 for the use of an adapter class to allow 
for plugging in different implementations as well. 

I've got some time setup next week for my team to sit with the IBM Dojo 
experts on Monday to discuss further though, so for now I'm going to 
stay in the background while things continue to develop. 

Ganesh wrote:
> Hi Werner,
>
> 95% ack.
>
> 1. Having an adapter class would also give all of our dojo, jQuery and 
> trinidad friends a chance to plugin concurrent implementations and 
> provide performance tests or other advantages their implemetations 
> mights have.
>
> 2. The listeners are definitely a huge plus against the current spec. 
> They remove the need for most of the additional attributes described 
> in MYFACES-2174. Here are the ones that would still be needed: 
> queuesize, errorlevel and submit. Having them in a subarray 
> myfaces:{queuesize: (int), errorlevel (warning/error/fatal), submit 
> (componentIds)} will clarify on that this is beyond the specs. We'll 
> need to extend the adapter interface to pass the options array. I'll 
> update MYFACES.2174 on this. For the other options it would be nice to 
> provide a wrapper function that accepts disable, loadingbar and 
> postcallback parameters. Which would be the correct place for this 
> wrapper to go? Provide it together with the MyFaces core? Put it into 
> tomahawk? Create a separate project, maybe even within J4Fry that 
> releases a jar containing only this wrapper, so it can be used inside 
> RI too?
>
> 3. Translantion of the comments must done.
>
> I'll go for 1., 2. and 3. during the next few days.
>
> Here's the 5%:
>
> Why these namespace concerns? Isn't org.apache.myfaces the natural 
> choice? How could this lead to namespace collisions? Actually 
> myfaces.* is shorter, so it would be ok, too. Please clarify.
>
> Currently I'm working on fixing the request queue, because in J4Fry we 
> where only using a 1 element queue. Actually I'm missing a reasonable 
> use case for a bigger AJAX request queue. Imagine a user typing 
> letters in an input field with each letter queueing an AJAX request 
> onKeyup. Now, the first request will submit immedately and the engine 
> starts waiting for the callback. In the meantime the user types 5 more 
> letters, each of them queueing another request. So, what whould 
> happen, when the first request has returned? The 2nd request would now 
> start collecting form values (cannot be done before, because state 
> might have changed because of request 1), but the input field now 
> already contains all 6 letters the user has typed. Consequently, all 5 
> queued requests would submit the same values, thus producing 5 
> identical xhrs. Do you have an idea which szenario could be targeted 
> with a queue size > 1?
>
> Best Regards,
> Ganesh
>
> Werner Punz schrieb:
>> Ok I have checked the j4fry code.
>> So far it looks pretty good to me, well documented and clean and has 
>> worked around a few pitfalls, however some things have to be changed.
>>
>> I personally would recommend to move the connection between jsf2.js and
>> the j4fry code into an adapter class, like I did with my code.
>>
>> The reason is, the adapter class is needed to isolate jsf2 specifics 
>> from the underlying implementation details. Stuff like progress 
>> displays or invalidation of controls and custom options,
>> should be handled within the adapters as long as they are not specified
>> explicitely.
>>
>> The adapter also can isolate jsf2 from the underlying transport and 
>> ppr mechanisms to a certain degree and allows other frameworks to 
>> exchange the transports if the need arises!
>> (which again would give us an advantage over the RI which has 
>> everything hardcoded into one big class)
>>
>> So the calling hierarchy is jsf2 api <-> framework adapter with a 
>> clear well defined interface <-> implementation
>>
>> This also allows us to exchange the underlying frameworks with a 
>> simple switch (like I did for Trinidad and my own implementation)
>> The implementation can call back into jsf2 (it should not if possible
>> the adapter should) but jsf2 should not call directly into the 
>> implementation it should call the adapter!
>>
>> Also not found in the public specs but in the latest ri is a listener
>> mechanism which notifies the listeners in various stages of the 
>> lifecycle, I assume since the RI has them as public APIs that those 
>> are in later non public specs. I implemented those for exactly this 
>> reason, you basically can copy paste it from me.
>>
>> Also for the J4Fry specific additonal options, can anyone check in 
>> the latest specs if frameworks are allowed to offer additional 
>> functionality via custom options?
>>
>> Those should be moved into one single submap under the myfaces 
>> namespace to avoid namespace collissions with public options set by 
>> the user!
>> Those can be processed and mapped on adapter level, I guess!
>>
>> So far my first comments on the j4fry code :-)
>>
>> And last but not least: Namespaces they should be moved over to the 
>> myfaces umbrella, and the comments have to be translated to english.
>>
>>
>> And please don´t get me wrong, the code quality is excellent! I 
>> really like what I have seen so far...
>>
>

Re: MyFaces 2.0 J4Fry first comments

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

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!

Re: MyFaces 2.0 J4Fry first comments

[Ganesh <ga...@j4fry.org>]

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).

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).

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).

- 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.

Best Regards,
Ganesh

Werner Punz schrieb:
> Ganesh schrieb:
>> Hi Werner,
>>
>> 95% ack.
>>
>> 1. Having an adapter class would also give all of our dojo, jQuery 
>> and trinidad friends a chance to plugin concurrent implementations 
>> and provide performance tests or other advantages their 
>> implemetations mights have.
>>
> Yes definitely... I think the core implementation parts should be 
> pluggable...
>
>> 2. The listeners are definitely a huge plus against the current spec. 
>> They remove the need for most of the additional attributes described 
>> in MYFACES-2174. Here are the ones that would still be needed: 
>> queuesize, errorlevel and submit. Having them in a subarray 
>> myfaces:{queuesize: (int), errorlevel (warning/error/fatal), submit 
>> (componentIds)}
>
> Ok errorlevel can be kept submit definitely not, this is covered in 
> the standard option parameter execute (which covers a list of 
> component ids to be executed) and also the render paramter covers the 
> list of component ids to be processed by the response drawing.
>
>  will
>> clarify on that this is beyond the specs. We'll need to extend the 
>> adapter interface to pass the options array.
> Actually what I would propose is to use my jsf.js which is basically 
> the outer core, doing al the execute and render preprocessing and hook 
> yourself into their with your own adapter...
> That way we can cover the standard stuff (like how the render and 
> execute ids have to be collected and converted)
> and then on your side you can do additonal processing.
> What I would say, for non standard staff we can follow the jsf way
> but adding our own myfaces submap to the options which allow to add 
> additional parameters which are implementation dependend..
>
>
>  I'll update MYFACES.2174 on
>> this. For the other options it would be nice to provide a wrapper 
>> function that accepts disable, loadingbar and postcallback 
>> parameters. Which would be the correct place for this wrapper to go? 
>> Provide it together with the MyFaces core? Put it into tomahawk? 
>> Create a separate project, maybe even within J4Fry that releases a 
>> jar containing only this wrapper, so it can be used inside RI too?
>>
> Actually I probably would add simply a set of listener function 
> classes instances of them then can be added to the listener queue on 
> the fly...
> The implementation specifics then are just a matter of implementing 
> the interface needed to call the listeners.
> The place could be in the impl package somewhere, or our extension 
> project.
>
>
>
>> 3. Translantion of the comments must done.
>>
>> I'll go for 1., 2. and 3. during the next few days.
>>
>> Here's the 5%:
>>
>> Why these namespace concerns? Isn't org.apache.myfaces the natural 
>> choice? How could this lead to namespace collisions? Actually 
>> myfaces.* is shorter, so it would be ok, too. Please clarify.
>>
> It is myfaces for now, we can rechange that simply by using a regexp...
> It used to be org.apache.myfaces but it was too long for my taste.
> Especiall also since org is a generic root so using that as root
> via openajax cannot be reserved to apache or myfaces, hence myfaces 
> and nothing else!
>
>
>> Currently I'm working on fixing the request queue, because in J4Fry 
>> we where only using a 1 element queue. Actually I'm missing a 
>> reasonable use case for a bigger AJAX request queue. Imagine a user 
>> typing letters in an input field with each letter queueing an AJAX 
>> request onKeyup. Now, the first request will submit immedately and 
>> the engine starts waiting for the callback. In the meantime the user 
>> types 5 more letters, each of them queueing another request. So, what 
>> whould happen, when the first request has returned? The 2nd request 
>> would now start collecting form values (cannot be done before, 
>> because state might have changed because of request 1), but the input 
>> field now already contains all 6 letters the user has typed. 
>> Consequently, all 5 queued requests would submit the same values, 
>> thus producing 5 identical xhrs. Do you have an idea which szenario 
>> could be targeted with a queue size > 1?
>>
> One thing instantly comes to mind, dynamic scrolling...
> Or short inputs affecting two different forms, also
> real time validation of input text comes to mind where this szenario 
> definitely is better with a long queue and yet stil must perform 
> asynchronously.
>
>
>
>> Best Regards,
>> Ganesh
>>
>> Werner Punz schrieb:
>>> Ok I have checked the j4fry code.
>>> So far it looks pretty good to me, well documented and clean and has 
>>> worked around a few pitfalls, however some things have to be changed.
>>>
>>> I personally would recommend to move the connection between jsf2.js and
>>> the j4fry code into an adapter class, like I did with my code.
>>>
>>> The reason is, the adapter class is needed to isolate jsf2 specifics 
>>> from the underlying implementation details. Stuff like progress 
>>> displays or invalidation of controls and custom options,
>>> should be handled within the adapters as long as they are not specified
>>> explicitely.
>>>
>>> The adapter also can isolate jsf2 from the underlying transport and 
>>> ppr mechanisms to a certain degree and allows other frameworks to 
>>> exchange the transports if the need arises!
>>> (which again would give us an advantage over the RI which has 
>>> everything hardcoded into one big class)
>>>
>>> So the calling hierarchy is jsf2 api <-> framework adapter with a 
>>> clear well defined interface <-> implementation
>>>
>>> This also allows us to exchange the underlying frameworks with a 
>>> simple switch (like I did for Trinidad and my own implementation)
>>> The implementation can call back into jsf2 (it should not if possible
>>> the adapter should) but jsf2 should not call directly into the 
>>> implementation it should call the adapter!
>>>
>>> Also not found in the public specs but in the latest ri is a listener
>>> mechanism which notifies the listeners in various stages of the 
>>> lifecycle, I assume since the RI has them as public APIs that those 
>>> are in later non public specs. I implemented those for exactly this 
>>> reason, you basically can copy paste it from me.
>>>
>>> Also for the J4Fry specific additonal options, can anyone check in 
>>> the latest specs if frameworks are allowed to offer additional 
>>> functionality via custom options?
>>>
>>> Those should be moved into one single submap under the myfaces 
>>> namespace to avoid namespace collissions with public options set by 
>>> the user!
>>> Those can be processed and mapped on adapter level, I guess!
>>>
>>> So far my first comments on the j4fry code :-)
>>>
>>> And last but not least: Namespaces they should be moved over to the 
>>> myfaces umbrella, and the comments have to be translated to english.
>>>
>>>
>>> And please don´t get me wrong, the code quality is excellent! I 
>>> really like what I have seen so far...
>>>
>>
>

Re: MyFaces 2.0 J4Fry first comments

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

Ganesh schrieb:
> Hi Werner,
> 
> 95% ack.
> 
> 1. Having an adapter class would also give all of our dojo, jQuery and 
> trinidad friends a chance to plugin concurrent implementations and 
> provide performance tests or other advantages their implemetations 
> mights have.
> 
Yes definitely... I think the core implementation parts should be 
pluggable...

> 2. The listeners are definitely a huge plus against the current spec. 
> They remove the need for most of the additional attributes described in 
> MYFACES-2174. Here are the ones that would still be needed: queuesize, 
> errorlevel and submit. Having them in a subarray myfaces:{queuesize: 
> (int), errorlevel (warning/error/fatal), submit (componentIds)}

Ok errorlevel can be kept submit definitely not, this is covered in the 
standard option parameter execute (which covers a list of component ids 
to be executed) and also the render paramter covers the list of 
component ids to be processed by the response drawing.

  will
> clarify on that this is beyond the specs. We'll need to extend the 
> adapter interface to pass the options array.
Actually what I would propose is to use my jsf.js which is basically the 
outer core, doing al the execute and render preprocessing and hook 
yourself into their with your own adapter...
That way we can cover the standard stuff (like how the render and 
execute ids have to be collected and converted)
and then on your side you can do additonal processing.
What I would say, for non standard staff we can follow the jsf way
but adding our own myfaces submap to the options which allow to add 
additional parameters which are implementation dependend..


  I'll update MYFACES.2174 on
> this. For the other options it would be nice to provide a wrapper 
> function that accepts disable, loadingbar and postcallback parameters. 
> Which would be the correct place for this wrapper to go? Provide it 
> together with the MyFaces core? Put it into tomahawk? Create a separate 
> project, maybe even within J4Fry that releases a jar containing only 
> this wrapper, so it can be used inside RI too?
> 
Actually I probably would add simply a set of listener function classes 
instances of them then can be added to the listener queue on the fly...
The implementation specifics then are just a matter of implementing the 
interface needed to call the listeners.
The place could be in the impl package somewhere, or our extension project.



> 3. Translantion of the comments must done.
> 
> I'll go for 1., 2. and 3. during the next few days.
> 
> Here's the 5%:
> 
> Why these namespace concerns? Isn't org.apache.myfaces the natural 
> choice? How could this lead to namespace collisions? Actually myfaces.* 
> is shorter, so it would be ok, too. Please clarify.
> 
It is myfaces for now, we can rechange that simply by using a regexp...
It used to be org.apache.myfaces but it was too long for my taste.
Especiall also since org is a generic root so using that as root
via openajax cannot be reserved to apache or myfaces, hence myfaces and 
nothing else!


> Currently I'm working on fixing the request queue, because in J4Fry we 
> where only using a 1 element queue. Actually I'm missing a reasonable 
> use case for a bigger AJAX request queue. Imagine a user typing letters 
> in an input field with each letter queueing an AJAX request onKeyup. 
> Now, the first request will submit immedately and the engine starts 
> waiting for the callback. In the meantime the user types 5 more letters, 
> each of them queueing another request. So, what whould happen, when the 
> first request has returned? The 2nd request would now start collecting 
> form values (cannot be done before, because state might have changed 
> because of request 1), but the input field now already contains all 6 
> letters the user has typed. Consequently, all 5 queued requests would 
> submit the same values, thus producing 5 identical xhrs. Do you have an 
> idea which szenario could be targeted with a queue size > 1?
> 
One thing instantly comes to mind, dynamic scrolling...
Or short inputs affecting two different forms, also
real time validation of input text comes to mind where this szenario 
definitely is better with a long queue and yet stil must perform 
asynchronously.



> Best Regards,
> Ganesh
> 
> Werner Punz schrieb:
>> Ok I have checked the j4fry code.
>> So far it looks pretty good to me, well documented and clean and has 
>> worked around a few pitfalls, however some things have to be changed.
>>
>> I personally would recommend to move the connection between jsf2.js and
>> the j4fry code into an adapter class, like I did with my code.
>>
>> The reason is, the adapter class is needed to isolate jsf2 specifics 
>> from the underlying implementation details. Stuff like progress 
>> displays or invalidation of controls and custom options,
>> should be handled within the adapters as long as they are not specified
>> explicitely.
>>
>> The adapter also can isolate jsf2 from the underlying transport and 
>> ppr mechanisms to a certain degree and allows other frameworks to 
>> exchange the transports if the need arises!
>> (which again would give us an advantage over the RI which has 
>> everything hardcoded into one big class)
>>
>> So the calling hierarchy is jsf2 api <-> framework adapter with a 
>> clear well defined interface <-> implementation
>>
>> This also allows us to exchange the underlying frameworks with a 
>> simple switch (like I did for Trinidad and my own implementation)
>> The implementation can call back into jsf2 (it should not if possible
>> the adapter should) but jsf2 should not call directly into the 
>> implementation it should call the adapter!
>>
>> Also not found in the public specs but in the latest ri is a listener
>> mechanism which notifies the listeners in various stages of the 
>> lifecycle, I assume since the RI has them as public APIs that those 
>> are in later non public specs. I implemented those for exactly this 
>> reason, you basically can copy paste it from me.
>>
>> Also for the J4Fry specific additonal options, can anyone check in the 
>> latest specs if frameworks are allowed to offer additional 
>> functionality via custom options?
>>
>> Those should be moved into one single submap under the myfaces 
>> namespace to avoid namespace collissions with public options set by 
>> the user!
>> Those can be processed and mapped on adapter level, I guess!
>>
>> So far my first comments on the j4fry code :-)
>>
>> And last but not least: Namespaces they should be moved over to the 
>> myfaces umbrella, and the comments have to be translated to english.
>>
>>
>> And please don´t get me wrong, the code quality is excellent! I really 
>> like what I have seen so far...
>>
> 

Re: MyFaces 2.0 J4Fry first comments

[Ganesh <ga...@j4fry.org>]

Hi Werner,

95% ack.

1. Having an adapter class would also give all of our dojo, jQuery and 
trinidad friends a chance to plugin concurrent implementations and 
provide performance tests or other advantages their implemetations 
mights have.

2. The listeners are definitely a huge plus against the current spec. 
They remove the need for most of the additional attributes described in 
MYFACES-2174. Here are the ones that would still be needed: queuesize, 
errorlevel and submit. Having them in a subarray myfaces:{queuesize: 
(int), errorlevel (warning/error/fatal), submit (componentIds)} will 
clarify on that this is beyond the specs. We'll need to extend the 
adapter interface to pass the options array. I'll update MYFACES.2174 on 
this. For the other options it would be nice to provide a wrapper 
function that accepts disable, loadingbar and postcallback parameters. 
Which would be the correct place for this wrapper to go? Provide it 
together with the MyFaces core? Put it into tomahawk? Create a separate 
project, maybe even within J4Fry that releases a jar containing only 
this wrapper, so it can be used inside RI too?

3. Translantion of the comments must done.

I'll go for 1., 2. and 3. during the next few days.

Here's the 5%:

Why these namespace concerns? Isn't org.apache.myfaces the natural 
choice? How could this lead to namespace collisions? Actually myfaces.* 
is shorter, so it would be ok, too. Please clarify.

Currently I'm working on fixing the request queue, because in J4Fry we 
where only using a 1 element queue. Actually I'm missing a reasonable 
use case for a bigger AJAX request queue. Imagine a user typing letters 
in an input field with each letter queueing an AJAX request onKeyup. 
Now, the first request will submit immedately and the engine starts 
waiting for the callback. In the meantime the user types 5 more letters, 
each of them queueing another request. So, what whould happen, when the 
first request has returned? The 2nd request would now start collecting 
form values (cannot be done before, because state might have changed 
because of request 1), but the input field now already contains all 6 
letters the user has typed. Consequently, all 5 queued requests would 
submit the same values, thus producing 5 identical xhrs. Do you have an 
idea which szenario could be targeted with a queue size > 1?

Best Regards,
Ganesh

Werner Punz schrieb:
> Ok I have checked the j4fry code.
> So far it looks pretty good to me, well documented and clean and has 
> worked around a few pitfalls, however some things have to be changed.
>
> I personally would recommend to move the connection between jsf2.js and
> the j4fry code into an adapter class, like I did with my code.
>
> The reason is, the adapter class is needed to isolate jsf2 specifics 
> from the underlying implementation details. Stuff like progress 
> displays or invalidation of controls and custom options,
> should be handled within the adapters as long as they are not specified
> explicitely.
>
> The adapter also can isolate jsf2 from the underlying transport and 
> ppr mechanisms to a certain degree and allows other frameworks to 
> exchange the transports if the need arises!
> (which again would give us an advantage over the RI which has 
> everything hardcoded into one big class)
>
> So the calling hierarchy is jsf2 api <-> framework adapter with a 
> clear well defined interface <-> implementation
>
> This also allows us to exchange the underlying frameworks with a 
> simple switch (like I did for Trinidad and my own implementation)
> The implementation can call back into jsf2 (it should not if possible
> the adapter should) but jsf2 should not call directly into the 
> implementation it should call the adapter!
>
> Also not found in the public specs but in the latest ri is a listener
> mechanism which notifies the listeners in various stages of the 
> lifecycle, I assume since the RI has them as public APIs that those 
> are in later non public specs. I implemented those for exactly this 
> reason, you basically can copy paste it from me.
>
> Also for the J4Fry specific additonal options, can anyone check in the 
> latest specs if frameworks are allowed to offer additional 
> functionality via custom options?
>
> Those should be moved into one single submap under the myfaces 
> namespace to avoid namespace collissions with public options set by 
> the user!
> Those can be processed and mapped on adapter level, I guess!
>
> So far my first comments on the j4fry code :-)
>
> And last but not least: Namespaces they should be moved over to the 
> myfaces umbrella, and the comments have to be translated to english.
>
>
> And please don´t get me wrong, the code quality is excellent! I really 
> like what I have seen so far...
>

MyFaces 2.0 J4Fry first comments

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

Ok I have checked the j4fry code.
So far it looks pretty good to me, well documented and clean and has 
worked around a few pitfalls, however some things have to be changed.

I personally would recommend to move the connection between jsf2.js and
the j4fry code into an adapter class, like I did with my code.

The reason is, the adapter class is needed to isolate jsf2 specifics 
from the underlying implementation details. Stuff like progress displays 
or invalidation of controls and custom options,
should be handled within the adapters as long as they are not specified
explicitely.

The adapter also can isolate jsf2 from the underlying transport and ppr 
mechanisms to a certain degree and allows other frameworks to exchange 
the transports if the need arises!
(which again would give us an advantage over the RI which has everything 
hardcoded into one big class)

So the calling hierarchy is jsf2 api <-> framework adapter with a clear 
well defined interface <-> implementation

This also allows us to exchange the underlying frameworks with a simple 
switch (like I did for Trinidad and my own implementation)
The implementation can call back into jsf2 (it should not if possible
the adapter should) but jsf2 should not call directly into the 
implementation it should call the adapter!

Also not found in the public specs but in the latest ri is a listener
mechanism which notifies the listeners in various stages of the 
lifecycle, I assume since the RI has them as public APIs that those are 
in later non public specs. I implemented those for exactly this reason, 
you basically can copy paste it from me.

Also for the J4Fry specific additonal options, can anyone check in the 
latest specs if frameworks are allowed to offer additional functionality 
via custom options?

Those should be moved into one single submap under the myfaces namespace 
to avoid namespace collissions with public options set by the user!
Those can be processed and mapped on adapter level, I guess!

So far my first comments on the j4fry code :-)

And last but not least: Namespaces they should be moved over to the 
myfaces umbrella, and the comments have to be translated to english.


And please don´t get me wrong, the code quality is excellent! I really 
like what I have seen so far...

Re: MyFaces 2.0 AJAX development path

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

+1 on the wiki, great idea!

On Thu, Apr 2, 2009 at 12:27 AM, Andrew Robinson
<an...@gmail.com> wrote:
> I have a different suggestion.
>
> Each proponent(s) of a 3rd party AJAX solution, create a WIKI page on the
> apache website with PROS and CONS for that library. In that WIKI, include a
> gap analysis of the library vs. the JSF2 spec. requirements. Also mention
> speed performance and download performance (size) and also flexibility and
> maintainability.
>
> Then once these WIKIs are complete enough, the dev@ community can use them
> as a discussion point on one or another. I just think an email thread for
> this is not the right solution until the full picture is seen for each
> library.
>
> I'm surprised no one has mentioned jQuery since Dojo keeps getting
> mentioned, as jQuery currently has some of the fastest performing code for
> XPath-like page lookups. Not to mention jQuery is 19KB where Dojo is 80KB
>
> -Andrew
>
> On Wed, Apr 1, 2009 at 3:31 PM, Ganesh <ga...@j4fry.org> wrote:
>>
>> Hi,
>>
>> I'm sorry if I was sounding "hot". It's just that I'd really love the JSF
>> AJAX code we've been crafting and refining for years at J4Fry to go into
>> MyFaces and I think there are reasonable arguments for this. I'm only trying
>> to bring them forward with the hope of convincing everyone ;-)
>>
>> Dojo code is cool and it's hype, so if there is anything we can use from
>> it that'll be great. License is probably a minor issue here. What exactly do
>> you mean: "transport and logging layer"?
>>
>> My understanding of transport is that it is hardly more that instantiating
>> an xmlhttprequest and queueing the callback. I'm afraid "crossporting" the
>> dojo code wouldn't do a great deal of change to the code as it's pretty much
>> the same in many AJAX implementations including J4Fry and trinidad (please
>> correct me of the parts if I'm overseeing here).
>>
>> The logging part in dojo in really good - but it depends on firebug! Would
>> you want to include firebug lite with MyFaces??? I'm not quite sure of the
>> size of it and it certainly needs lots of improvement and bugfixing and the
>> state we put into MyFaces would be frozen - we would need to crossport new
>> releases as they evolve.
>>
>> As you see there are several doubts on my side, but I would be happy if
>> you enlightened me in understanding the exact meaning of what you where
>> suggesting.
>>
>> Best Regards,
>> Ganesh
>>
>>
>>
>> Werner Punz schrieb:
>>>
>>> Cool down guys :-)
>>> No seriously I have stated already why I personally would
>>> prefer not to get a direct dojo dependency into the myfaces core.
>>> However, I am fine with having ported useful code over from Dojo
>>> into the core.
>>>
>>> So my proposal is following:
>>>
>>> -1 to a dojo dependency in the myfaces core. I personally thing
>>> the dojo dependency in Tomahawk was evil enough and I am still working on
>>> getting it out into a separate component lib!
>>>
>>> Also the namespace in the core must be under the core javax and myfaces
>>> namespaces no external namespaces should be allowed to avoid namespace
>>> clashes. The namespacing also should follow the jsf2 conventions of using
>>> maps and using the openajax api!
>>>
>>> +1 if someone finds something useful we can take it from the dojo core
>>> lib
>>> but must adhere to the dojo license (license.txt with the dojo bsd
>>> license and references in the code should be suffice)
>>>
>>> Can anyone live with that? I personally for instance would love to have
>>> the dojo transport and logging layer being isolated out of dojo to be reused
>>> that stuff simply is phantastic but with a full dojo dependency for me this
>>> would be a no go...
>>>
>>> As I said I am not very much in favor of a full dojo dependency although
>>> I personally love dojo.
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>>
>>> Ganesh schrieb:
>>>>
>>>> Hi Michael,
>>>>
>>>> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
>>>> JSF solution from scratch I would certainly do this based on Dojo. I'm
>>>> currently making up some Facelets templates for Dojo JSF integration
>>>> (just a playground:
>>>> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
>>>> it's great fun! It's also good to hear that there are more people
>>>> willing to help with the MyFaces 2.0 AJAX.
>>>>
>>>> I think the primary problem is not doing some xhr in a queue and
>>>> processing of the callbacks. This has become standard stuff Trinidad and
>>>> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
>>>> is the way that J4Fry AJAX is integrated with JSF from scratch. In
>>>> detail there is:
>>>>
>>>>   * JSF ViewState processing
>>>>   * Component oriented processing of the HTML replacements
>>>>   * Submit parameters that trigger invoke application and render
>>>>     response phases
>>>>   * Parameters beyond the scope of the spec for PPS and several
>>>>     further features crucial for a good JSF AJAX experience
>>>>   * Javascript code is already ported to JSF 2.0 and has been tested
>>>>     against RI 2.0
>>>>   * Java code for server side processing has been running with JSF 1.2
>>>>     for a long time and waits for the JSF 2.0 port
>>>>   * JSR 168 portlet support
>>>>
>>>> I've also opened a jira for a list of features for JSF integration that
>>>> go far beyond the spec. These features weren't just implemented for JSF 2.0,
>>>> they have been productive in high performance business critical
>>>> applications for years.
>>>>
>>>> Implementing all of this from scratch based on dojo xhr is surely
>>>> possible, but it would probably take time to reach the necessary code
>>>> quality.
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>> Michael Concini schrieb:
>>>>>
>>>>> Sorry I'm a little late to the discussion here, but I'm a little
>>>>> concerned with the direction here.  I'm not very familiar with the
>>>>> advantages or disadvantages of J4Fry, but I do know that we're not familiar
>>>>> with the state of the J4Fry code.  We do know Dojo is a mature release with
>>>>> top level performance and accessibility features.  In addition, Dojo is a
>>>>> very well known framework with a large and dedicated developer community
>>>>> surrounding it.  What does J4Fry offer that Dojo cannot?
>>>>>
>>>>> If the concern is developer resources, we have a team of developers at
>>>>> IBM who are very active in the Dojo community and who have offered their
>>>>> assistance to my team in porting the necessary code to MyFaces.  The license
>>>>> is really not a concern, as Dojo code is already being included in at least
>>>>> Apache project.  As long as you mention in your code comments that the code
>>>>> was ported from Dojo under the BSD license you shouldn't need to do anything
>>>>> else.
>>>>> I think it would be worthwhile to have a discussion among the community
>>>>> about which framework would be best to utilize going forward.
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>> Ganesh wrote:
>>>>>>
>>>>>> 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"
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 3. Dojo cross-port:
>>>>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> In my understanding of the code it consists of 4 major parts:
>>>>>> - Trinidad RequestQueue
>>>>>> - Dojo Javascript fiddling
>>>>>> - OpenAjax
>>>>>> - JSF2.0 spec. impl. parts
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> My other point is: Why do you use a servlet for testing? We could use
>>>>>> the RI to test the Javascript against and then move to the Java part
>>>>>> with pretested Javascript. This way we would also ensure full
>>>>>> compatibility of the XML formats used by both implementations. The
>>>>>> only
>>>>>> point one could make is about size. If the RI's XML format turns out
>>>>>> to
>>>>>> be quite talkative we could think about using a more performant
>>>>>> format.
>>>>>> For this reason J4Fry was originally using JSON but the spec
>>>>>> explicitly
>>>>>> dictates the use of XML here (god knows why ...). What do you think?
>>>>>>
>>>>>> Best Regards,
>>>>>> Ganesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>



-- 
Matthias Wessendorf

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

Re: MyFaces 2.0 AJAX development path

[Andrew Robinson <an...@gmail.com>]

I have a different suggestion.

Each proponent(s) of a 3rd party AJAX solution, create a WIKI page on the
apache website with PROS and CONS for that library. In that WIKI, include a
gap analysis of the library vs. the JSF2 spec. requirements. Also mention
speed performance and download performance (size) and also flexibility and
maintainability.

Then once these WIKIs are complete enough, the dev@ community can use them
as a discussion point on one or another. I just think an email thread for
this is not the right solution until the full picture is seen for each
library.

I'm surprised no one has mentioned jQuery since Dojo keeps getting
mentioned, as jQuery currently has some of the fastest performing code for
XPath-like page lookups. Not to mention jQuery is 19KB where Dojo is 80KB

-Andrew

On Wed, Apr 1, 2009 at 3:31 PM, Ganesh <ga...@j4fry.org> wrote:

> Hi,
>
> I'm sorry if I was sounding "hot". It's just that I'd really love the JSF
> AJAX code we've been crafting and refining for years at J4Fry to go into
> MyFaces and I think there are reasonable arguments for this. I'm only trying
> to bring them forward with the hope of convincing everyone ;-)
>
> Dojo code is cool and it's hype, so if there is anything we can use from it
> that'll be great. License is probably a minor issue here. What exactly do
> you mean: "transport and logging layer"?
>
> My understanding of transport is that it is hardly more that instantiating
> an xmlhttprequest and queueing the callback. I'm afraid "crossporting" the
> dojo code wouldn't do a great deal of change to the code as it's pretty much
> the same in many AJAX implementations including J4Fry and trinidad (please
> correct me of the parts if I'm overseeing here).
>
> The logging part in dojo in really good - but it depends on firebug! Would
> you want to include firebug lite with MyFaces??? I'm not quite sure of the
> size of it and it certainly needs lots of improvement and bugfixing and the
> state we put into MyFaces would be frozen - we would need to crossport new
> releases as they evolve.
>
> As you see there are several doubts on my side, but I would be happy if you
> enlightened me in understanding the exact meaning of what you where
> suggesting.
>
> Best Regards,
> Ganesh
>
>
>
> Werner Punz schrieb:
>
>  Cool down guys :-)
>> No seriously I have stated already why I personally would
>> prefer not to get a direct dojo dependency into the myfaces core.
>> However, I am fine with having ported useful code over from Dojo
>> into the core.
>>
>> So my proposal is following:
>>
>> -1 to a dojo dependency in the myfaces core. I personally thing
>> the dojo dependency in Tomahawk was evil enough and I am still working on
>> getting it out into a separate component lib!
>>
>> Also the namespace in the core must be under the core javax and myfaces
>> namespaces no external namespaces should be allowed to avoid namespace
>> clashes. The namespacing also should follow the jsf2 conventions of using
>> maps and using the openajax api!
>>
>> +1 if someone finds something useful we can take it from the dojo core lib
>> but must adhere to the dojo license (license.txt with the dojo bsd license
>> and references in the code should be suffice)
>>
>> Can anyone live with that? I personally for instance would love to have
>> the dojo transport and logging layer being isolated out of dojo to be reused
>> that stuff simply is phantastic but with a full dojo dependency for me this
>> would be a no go...
>>
>> As I said I am not very much in favor of a full dojo dependency although I
>> personally love dojo.
>>
>>
>>
>> Werner
>>
>>
>>
>>
>> Ganesh schrieb:
>>
>>> Hi Michael,
>>>
>>> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
>>> JSF solution from scratch I would certainly do this based on Dojo. I'm
>>> currently making up some Facelets templates for Dojo JSF integration
>>> (just a playground:
>>> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
>>> it's great fun! It's also good to hear that there are more people
>>> willing to help with the MyFaces 2.0 AJAX.
>>>
>>> I think the primary problem is not doing some xhr in a queue and
>>> processing of the callbacks. This has become standard stuff Trinidad and
>>> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
>>> is the way that J4Fry AJAX is integrated with JSF from scratch. In
>>> detail there is:
>>>
>>>   * JSF ViewState processing
>>>   * Component oriented processing of the HTML replacements
>>>   * Submit parameters that trigger invoke application and render
>>>     response phases
>>>   * Parameters beyond the scope of the spec for PPS and several
>>>     further features crucial for a good JSF AJAX experience
>>>   * Javascript code is already ported to JSF 2.0 and has been tested
>>>     against RI 2.0
>>>   * Java code for server side processing has been running with JSF 1.2
>>>     for a long time and waits for the JSF 2.0 port
>>>   * JSR 168 portlet support
>>>
>>> I've also opened a jira for a list of features for JSF integration that
>>> go far beyond the spec. These features weren't just implemented for JSF 2.0,
>>> they have been productive in high performance business critical
>>> applications for years.
>>>
>>> Implementing all of this from scratch based on dojo xhr is surely
>>> possible, but it would probably take time to reach the necessary code
>>> quality.
>>>
>>> Best Regards,
>>> Ganesh
>>>
>>> Michael Concini schrieb:
>>>
>>>> Sorry I'm a little late to the discussion here, but I'm a little
>>>> concerned with the direction here.  I'm not very familiar with the
>>>> advantages or disadvantages of J4Fry, but I do know that we're not familiar
>>>> with the state of the J4Fry code.  We do know Dojo is a mature release with
>>>> top level performance and accessibility features.  In addition, Dojo is a
>>>> very well known framework with a large and dedicated developer community
>>>> surrounding it.  What does J4Fry offer that Dojo cannot?
>>>>
>>>> If the concern is developer resources, we have a team of developers at
>>>> IBM who are very active in the Dojo community and who have offered their
>>>> assistance to my team in porting the necessary code to MyFaces.  The license
>>>> is really not a concern, as Dojo code is already being included in at least
>>>> Apache project.  As long as you mention in your code comments that the code
>>>> was ported from Dojo under the BSD license you shouldn't need to do anything
>>>> else.
>>>> I think it would be worthwhile to have a discussion among the community
>>>> about which framework would be best to utilize going forward.
>>>>
>>>> Thanks,
>>>> Mike
>>>>
>>>> Ganesh wrote:
>>>>
>>>>> 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"
>>>>>
>>>>> 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.
>>>>>
>>>>> 3. Dojo cross-port:
>>>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> In my understanding of the code it consists of 4 major parts:
>>>>> - Trinidad RequestQueue
>>>>> - Dojo Javascript fiddling
>>>>> - OpenAjax
>>>>> - JSF2.0 spec. impl. parts
>>>>>
>>>>> 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.
>>>>>
>>>>> My other point is: Why do you use a servlet for testing? We could use
>>>>> the RI to test the Javascript against and then move to the Java part
>>>>> with pretested Javascript. This way we would also ensure full
>>>>> compatibility of the XML formats used by both implementations. The only
>>>>> point one could make is about size. If the RI's XML format turns out to
>>>>> be quite talkative we could think about using a more performant format.
>>>>> For this reason J4Fry was originally using JSON but the spec explicitly
>>>>> dictates the use of XML here (god knows why ...). What do you think?
>>>>>
>>>>> Best Regards,
>>>>> Ganesh
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>

Re: MyFaces 2.0 AJAX development path

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

Ok to make this thread endless.

I have spending the last hours going over the codebase over mine and 
over the RI.

First the good news, the RI has not changed significantly in the last 2 
months, so I assume the JSF API is stable.

To the semi "bad" news:

After looking at everything, I personally would prefer not to use J4Fry 
entirely as base but use a merged approach from my code and j4frys.

I will give a reason:

a) J4Fry has a lot of stuff in the core which ultimately is better used 
in listeners (the entire disabling of elements, showing progress 
indicators). So moving this entire code out into listeners probably has 
to be performed anyway.

b) I did a lot of fine grained work regarding the compatibility to the 
RI especially in detail areas not fully covered by the spec (context
handling, pass through parameters, detail adjustment in which paramaters 
have been moved out of the options and are not dragged into the pass 
through params)

c) The entire response ppr handling is specified in the ri and probably 
in the spec as is and cannot be altered, hence this probably must be 
covered in jsf.js anyway so we have to move that over or have to write 
parts from scratch to cover the specs!

In the end I have a small isolated xhr layer which itself has 160 locs 
including blanks and comments easily maintainable and fixable with a 
fully working queue integrated.

If we strip all the mentioned things from j4fry and move them into 
listeners and jsf.js we probably end up with a similar core but a tad 
bigger due to bigger abstractions (for me the queue for instance is part 
of the transport and the entire queue just is an array!)
But with more work because on one hand we just would rip out the code 
needed on the other we have to rework an entire framework core!

So here is my proposal, we stay at my mini core for now (unless there 
are serious arguments to drop it) for the xhr aspects but fix things I 
might have missed and add some functionality, like being able to limit 
the queue size.

Outside of the core implementation we add the listeners, which currently 
are in the core functionalitywise to get the disabling enabling and 
progressor visualisation in (sort of as a goody addon from myfaces)

We try go get as much from the response handler from j4fry for our own 
ppr response handler to minimize work on that part (I wanted to start 
with that one as next step anyway). There are probably a lot of things 
in j4fry we can reuse.

So in the end it will be a merged codebase from the better parts of both 
codebases..

And in the end we can all work on this, I would love to have others also 
doing stuff in this area not only entirely me!


Werner


Werner Punz schrieb:
> Ganesh schrieb:
> Actually it was more along the lines of examples
> of what we could reuse from dojo!
> 
>> My understanding of transport is that it is hardly more that 
>> instantiating an xmlhttprequest and queueing the callback. I'm afraid 
>> "crossporting" the dojo code wouldn't do a great deal of change to the 
>> code as it's pretty much the same in many AJAX implementations 
>> including J4Fry and trinidad (please correct me of the parts if I'm 
>> overseeing here).
>>
> Yes I assume so, I personally just find the way the dojo people have 
> isolated the transport  excellent with their xhrRequest objects
> and callback functions cleanly isolated and easy to use. It is not an 
> order that we should integrated it :-)
> 
> But I checked out the transport layer a while ago, because I wanted to 
> reuse it, and that one was pretty hard to rip out! There are so many 
> dependencies into dojo that
> it probably is harder to rip that out than to program your own transport 
> layer on top of xmlhttprequest :-)
> 
> 
> 
>> The logging part in dojo in really good - but it depends on firebug! 
>> Would you want to include firebug lite with MyFaces??? I'm not quite 
>> sure of the size of it and it certainly needs lots of improvement and 
>> bugfixing and the state we put into MyFaces would be frozen - we would 
>> need to crossport new releases as they evolve.
>>
> You probably are right there, I was not too deep into the API again this 
> was just an example of a dojo part which might be useful for us :-)
> A small logging api itself is a no brainer and can be done within a 
> short period of time (i did it in my code as well, with hooks into 
> console if present if not doing something else)
> 
> 

Re: MyFaces 2.0 AJAX development path

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

Ganesh schrieb:
Actually it was more along the lines of examples
of what we could reuse from dojo!

> My understanding of transport is that it is hardly more that 
> instantiating an xmlhttprequest and queueing the callback. I'm afraid 
> "crossporting" the dojo code wouldn't do a great deal of change to the 
> code as it's pretty much the same in many AJAX implementations including 
> J4Fry and trinidad (please correct me of the parts if I'm overseeing here).
> 
Yes I assume so, I personally just find the way the dojo people have 
isolated the transport  excellent with their xhrRequest objects
and callback functions cleanly isolated and easy to use. It is not an 
order that we should integrated it :-)

But I checked out the transport layer a while ago, because I wanted to 
reuse it, and that one was pretty hard to rip out! There are so many 
dependencies into dojo that
it probably is harder to rip that out than to program your own transport 
layer on top of xmlhttprequest :-)



> The logging part in dojo in really good - but it depends on firebug! 
> Would you want to include firebug lite with MyFaces??? I'm not quite 
> sure of the size of it and it certainly needs lots of improvement and 
> bugfixing and the state we put into MyFaces would be frozen - we would 
> need to crossport new releases as they evolve.
> 
You probably are right there, I was not too deep into the API again this 
was just an example of a dojo part which might be useful for us :-)
A small logging api itself is a no brainer and can be done within a 
short period of time (i did it in my code as well, with hooks into 
console if present if not doing something else)

Re: MyFaces 2.0 AJAX development path

[Ganesh <ga...@j4fry.org>]

Hi,

I'm sorry if I was sounding "hot". It's just that I'd really love the 
JSF AJAX code we've been crafting and refining for years at J4Fry to go 
into MyFaces and I think there are reasonable arguments for this. I'm 
only trying to bring them forward with the hope of convincing everyone ;-)

Dojo code is cool and it's hype, so if there is anything we can use from 
it that'll be great. License is probably a minor issue here. What 
exactly do you mean: "transport and logging layer"?

My understanding of transport is that it is hardly more that 
instantiating an xmlhttprequest and queueing the callback. I'm afraid 
"crossporting" the dojo code wouldn't do a great deal of change to the 
code as it's pretty much the same in many AJAX implementations including 
J4Fry and trinidad (please correct me of the parts if I'm overseeing here).

The logging part in dojo in really good - but it depends on firebug! 
Would you want to include firebug lite with MyFaces??? I'm not quite 
sure of the size of it and it certainly needs lots of improvement and 
bugfixing and the state we put into MyFaces would be frozen - we would 
need to crossport new releases as they evolve.

As you see there are several doubts on my side, but I would be happy if 
you enlightened me in understanding the exact meaning of what you where 
suggesting.

Best Regards,
Ganesh



Werner Punz schrieb:
> Cool down guys :-)
> No seriously I have stated already why I personally would
> prefer not to get a direct dojo dependency into the myfaces core.
> However, I am fine with having ported useful code over from Dojo
> into the core.
>
> So my proposal is following:
>
> -1 to a dojo dependency in the myfaces core. I personally thing
> the dojo dependency in Tomahawk was evil enough and I am still working 
> on getting it out into a separate component lib!
>
> Also the namespace in the core must be under the core javax and 
> myfaces namespaces no external namespaces should be allowed to avoid 
> namespace clashes. The namespacing also should follow the jsf2 
> conventions of using maps and using the openajax api!
>
> +1 if someone finds something useful we can take it from the dojo core 
> lib
> but must adhere to the dojo license (license.txt with the dojo bsd 
> license and references in the code should be suffice)
>
> Can anyone live with that? I personally for instance would love to 
> have the dojo transport and logging layer being isolated out of dojo 
> to be reused that stuff simply is phantastic but with a full dojo 
> dependency for me this would be a no go...
>
> As I said I am not very much in favor of a full dojo dependency 
> although I personally love dojo.
>
>
>
> Werner
>
>
>
>
> Ganesh schrieb:
>> Hi Michael,
>>
>> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
>> JSF solution from scratch I would certainly do this based on Dojo. I'm
>> currently making up some Facelets templates for Dojo JSF integration
>> (just a playground: 
>> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
>> it's great fun! It's also good to hear that there are more people
>> willing to help with the MyFaces 2.0 AJAX.
>>
>> I think the primary problem is not doing some xhr in a queue and
>> processing of the callbacks. This has become standard stuff Trinidad and
>> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
>> is the way that J4Fry AJAX is integrated with JSF from scratch. In
>> detail there is:
>>
>>    * JSF ViewState processing
>>    * Component oriented processing of the HTML replacements
>>    * Submit parameters that trigger invoke application and render
>>      response phases
>>    * Parameters beyond the scope of the spec for PPS and several
>>      further features crucial for a good JSF AJAX experience
>>    * Javascript code is already ported to JSF 2.0 and has been tested
>>      against RI 2.0
>>    * Java code for server side processing has been running with JSF 1.2
>>      for a long time and waits for the JSF 2.0 port
>>    * JSR 168 portlet support
>>
>> I've also opened a jira for a list of features for JSF integration 
>> that go far beyond the spec. These features weren't just implemented 
>> for JSF 2.0, they have been productive in high performance business 
>> critical
>> applications for years.
>>
>> Implementing all of this from scratch based on dojo xhr is surely 
>> possible, but it would probably take time to reach the necessary code 
>> quality.
>>
>> Best Regards,
>> Ganesh
>>
>> Michael Concini schrieb:
>>> Sorry I'm a little late to the discussion here, but I'm a little 
>>> concerned with the direction here.  I'm not very familiar with the 
>>> advantages or disadvantages of J4Fry, but I do know that we're not 
>>> familiar with the state of the J4Fry code.  We do know Dojo is a 
>>> mature release with top level performance and accessibility 
>>> features.  In addition, Dojo is a very well known framework with a 
>>> large and dedicated developer community surrounding it.  What does 
>>> J4Fry offer that Dojo cannot?
>>>
>>> If the concern is developer resources, we have a team of developers 
>>> at IBM who are very active in the Dojo community and who have 
>>> offered their assistance to my team in porting the necessary code to 
>>> MyFaces.  The license is really not a concern, as Dojo code is 
>>> already being included in at least Apache project.  As long as you 
>>> mention in your code comments that the code was ported from Dojo 
>>> under the BSD license you shouldn't need to do anything else.
>>> I think it would be worthwhile to have a discussion among the 
>>> community about which framework would be best to utilize going forward.
>>>
>>> Thanks,
>>> Mike
>>>
>>> Ganesh wrote:
>>>> 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"
>>>>
>>>> 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.
>>>>
>>>> 3. Dojo cross-port:
>>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>>
>>>> 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.
>>>>
>>>> In my understanding of the code it consists of 4 major parts:
>>>> - Trinidad RequestQueue
>>>> - Dojo Javascript fiddling
>>>> - OpenAjax
>>>> - JSF2.0 spec. impl. parts
>>>>
>>>> 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.
>>>>
>>>> My other point is: Why do you use a servlet for testing? We could use
>>>> the RI to test the Javascript against and then move to the Java part
>>>> with pretested Javascript. This way we would also ensure full
>>>> compatibility of the XML formats used by both implementations. The 
>>>> only
>>>> point one could make is about size. If the RI's XML format turns 
>>>> out to
>>>> be quite talkative we could think about using a more performant 
>>>> format.
>>>> For this reason J4Fry was originally using JSON but the spec 
>>>> explicitly
>>>> dictates the use of XML here (god knows why ...). What do you think?
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>>
>>>
>>
>>
>

Re: MyFaces 2.0 AJAX development path

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

Cool down guys :-)
No seriously I have stated already why I personally would
prefer not to get a direct dojo dependency into the myfaces core.
However, I am fine with having ported useful code over from Dojo
into the core.

So my proposal is following:

-1 to a dojo dependency in the myfaces core. I personally thing
the dojo dependency in Tomahawk was evil enough and I am still working 
on getting it out into a separate component lib!

Also the namespace in the core must be under the core javax and myfaces 
namespaces no external namespaces should be allowed to avoid namespace 
clashes. The namespacing also should follow the jsf2 conventions of 
using maps and using the openajax api!

+1 if someone finds something useful we can take it from the dojo core lib
but must adhere to the dojo license (license.txt with the dojo bsd 
license and references in the code should be suffice)

Can anyone live with that? I personally for instance would love to have 
the dojo transport and logging layer being isolated out of dojo to be 
reused that stuff simply is phantastic but with a full dojo dependency 
for me this would be a no go...

As I said I am not very much in favor of a full dojo dependency although 
I personally love dojo.



Werner




Ganesh schrieb:
> Hi Michael,
> 
> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
> JSF solution from scratch I would certainly do this based on Dojo. I'm
> currently making up some Facelets templates for Dojo JSF integration
> (just a playground: 
> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
> it's great fun! It's also good to hear that there are more people
> willing to help with the MyFaces 2.0 AJAX.
> 
> I think the primary problem is not doing some xhr in a queue and
> processing of the callbacks. This has become standard stuff Trinidad and
> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
> is the way that J4Fry AJAX is integrated with JSF from scratch. In
> detail there is:
> 
>    * JSF ViewState processing
>    * Component oriented processing of the HTML replacements
>    * Submit parameters that trigger invoke application and render
>      response phases
>    * Parameters beyond the scope of the spec for PPS and several
>      further features crucial for a good JSF AJAX experience
>    * Javascript code is already ported to JSF 2.0 and has been tested
>      against RI 2.0
>    * Java code for server side processing has been running with JSF 1.2
>      for a long time and waits for the JSF 2.0 port
>    * JSR 168 portlet support
> 
> I've also opened a jira for a list of features for JSF integration that 
> go far beyond the spec. These features weren't just implemented for JSF 
> 2.0, they have been productive in high performance business critical
> applications for years.
> 
> Implementing all of this from scratch based on dojo xhr is surely 
> possible, but it would probably take time to reach the necessary code 
> quality.
> 
> Best Regards,
> Ganesh
> 
> Michael Concini schrieb:
>> Sorry I'm a little late to the discussion here, but I'm a little 
>> concerned with the direction here.  I'm not very familiar with the 
>> advantages or disadvantages of J4Fry, but I do know that we're not 
>> familiar with the state of the J4Fry code.  We do know Dojo is a 
>> mature release with top level performance and accessibility features.  
>> In addition, Dojo is a very well known framework with a large and 
>> dedicated developer community surrounding it.  What does J4Fry offer 
>> that Dojo cannot?
>>
>> If the concern is developer resources, we have a team of developers at 
>> IBM who are very active in the Dojo community and who have offered 
>> their assistance to my team in porting the necessary code to MyFaces.  
>> The license is really not a concern, as Dojo code is already being 
>> included in at least Apache project.  As long as you mention in your 
>> code comments that the code was ported from Dojo under the BSD license 
>> you shouldn't need to do anything else.
>> I think it would be worthwhile to have a discussion among the 
>> community about which framework would be best to utilize going forward.
>>
>> Thanks,
>> Mike
>>
>> Ganesh wrote:
>>> 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"
>>>
>>> 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.
>>>
>>> 3. Dojo cross-port:
>>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>>
>>> 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.
>>>
>>> In my understanding of the code it consists of 4 major parts:
>>> - Trinidad RequestQueue
>>> - Dojo Javascript fiddling
>>> - OpenAjax
>>> - JSF2.0 spec. impl. parts
>>>
>>> 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.
>>>
>>> My other point is: Why do you use a servlet for testing? We could use
>>> the RI to test the Javascript against and then move to the Java part
>>> with pretested Javascript. This way we would also ensure full
>>> compatibility of the XML formats used by both implementations. The only
>>> point one could make is about size. If the RI's XML format turns out to
>>> be quite talkative we could think about using a more performant format.
>>> For this reason J4Fry was originally using JSON but the spec explicitly
>>> dictates the use of XML here (god knows why ...). What do you think?
>>>
>>> Best Regards,
>>> Ganesh
>>>
>>>
>>
> 
> 

Re: MyFaces 2.0 AJAX development path

[Ganesh <ga...@j4fry.org>]

Hi Michael,

Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX
JSF solution from scratch I would certainly do this based on Dojo. I'm
currently making up some Facelets templates for Dojo JSF integration
(just a playground: 
http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and
it's great fun! It's also good to hear that there are more people
willing to help with the MyFaces 2.0 AJAX.

I think the primary problem is not doing some xhr in a queue and
processing of the callbacks. This has become standard stuff Trinidad and
Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference
is the way that J4Fry AJAX is integrated with JSF from scratch. In
detail there is:

    * JSF ViewState processing
    * Component oriented processing of the HTML replacements
    * Submit parameters that trigger invoke application and render
      response phases
    * Parameters beyond the scope of the spec for PPS and several
      further features crucial for a good JSF AJAX experience
    * Javascript code is already ported to JSF 2.0 and has been tested
      against RI 2.0
    * Java code for server side processing has been running with JSF 1.2
      for a long time and waits for the JSF 2.0 port
    * JSR 168 portlet support

I've also opened a jira for a list of features for JSF integration that 
go far beyond the spec. These features weren't just implemented for JSF 
2.0, they have been productive in high performance business critical
applications for years.

Implementing all of this from scratch based on dojo xhr is surely 
possible, but it would probably take time to reach the necessary code 
quality.

Best Regards,
Ganesh

Michael Concini schrieb:
> Sorry I'm a little late to the discussion here, but I'm a little 
> concerned with the direction here.  I'm not very familiar with the 
> advantages or disadvantages of J4Fry, but I do know that we're not 
> familiar with the state of the J4Fry code.  We do know Dojo is a 
> mature release with top level performance and accessibility features.  
> In addition, Dojo is a very well known framework with a large and 
> dedicated developer community surrounding it.  What does J4Fry offer 
> that Dojo cannot?
>
> If the concern is developer resources, we have a team of developers at 
> IBM who are very active in the Dojo community and who have offered 
> their assistance to my team in porting the necessary code to MyFaces.  
> The license is really not a concern, as Dojo code is already being 
> included in at least Apache project.  As long as you mention in your 
> code comments that the code was ported from Dojo under the BSD license 
> you shouldn't need to do anything else.
> I think it would be worthwhile to have a discussion among the 
> community about which framework would be best to utilize going forward.
>
> Thanks,
> Mike
>
> Ganesh wrote:
>> 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"
>>
>> 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.
>>
>> 3. Dojo cross-port:
>> The JSF2Utils class consists mostly of copied Dojo code. 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.
>>
>> 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.
>>
>> In my understanding of the code it consists of 4 major parts:
>> - Trinidad RequestQueue
>> - Dojo Javascript fiddling
>> - OpenAjax
>> - JSF2.0 spec. impl. parts
>>
>> 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.
>>
>> My other point is: Why do you use a servlet for testing? We could use
>> the RI to test the Javascript against and then move to the Java part
>> with pretested Javascript. This way we would also ensure full
>> compatibility of the XML formats used by both implementations. The only
>> point one could make is about size. If the RI's XML format turns out to
>> be quite talkative we could think about using a more performant format.
>> For this reason J4Fry was originally using JSON but the spec explicitly
>> dictates the use of XML here (god knows why ...). What do you think?
>>
>> Best Regards,
>> Ganesh
>>
>>
>

Re: MyFaces 2.0 AJAX development path

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

Michael Concini schrieb:
> Sorry I'm a little late to the discussion here, but I'm a little 
> concerned with the direction here.  I'm not very familiar with the 
> advantages or disadvantages of J4Fry, but I do know that we're not 
> familiar with the state of the J4Fry code.  We do know Dojo is a mature 
> release with top level performance and accessibility features.  In 
> addition, Dojo is a very well known framework with a large and dedicated 
> developer community surrounding it.  What does J4Fry offer that Dojo 
> cannot?
> 
> If the concern is developer resources, we have a team of developers at 
> IBM who are very active in the Dojo community and who have offered their 
> assistance to my team in porting the necessary code to MyFaces.  The 
> license is really not a concern, as Dojo code is already being included 
> in at least Apache project.  As long as you mention in your code 
> comments that the code was ported from Dojo under the BSD license you 
> shouldn't need to do anything else.
> I think it would be worthwhile to have a discussion among the community 
> about which framework would be best to utilize going forward.
> 

Sorry for jumping in late again, but the last days I was in "sickbay" 
with a flu.

Hello I also was working on an implementation as it seems, the J4Fry 
people have surpassed me in this regard, so I might drop my part and 
will take over from what I will get from the J4Fry people.

I have to check their code first and will probably do some adjustments!
Since I have not seen of what they have done so far, I will have to do a 
checkup once parts of their work are submitted into the jira!

But now for Dojo:

I am as well knee deep into Dojo, and my opinions especially regarding 
the Dojo core (the dijit widgets somewhat less due to bugs) is very 
high, but in my code I did not use it. Lets talk seriously about Dojo, 
and what it has to offer and where the problems are using it.

Dojo offers a lot, but is it really a good base for our implementation.
First of all we have a base library which means we should not introduce 
a dependency against another library widely used we have to map 
everything into the jsf namespace.
(I think dojo can remap namespaces but I have to recheck that)

The dojo core itself is 50kbyte compressed with a lot of things we do 
not need, what we would need mostly for jsf 2.0 is the dojo transport 
layer only, nothing else. It is hard to isolate that one out! The other 
thing is dojo.hitch, which can be ripped out (and is by me in the code I 
committed) and maybe the log layer!


The dojo ppr itself is a totally different issue, and mechanism, because 
it relies on parsing on the javascript side and frankly spoken, works 
entirely different to jsf.

JSF needs a ResponseWriter and a separate eval for the embedded scripts
while dojo relies on parsing of the client side tags regarding 
attributes, so we cannot recycle that one (which would be a huge benefit).

As for ppr and dojo, I dont see to many clashes here, the jsf namespace 
and dojo namespace are two different entities, so if we avoid that one
so mixing both things should be a no brainer.
(I did a ppr of dojo based components based on Trinidad, in my still due 
to time constraints not yet opensourced dojo components jsf project)

So what would speak for dojo:
a) a nice transport layer api which we could recycle
and some nice apis doing some isolation in the dom handling!

What would speak against dojo:

a) A moving target beyound our control with probable name clashes, 
unless we can remap the namespaces

b) 50 kbytes extra includes we have to drag along unless it is possible 
to isolate the transport only code (which is hard because dojo is so 
interwined with each other)


The probably best way to resolve all this might be to isolate the entire 
transport handling so that third party libraries can be plugged in, from 
the rest of the jsf2 spec we would not get too much support anyway!

Another thing could be we could isolate the parts of dojo we need and 
take them into our own code, which would make sense, but the isolation 
of code from the core itself is very hard and time consuming due to the 
intra function dependencies within the core!

But in the end keep in mind, keep things as small as possible, one 
reason why I tried to phase out the Trinidad code I used upfront in my 
first implementation trials, there were too many things in there which 
needed some cleanup and isolation and which we did not need in the first 
place!
But what we definitely have to achieve is to keep things clean and try 
to avoid any clashes into third party libs or sideeffects into them!

Ok just my 2c regarding the usage of dojo. As I said I can live with it 
but more along being able to hook another tansport adapter/provider 
instead of hooking it as dependency into the core!



Just my 2c...

Werner

Re: MyFaces 2.0 AJAX development path

[Michael Concini <mc...@gmail.com>]

Sorry I'm a little late to the discussion here, but I'm a little 
concerned with the direction here.  I'm not very familiar with the 
advantages or disadvantages of J4Fry, but I do know that we're not 
familiar with the state of the J4Fry code.  We do know Dojo is a mature 
release with top level performance and accessibility features.  In 
addition, Dojo is a very well known framework with a large and dedicated 
developer community surrounding it.  What does J4Fry offer that Dojo cannot?

If the concern is developer resources, we have a team of developers at 
IBM who are very active in the Dojo community and who have offered their 
assistance to my team in porting the necessary code to MyFaces.  The 
license is really not a concern, as Dojo code is already being included 
in at least Apache project.  As long as you mention in your code 
comments that the code was ported from Dojo under the BSD license you 
shouldn't need to do anything else. 

I think it would be worthwhile to have a discussion among the community 
about which framework would be best to utilize going forward.

Thanks,
Mike

Ganesh wrote:
> 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"
>
> 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.
>
> 3. Dojo cross-port:
> The JSF2Utils class consists mostly of copied Dojo code. 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.
>
> 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.
>
> In my understanding of the code it consists of 4 major parts:
> - Trinidad RequestQueue
> - Dojo Javascript fiddling
> - OpenAjax
> - JSF2.0 spec. impl. parts
>
> 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.
>
> My other point is: Why do you use a servlet for testing? We could use
> the RI to test the Javascript against and then move to the Java part
> with pretested Javascript. This way we would also ensure full
> compatibility of the XML formats used by both implementations. The only
> point one could make is about size. If the RI's XML format turns out to
> be quite talkative we could think about using a more performant format.
> For this reason J4Fry was originally using JSON but the spec explicitly
> dictates the use of XML here (god knows why ...). What do you think?
>
> Best Regards,
> Ganesh
>
>

Re: MyFaces 2.0 AJAX development path

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

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!

MyFaces 2.0 and javascript builder plugin

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

Hello everyone.

MyFaces 2.0 enforces a central jsf.js for all includes,
now my idea is to concatenate all files to a single js file and 
recompress them.
So far I have this working with the standard maven plugin which does it
(despite having had to workaround 1-2 bugs)
Now I have seen our builder tools also have a javascript plugin.

Now two questions:
Are our builder tools able to do the same, as it seems they do, but 
since this part lacks documentation entirely I have not yet figured out 
how to trigger them on a set of javascript files correctly.

Secondly, does it make sense to maintain our own builder tools
regarding javascript if maven itself has one in the sandbox?

Werner

Re: MyFaces 2.0 AJAX development path

[Ganesh <ga...@j4fry.org>]

Hi,

We're working on JS library that replaces RI's AJAX JS. Here's an 
example of the XML format they use to transport their partial responses. 
We'll make our JS compatible with this:

<?xml version="1.0" encoding="utf-8"?>
<partial-response>
    <changes>
        <update id="out1">
            <![CDATA[<span id="out1">6</span>]]>
        </update>
        <update id="javax.faces.ViewState">
            <![CDATA[j_id5:j_id7]]>
        </update>
    </changes>
</partial-response>

When building an AJAX example with JSF 2.0 RI I had to use Javascript 
that differed slightly from what is defined in the spec. I've documented 
the differences here: http://forums.sun.com/thread.jspa?threadID=5376889

Best Regards,
Ganesh