Hello Coach,
XAP does Ajax component wrapping on the client side in contrast to what
jMaki does on the server side. XAP is a 100% client side framework that
enables developers to write apps using a declarative XML syntax instead
of coding JavaScript. Different from JSF (which does processing on the
server side), XAP runtime converts such XML into actual Ajax code on the
client side and maintains state on the client side.
More info can be seen at http://incubator.apache.org/xap
For example, a sample XAP app
http://www.rockstarapps.com/samples/sendmeapic
Do you think XAP and RCF can work together?
the XAP pages look interesting and the demo is nice as well. I think
there is a possibility to get them working together. Here is what I
think might be interesting/worth for looking:
Since a developer needs to write only a client-side and a server-side
renderer (see below) for a new (custom) component, there might be a
way to use XAP and its XAL documents to provide components that fit
100% into the client-side lifecycle (see below). Instead of describing
a complete page with XAL, just provide a XAP/XAL-based client-side
renderer version for a component. Being able to work inside the
client-lifecycle would allow a page developer to *reuse* JSF goodies
like the Validators or Converters and they are still able to work w/in
the client-side-lifecycle (this isn't that easy when using jmaki,
afaict).
At least XAP sounds to be a good way to integrate 3rd party UI
Toolkits, like Dojo or Rico.
I saw there is a XAP presentation at the ApacheCon in Amsterdam, I'll
join your session and take a look at what the speaker has to say about
XAP. One mailing lists, we can check a technical way to integrate
them. Not sure how nice this will work, but I think it is worth to
try. What do you think?
Can you elaborate on what you mean by "*rich*" JSF component vs.
"*simple*" ajax-jsf-comp? I don't get the differences between jMaki and
RCF (besides using different tag names and Ajax components). I think
they all work similar by converting JSP Tag or JSF tags into Ajax code
on the server send the Ajax code to run on the client side, and maintain
a stateful component model on the server, right? jMaki can wrap a "rich"
Ajax component not any less than RCF, right? What do you mean by "JSF
concepts ported to the client"? Is there any architectural differences
between RCF and jMaki?
jmaki is using some "templating" techniques to enable developers to
add dojo (or whatever) to their JSF page. The endresult is a generic
tag, that can be used in several pages. The cool thing is, you can use
EL to bind values to backing beans and even interact w/ methods of the
beans. The same is also possible with Facelets. That is a huge step to
get your own ajax-based "widgets". With "simple" I was trying to make
clear that here only some templating comes in and in a generic way you
have a ajax-based tag (not a full-qualified component).
RCF is a bit different. RCF has a client-side framework and a
server-side framework. On server-side RCF relies on JSF and the client
part is also a "portion" of jsf to the client. That means we have
components available on the client. A JSF component is a JavaBean that
has some properties and events. The "same" is available on the client,
as a js class (generated by same metadata RCF uses to generate the
JavaBeans). Also there is a client-side renderer which is responsible
for doing all the client side stuff. The server side renderers render
"basic" HTML (no onclick="doit();" for instance) and at the end of the
page we use a JSON string to initialize the client side components and
their properties. The client side renderers join the game do register
"handlers" for events like click(onclick) or mouse-down (onmousedown)
for the "raw" HTML. Like for instance you have a slider that has
somewhere a "+" image-button to move the slider to the right (or left
in BIDI mode). The image and its <a> element are rendered on the
server, but the "client handling" is enabled by the client side
renderer, when it initializes its "root dom element" (the div here):
<div id="theSlider">
...
<a id="theSlider:plus" class="aStyleClassForThePlusButtonOfTheSlider" />
...
</div>
Not only renderers and components are available on the client. JSF
concepts like converter or validator as well:
<inputText id="long" value="#{bean.long}">
<validateLongRange min="3" max="12" />
</inputText>
When a user enters a string and *tabs* out, a ConverterException (on
the client with JS) is thrown, since the value is LONG typed, JSF uses
its default long converter, the JS version is sent down to the client
and available of the "inputText js component". Let's think about a
user enters 2 and tabs out. Then the client side framework throws a
ValidatorException, because 2 isn't inside the expected range.
When a (client) validator- or converter-exception is thrown, RCF
creates a client side version of the FacesMessage component and shows
the user a "error-message". The renderer for the
JSF-standard-FacesMessage shows/renders a popup-like widget,
containing the error message.
(RCF doesn't disable convertion/validation on the server, just because
there was some client stuff)
All these concepts work under the "client version" of the lifecycle
(similar to the jsf lifecycle on the server). So, there is a
client-version of the JSF-framework, I only gave a short example.
-Matthias
Thanks...
--Coach
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
