> What limitation of Trinidad components are limiting Trinidad PPR functionality
> overall, when you've conclusively proved that you can write components on
> top of the Trinidad PPR functionality that address your issues? Nothing
> discussed here is about whether PPR/AJAX core functionality in Trinidad
> needs enhancements.
>From the various mailing lists and blogs on JSF, you will see that if
you required users of a JSF toolkit to write custom components or
renderers, there is a good chance many will not use your components.
The A4J library is quickly becoming the JSF standard for AJAX
solutions, because it allows for people to use large amounts of AJAX
functionality with a lot of flexibility with absolutely no Java code
or configuration.
If Trinidad wants to achieve this same level of popularity and a good
chunk of the user market, it needs the same ability to plug and
play PPR functionality into the view layer only (meaning no coding
required).
The A4J components are AJAX oriented, they are not HTML oriented. This
allows them to work with other components out of the box. Take this
code for example:
<a4j:outputPanel id="myPanel">
Your selection is: #{mySelection}
</a4j:outputPanel>
<a4j:region>
<h:selectOneMenu value="#{mySelection}">
<a4j:support event="onchange"
ajaxSingle="true"
reRender="myPanel" />
<f:selectItem itemLabel="First" itemValue="1st" />
<f:selectItem itemLabel="Second" itemValue="2nd" />
</h:selectOneMenu>
</a4j:region>
This type of functionality has come up many times in the user list. It
is a very common use case. What is so grand about it?
1) a4j:outputPanel -- a simple construct yet, really not much
different at all from h:panelGroup. The difference is that it is clear
to users that this makes a DIV or a SPAN tag that can be updated from
AJAX. Yes, I could have easily used h:panelGroup and it would have
also worked, but not every thinks that way.
2) a4j:region -- much like the tr:subform, but it has better
performance. It has relatively clear documentation that states that it
sections off the AJAX request to only send data from inside this
region
3) a4j:support -- I just added AJAX support to a non-A4J component. I
got to choose when it fires, I got to put it on any HTML component
that I wanted, it didn't matter who wrote the component, I just know
it works and has many options.
Now take this example a bit further:
<h:inputText value="#{myValue}">
<a4j:support event="onkeydown"
ajaxSingle="true"
reRender="myPanel"
disableDefault="true"
onsubmit="var e = window.event || event;
var keyCode = evt.keyCode || evt.which;
var char = String.fromCharCode(keyCode);
if (char != '\n' && char != '\r') return true;" />
</h:inputText>
With no Java code, no custom components I now created a text box that
submits itself when the user hits enter when it has focus. I not only
got to choose the event to check, but I got to veto it if I want to,
and I also can have the component return false from the event handler.
Once again, I added it to a non-JBoss component.
I only showed a small portion of the A4J support functionality. It has
a lot more, like skipping updates, only firing AJAX calls every so
often (so it is feasible to use with keydown, mouseover, etc.), you
can set where the focus goes after the call is complete, you can use
your own status component that supports more than just an icon, and to
top it off, there is an "oncomplete" attribute that lets me run my own
JavaScript specific to this component once the AJAX call is done.
Trinidad's PPR functionality is tightly integrated with Trinidad's
components. There is no a4j:support type of component. Sure I can call
TrPage methods that are documented in the developers guide, but can I
get a call back when the event completes, can I set which components
that need to be re-rendered? Even if I use Trinidad components, I am
still limited. For example,
<tr:inputText autoSubmit="true" value="#{test}" />
Okay, when does it submit -- hard coded based on the developer who
wrote the input text renderer. Can I change it without Java code? No.
Can I run a specific action or action listener on the server when the
user hits the enter key? No. Can I add autoSubmit functionality to JSF
core or 3rd party components without Java code? Unfortunately no to
that question as well.
What you see happening is the different target audience. Trinidad's
PPR functionality is targeted primarily for component and renderer
developers. A4J is targeted to view developers, a.k.a users. I am not
saying that user's can't use Trinidad's PPR and I am not saying
component developers loose power with A4J, it is the level of clarity,
degree of exposed functionality and ease of use that is very
different.
Now the reason that I have chosen to try out Trinidad is that there
are more HTML components than in RichFaces. I knew going in that
Trinidad's PPR functionality is much less than A4J. I think there are
some nicer things about Trinidad's PPR than A4J, like the fact that I
know that my 3rd party components will not blow up during rendering
because A4J hacks the JSF lifecycle to get better performance. I also
chose Trinidad since it is based on the Apache license.
So with this in mind, why don't we write components for Trinidad that
are solely to exposed PPR functionality to help users write JSF
applications without worrying about components, renderers,
configuration, minimize the JavaScript, etc.?
> I'm not saying client-side validation is the one true way to go,.
> I'm saying that DHTML that can *insert messages on the client-side*
> is the right way to go
I don't agree with this, because DHTML inserting messages on the
client side means that only component that are specifically written to
do this will work with this solution. Also, it only supports messages,
a very small piece of JSF functionality. I, as a user, lose all the
great functionality of the components and their rendererers. Like my
seam:decorate example, I have the ability to completely change how I
render a bunch of components just because one component failed
validation.
As a user, if you could chose between being able to re-render
components, styling them as you want, and having the full power of JSF
or only being limited to having a message displayed in a way that one
component dictates that you have to and will only ever be supported by
components that have Trinidad as a dependency, which library would you
chose?
I'm not trying to put Trindad down, but am trying to convince the
team, from a seasoned user's perspective on how to make it more usable
and likable from a user's perspective.
Cheers,
Andrew
