richard ratta wrote:
> I don't think it is a burden to just call the annotation processor
> with a different
> factory. This is very simple and costs just another target in a builld
> file, if you will.
You'd be surprised. Most of "users" have no idea what this means or
care to learn. They just want to use the components. Adding an extra
step (a *build* step at that!) prevents adoption.
JSP is not a good environment for JSF. Facelets and JSFTemplating are
better environments for JSF developers. As awareness grows of this
fact, more people will use "alternate" view technologies and will look
for 1st class support of these from component libraries.
>
> I was able to do this quite easily when I wanted a different
> deliverable from the
> current processor.
>
> A developer is capable of producing a processor that meets their
> requirements if more than
> what is already provided is needed.
>
> In addition given that we have no way to qualify facelet support at
> the moment
> providing this facelet tld and other artifacts by default would mean
> that our delivery mechanism would
> have to prune out pieces that we cannot qualify.
I don't see this as a problem for an "open source" project. There is no
implied support. If you have an experimental or unstable area (aka.
areas you and / or your developers cannot support), why not say that in
the comments of the file or in some other similar way.
I don't see any reason not to include a Facelets TLD by default. I see
lots of reason to include it including:
* It's the most popular non-JSP JSF view technology
* The work is already done to support it by Jason Lee -- and Jason has
proven to be a great contributor to JSF and is very experienced w/ Facelets.
* Multiple users have already asked for it
* It doesn't effect non-facelets users
Anyway, that's my 2 cents on the matter. :)
Ken Paulsen
ken.paulsen_at_sun.com
https://jsftemplating.dev.java.net
> -rick
>
> Gregory Murphy wrote:
>
>> Jason Lee wrote:
>>
>>> With this change, then, the standard JSF and JSP files (.tld,
>>> faces-config.xml) will be generated by passing in one factory to the
>>> processor, and the Facelets support file (webuijsf.taglib.xml) will be
>>> generated in a second instantiation of the processor, either in the
>>> same
>>> task or a different one? What if one were able to pass in a list of
>>> factories to apt, and do everything in one pass? I'm not sure I see
>>> the
>>> value in making the Facelets support generation a separate tasks. IMO,
>>> the file should awalys be generated (thus generating should be made as
>>> painless as possible). If the end user isn't using Facelets, there is
>>> no run-time dependency on Facelets jars; there is only 21.4KB of disk
>>> space "wasted."
>>
>>
>> I was assuming that one would want to build "either - or": either a
>> standard JSF library, or a library that works with Facelets. It
>> sounds like you would prefer that there be just a single library,
>> which can work in either a JSP environment or a Facelets environment.
>> I take your point about efficiency.
>>
>> Ultimately, the decision about how best to integrate Woodstock with
>> Facelets is one of policy as well engineering. There is an
>> architecture group that meets to discuss such matters, I'll ask them
>> for their input.
>>
>> // Gregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>