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 17:59:38 GMT
On 9/7/07, Andrew Robinson <andrew.rw.robinson@gmail.com> wrote:
> > ...I'd be vastly less concerned about seeing such
> > a component appear in a generic MyFaces PPR/AJAX library, when
> > we get around to that...
>
> What about a slow start?
>
> Could be a tag namespace of:
>
> xmlns:tra="http://myfaces.apache.org/trinidad/ajax"
>
> or
>
> xmlns:trp="http://myfaces.apache.org/trinidad/ppr"

If the goal is to create a new PPR library, we should
just start there:

  xmlns:ppr="http://myfaces.apache.org/ppr"

... instead of creating trinidad components, then deleting
them.

We could try creating a new top-level library (perhaps
in SVN at something like:

  http://svn.apache.org/repos/asf/myfaces/sandbox/ppr

... where the initial implementation is entirely dependent
on Trinidad, we get the generic APIs we want in place,
then we look at refactoring Trinidad and the PPR library
to reverse the dependency order, and move this "ppr"
thing out of the generic MyFaces sandbox.

A lot of those details definitely would need to be
discussed with the greater MyFaces community, and
we'd certainly want to make sure some committers
who concentrate on Tomahawk are actively involved
in its development - there's zero point in heading down
this road if we don't have everyone on board with
making this a core dependency of both Trinidad and
Tomahawk.

-- Adam


> then any components written that are not HTML in nature, but are
> simply PPR-AJAX related would be in this namespace.
>
> That way, if Trinidad's PPR functionality is extracted into its own
> library, these components could move with it to a new namespace?
>
> It provides a half-way point where there is functionality not
> specifically for Trinidad's HTML oriented components, and keeping them
> separate from the "core" components. This way there is a clear
> separation of functionality and goals?
>

Mime
View raw message