It pays to add the footnotes:

[1] https://bpcatalog.dev.java.net/
[2] https://ajax.dev.java.net/

Craig

On 1/14/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:



On 1/14/07, JS Portal Support <[EMAIL PROTECTED]> wrote:
>
> Craig,
>
> Great, it now works nicely and is portable to any other view I might
> create
> in the future without altering my GenericTable view.


Cool ... that's the way it's supposed to work :-).


On a different note:
> Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script
> engine of choice? As we are currently looking at our options it seems to
> me
> this will be the wisest choice right?


More specifically, the component libraries at MyFaces (Tomahawk and Tobago
in the MyFaces project now, Trinidad in the incutabor) have tended to choose
Dojo for their Ajax support.  That's more up to each individual library than
it is up to MyFaces as a whole.  And, as a general policy, I can't disagree
that it is a reasonable choice.  I used Dojo also in our work on the
Blueprints Ajax components[1] that ship with Java Studio Creator and
NetBeans Visual Web Pack.

We made that choice originally because of the nice lower level APIs for
asynchronous messaging and eventing on the client side.  I've been pretty
happy with those layers, but not quite as happy with the UI widget layer --
which has been going through a lot of evolution lately but is looking more
settled as we go on.

Personally, I'm spending a bunch of time today on the jMaki project[2],
where a primary goal is to let you avoid locking yourself into one
particular widget framework.  jMaki strives to provide a common adapter API
around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo,
and a bunch of others) to both reduce complexity and support mix-and-match.
Today, there's a low level JSF component that provides direct connection to
a large portion of these libraries, but with a fairly low level API.  I'm
also working on adding a layer of JSF components per widget that will appeal
more to someone familiar with traditional JSF composition of your views ...
and, will fit very nicely into visual development tools.

Needless to say, this all works very nicely with Shale :-).

I have to say the more I learn about shale/MyFaces the more excited I get.
>
> We come from a custom build mvc which we respectfully will lay to rest
> now
> :-)


:-)

Thanks,
> Joost


Craig


Reply via email to