[jsr-314-open] AJAX library in JSF 2.0

[Werner Punz]

On Sun, Sep 27, 2009 at 9:09 PM, Jim Driscoll <Jim.Driscoll at sun.com> wrote:
> Hey Alexander:
>
> On 9/25/09 12:26 PM, Alexander Smirnov wrote:
>>
>> Our team just caught the problem with Mojarra implementation. Although
>> interaction with client-side code is encapsulated into AjaxBehavior
>> renderer, jsf.js library contains code that used by the some other
>> renderers from Jsf-impl.
>
> I'm not sure what you're referring to here: Do you mean the mojarra
> namespaced functions?  Those should be completely separate - that's why
> they're in a different namespace.  Putting them into a separate file has
> performance implications.  And if you think Mojarra's jsf.js file has other
> functions, check out MyFaces - they're much more agressive in breaking out
> functionality - an architecture that Mojarra will probably follow in the
> next rev as well.
>
Actually yes we are very modular, the reasons were threefold:
- First we wanted to keep the path to future extensions on the
transport part as open as possible
- Secondly, having done a load of work with dojo I simply prefer to
have javascript modular one way or the other (dojo does it in a more
aggressive manner than we do, because they also load the stuff
dynamically, optionally, while we bind our modules simply in the build
process)
- Third, when we started this we had some corporate users who wanted
to have Dojo as transport mechanism, although I like Dojo I preferred
not to introduce a dependency for a core library, but I wanted to keep
the path open for those users to replace the I/O transport layer,

So far the aggressive modularization worked out pretty well for us.

But given the state of the API as an external user I only would use
the module part if I knew that I would not switch at least the
scripts!

You nail yourself down to one implementation. My personal guess is
that the core API although it is very small (Thank god I prefer
minimalistic approaches over API clutter) it leaves enough flexibility
so that you can add your own extensions from the outside.


But as Jim Driscoll has stated if you provide such a thing as official
extension points in a dynamic language, it is hard to ensure that
two libraries do not add extensions which are incompatible to each other.
(Which is a non issue for now for us since the modular parts are in
impl only and not
part of the spec or api)

The only way I can see it is to either just add additional listeners or to
clearly specify the impl submodules and their interfaces and make them
delegatable
just like jsf does, or add some kind of chain patters which allow to plug users
their own implementations on top of the chain.

However we still cannot prevent that anyone does something nasty with
the runtime, this is javascript after all, but so no library can.
So there is a way to introduce more extension points, but we have to
be careful where and how.


> If you're interested, we could work together on a POC for this functionality
> that met the current spec.  We could add that into the next rev of the impl
> - that could fix it for you well before the next spec rev.
>
> We could coordinate that effort on the ajax sub-list.  At a minimum, Werner,
> Ted and Andy should also be watching what direction we head in, so we don't
> waste too much time going down a road that they disapprove of.
>
I´m in if you guys want me as a watcher, I also would recommend Ganesh
Jung or Alexander Bell for the job, we basically worked on equal parts
on the myfaces scripts.


> Please note that at least one person on this list (Ken) has already
> expressed discomfort at making these changes, since the bugs they could
> introduce would be difficult to track.  It's not clear that the
> functionality that you're looking for will meet the approval of the EG.  But
> the sooner we start, the sooner we can start to sort through that.
>
>> I think it breaks flexibility provided by pluggable JSF
>> model.
>
> Well, as I said, if you modify the jsf.js file, and someone else does as
> well - how will those two interact?  They won't.  Which is why it's a bad
> idea.  I'd argue that we should expect that frameworks will *not* supply
> their own jsf.js - only implementations, of which there are two.
>