myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
Date Sat, 08 Sep 2007 00:17:11 GMT
On 9/7/07, Andrew Robinson <andrew.rw.robinson@gmail.com> wrote:
> 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.

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.

> 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.

I still agree this is a good goal (though, BTW, the very
specific issue of *what* constitutes a triggering activity
is in fact exactly a component issue, and therefore does
very much belong to Trinidad components!)

> 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,

I said no such thing, nor would I ever.  I'm sorry if you
misunderstood.

> 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.

This is not my message.  I've never heard anyone give this
message.

> 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?

NOT client-side validation.  Client-side insertion of server-side
messages.  Heck, I work at Oracle - do you really think I don't believe
in database-generated error messages?

> 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.

I've never said "100% no" to this functionality.  I've said "100% no"
to adding it in without discussion, and I'm pushing back on specific
parts of it that just don't seem to add up, especially where they concern
Trinidad components.

-- Adam


>

Mime
View raw message