Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of andrew.rw.robinson@gmail.com
 designates 209.85.128.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RQ/YsRVhNx4ody2KzpUsCNAKljpCztXJhgfuFhYk3sxe7RkbvMys/W3SE6NABxrwlLnUqb1FfUlcXE4r8rzmWKUL1C6lpq/zHs1qutO/fSNtSwww7NMkOdCIW3yUTQlizgHdeomI3A0cN6fZywM/9Q6nfX+SKHAtEt0EgKnqmE4=
Message-ID: <bc36a6210709070834h50389a00v2f3b5ad02f5e5119@mail.gmail.com>
Date: Fri, 7 Sep 2007 09:34:05 -0600
From: "Andrew Robinson" <andrew.rw.robinson@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: [Trinidad] Components provided by issues 663 and 664 - overview
 and chance to vote
In-Reply-To: <bc36a6210709070630w3abfcaecp55269432addd38d8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bc36a6210709040838k41b77a1au2ca7cb2a3f018eb2@mail.gmail.com>
	 <6dac79b90709040900w59916a9bwdb2d03ebc2ee5cb4@mail.gmail.com>
	 <bc36a6210709040929j69dfdb5ve33bd3ba83b746e@mail.gmail.com>
	 <6dac79b90709051345t784fa489pd33481b53007305d@mail.gmail.com>
	 <bc36a6210709051419l7353d4c3ode263f3fb641fb5d@mail.gmail.com>
	 <6dac79b90709061645w6efcd938t4420b8620b3a2647@mail.gmail.com>
	 <bc36a6210709070630w3abfcaecp55269432addd38d8@mail.gmail.com>

Adam,

To put it a little more politically correct, I think it is very
important to have the PPR/AJAX function of Trinidad viewed as
completely separate functionality from the Trinidad components. In the
same way that decisions by RichFaces developers does not limit
Ajax4JSF functionality, I don't feel that Trinidad components should
limit Trinidad PPR functionality.

If a user must choose RichFaces+A4J, ICEFaces or Trinidad to get PPR
functionality since the libraries really are not compatible, I think
it is extremely important to ensure that the AJAX functionality that
Trinidad uses should be as portable and feature rich as possible to
allow users to integrate more than one library at a time (facelets and
seam are examples of very popular frameworks that have components).

I think this is also a very good reason why I proposed, and at the
time you agreed, that the PPR/AJAX functionality should be extracted
from Trinidad and made part of a MyFaces AJAX commons library.

With this in mind, I think the PPR functionality in Trinidad should be
designed for all JSF development scenarios, and not just ones that
only apply to Trinidad components.

So when you said that it wasn't important that seam:validation,
seam:validateAll and seam:decorate functionality should not be
supported by Trinidad PPR, because Trinidad components would not
benefit from that functionality just because most users that use
Trinidad components, use client-side validation, it is almost like you
are saying that users have to choose either 100% Trinidad components,
or not to use Trinidad at all as the message that is coming across is
that the Trinidad developers will not support functionality that
doesn't apply to most of the Trinidad component use cases.

The tr:partialTrigger component's functionality is primarily for usage
with server-side validation, not JavaScript validation. It is very
important to have this functionality for users that will be using 3rd
party validators, and 3rd party components, as witnessed by the Seam
components I just listed.

Also, I have mentioned several times a use case of requiring server
side validation for validation of database uniqueness of fields (like
user name), but you have never responded to that, but instead keep
going back to client-side validation. How do you propose to handle
database-based JSF validators with PPR?

In summary, my point is that I believe tr:partialTrigger provides
required functionality for a complete AJAX library. I also would like
this project to invest some time and research into providing more
robust AJAX support that is similar in nature to some of the A4J
functionality (like the A4J support component's attributes in
particular).

If we could get to more of a model of:

MyFaces AJAX
  - used by:
  - Trinidad components
    - Oracle rich client
  - Tomahawk
    - Sandbox
  - Tobago?

I think that a MyFaces custom component solution will become a lot
more appealing to people wishing to build a new JSF project. There has
been a lot of evidence that users do not feel that the PPR in Trinidad
is on the same playing field as A4J. Adding the missing functionality,
and making Trinidad's PPR functionality usable by all component
frameworks that wish to use it would go a very long way to making
Trinidad more ubiquitous.