</p>
</td>
</tr>
<tr>
<td valign="top" align="right">&nbsp;</td><td valign="top">
<p>
The functionality delivered in this milestone will allow a
user to build a simple JSF application and execute it on the
target server. The following section gives an end user
perspective of the features by enumerating all the use cases
we plan to handle in this release. Given one of the main
goal of this project is to provide an extensible framework,
the section will also list use cases for the extensibility
that will be provided as part of this milestone.
</p>
</td>
</tr>
<tr>
<td valign="top" bgcolor="#0080c0" align="left" colspan="2"><b><font face="Arial,Helvetica" color="#ffffff">Use Cases</font></b></td>
</tr>
<tr>
<td valign="top" align="right">&nbsp;</td><td valign="top">
<p>

<h4>1. Register the JSF Implementation.</h4>
The user experience will be similar to that of registering
the JRE. For each implementation registered, a user can
specify:
<ul>

Thanks for this document. Its always helpful to have concrete items
to discuss. It looks like a promising start.

Here's some questions building on what we discussed in status call.

>> 1. Register the JSF Implementation.

You mentioned "there are several implementations" in the status call ...=

but, as with servers, "we do not ship any". So ... will you be providing=
the
"adapters" for them? How many? Which ones? Or, is there no adapters,
and just a set of filenames/paths? If filenames/paths, I assume relative=

to server install? If so, is there an opportunity for improved easy of u=
se there?
That is, is it a mattter of saying where JSF implementation is, or that
a server (facet) supports JSF?

>>
>> 4. Create a JSF JSP Page.

I know several voiced agreement that "a seperate wizard" would be
appropriate ... but ... I'm not so sure. So,
I would like to voice "need" that nothing
(or little) should be "tied" to the wizard. Anything that the
wizard accomplishes should be able to be accomplished in other ways,
just by editing an existing JSP, modifying project properties, for examp=
le.
(I dont' really object to a wizard, per se ... but, just want to be
sure whole design doesn't depend on it ... I think that's consistent
with your remarks, I'm just restating the obvious).

>>
>> 6. Edit the Application Configuration Resource file.
>>
>> For this milestone, the Editor will be a basic SSE based XML Source
>> Editor with the following features.
>>
>> * JSF-specific content assist

Not sure how his would work, other than what's there for shema's.
Is there more needed? Do you need new API's from us in WTP Editing,
if so, probably won't be in your M1 :)
[e.g. API's to allow content assist for "classes" won't really be there.=

Of course, you could implement with suggestions for what to make API,
which would be helpful to us!]

>> * "Hot linking" (ctrl-click) for classes to their corresponding j=
ava
>> file. If the class doesn't exist, the editor will provide optio=
n
>> to launch wizard to create it

Are these really "APIs"? That others could write code to? First one seem=
s maybe could be
depending on registration means ... but are others needed as API's, or a=
re you just
providing an implementation to do these things? Seems API implies someon=
e is
"going beyond JSF" ... adding something on top of JSF. Maybe I'm reading=
too much
into it ... but, you know how cautious I am about calling something API =
:)

Thanks for this document. Its always helpful to have concrete items
to discuss. It looks like a promising start.

Here's some questions building on what we discussed in status call.

>> 1. Register the JSF Implementation.

You mentioned "there are several implementations" in the status call ...=

but, as with servers, "we do not ship any". So ... will you be providing=
the
"adapters" for them? How many? Which ones? Or, is there no adapters,
and just a set of filenames/paths? If filenames/paths, I assume relative=

to server install? If so, is there an opportunity for improved easy of u=
se there?
That is, is it a mattter of saying where JSF implementation is, or that
a server (facet) supports JSF?

>>
>> 4. Create a JSF JSP Page.

I know several voiced agreement that "a seperate wizard" would be
appropriate ... but ... I'm not so sure. So,
I would like to voice "need" that nothing
(or little) should be "tied" to the wizard. Anything that the
wizard accomplishes should be able to be accomplished in other ways,
just by editing an existing JSP, modifying project properties, for examp=
le.
(I dont' really object to a wizard, per se ... but, just want to be
sure whole design doesn't depend on it ... I think that's consistent
with your remarks, I'm just restating the obvious).

>>
>> 6. Edit the Application Configuration Resource file.
>>
>> For this milestone, the Editor will be a basic SSE based XML Source
>> Editor with the following features.
>>
>> * JSF-specific content assist

Not sure how his would work, other than what's there for shema's.
Is there more needed? Do you need new API's from us in WTP Editing,
if so, probably won't be in your M1 :)
[e.g. API's to allow content assist for "classes" won't really be there.=

Of course, you could implement with suggestions for what to make API,
which would be helpful to us!]

>> * "Hot linking" (ctrl-click) for classes to their corresponding j=
ava
>> file. If the class doesn't exist, the editor will provide optio=
n
>> to launch wizard to create it

Are these really "APIs"? That others could write code to? First one seem=
s maybe could be
depending on registration means ... but are others needed as API's, or a=
re you just
providing an implementation to do these things? Seems API implies someon=
e is
"going beyond JSF" ... adding something on top of JSF. Maybe I'm reading=
too much
into it ... but, you know how cautious I am about calling something API =
:)

David Williams wrote:
> On Tue, 11 Oct 2005 14:21:12 -0400, Raghu Srinivasan
> <raghunathan.srinivasan@oracle.com> wrote:
>
> Thanks for this document. Its always helpful to have concrete items
> to discuss. It looks like a promising start.
>
> Here's some questions building on what we discussed in status call.
>
>>> 1. Register the JSF Implementation.
>
>
> You mentioned "there are several implementations" in the status call ...
> but, as with servers, "we do not ship any". So ... will you be providing
> the
> "adapters" for them? How many? Which ones? Or, is there no adapters,
> and just a set of filenames/paths? If filenames/paths, I assume relative
> to server install? If so, is there an opportunity for improved easy of
> use there?
> That is, is it a mattter of saying where JSF implementation is, or that
> a server (facet) supports JSF?
>
There are no adapters; registering an implementation involves specifying
location of the implementation's JAR files and tag libraries, plus a few
other details. The implementation is not necessarily relative to any server;
a server may or may not include any JSF implementation. We will use the JSF
implementation registry to ensure that the libraries are on the build path,
the libraries are packaged into the web application, hopefully (eventually)
use tag library details to build palettes, etc. The basic idea behind the
registry is that the user need only provide details about an implementation
once per workspace, then consequently (e.g. when the JSF facet is added to a
web module) the user need only select the implementation by name, and not
have to specify all details each and every time.
>
>>>
>>> 4. Create a JSF JSP Page.
>
>
> I know several voiced agreement that "a seperate wizard" would be
> appropriate ... but ... I'm not so sure. So,
> I would like to voice "need" that nothing
> (or little) should be "tied" to the wizard. Anything that the
> wizard accomplishes should be able to be accomplished in other ways,
> just by editing an existing JSP, modifying project properties, for example.
> (I dont' really object to a wizard, per se ... but, just want to be
> sure whole design doesn't depend on it ... I think that's consistent
> with your remarks, I'm just restating the obvious).

Nothing will be tied to the wizard. The wizard will perform some basic tasks
that the user could perform manually in a series of steps. The wizard will
perform such tasks as ensuring that the web module has the JSF facet, that
FacesServlet is configured in web.xml, and producing a "stub" JSP page that
includes appropriate taglib directives for JSF. The wizard provides
convenience by orchestrating a series of tasks that could be performed manually.
>
>>>
>>> 6. Edit the Application Configuration Resource file.
>>>
>>> For this milestone, the Editor will be a basic SSE based XML Source
>>> Editor with the following features.
>>>
>>> * JSF-specific content assist
>
>
> Not sure how his would work, other than what's there for shema's.
> Is there more needed? Do you need new API's from us in WTP Editing,
> if so, probably won't be in your M1 :)
> [e.g. API's to allow content assist for "classes" won't really be there.
> Of course, you could implement with suggestions for what to make API,
> which would be helpful to us!]

We would like to implement such functionality as recognizing particular
regions in the StructuredDocument and where a JSP page is expected as
content, providing the user content assist that lists pages in the project,
or where a class is expected as content, providing the user content assist
that lists classes. We have not yet fully figured out implementation
details, and where we find we have a need for API that doesn't currently
exist, we will begin communicating with the appropriate team(s). Where API
will not be available in time for our M1, then we will table the
functionality for a future milestone (or rethink our strategy).
>
>>> * "Hot linking" (ctrl-click) for classes to their corresponding java
>>> file. If the class doesn't exist, the editor will provide option
>>> to launch wizard to create it
>
>
> Cool. Can we re-use this to edit PDE plugin files :) [just kidding,
> honest]

It's certainly possible that functionality that we intend to provide will be
useful elsewhere; we'd be happy for some of our intended implementations to
trickle out into other areas...now we just have to actually implement such
amazing stuff :)
>
>>> 9. Extensions
>>>
>>> * API to register a JSF implementation
>>> * API to add the JSF Project Facet to a Dynamic Web Project
>>> * API to create an Application Configuration Resource file.
>>> * API to add instances of various artifacts of the Application
>>> Configuration Resource file such as the Managed bean, Navigation
>>> Rule, Validator etc.
>>> * Extension points for the Application Configuration Editor
>
>
> Are these really "APIs"? That others could write code to? First one
> seems maybe could be
> depending on registration means ... but are others needed as API's, or
> are you just
> providing an implementation to do these things? Seems API implies
> someone is
> "going beyond JSF" ... adding something on top of JSF. Maybe I'm reading
> too much
> into it ... but, you know how cautious I am about calling something API :)

Yes, we believe that these will be provided as public APIs. A goal of our
project is to facilitate as much as possible further extension of the
tooling that we will provide. We can envision that clients of our tooling
(as we ourselves will be) may want to programmatically extend the services
that our own wizards and tools will make use of, and so we feel we should
expose significant functionality as API.
>
> Thanks again ... I'll look forward as these plans turning into code!]]>Ian Trimble2005-10-12T21:00:32-00:00Re: Milestone 1 Feature set + Next Status meeting: Reminder Meeting is at 2.00 PM PDT.https://www.eclipse.org/forums/index.php/mv/msg/149699/573617/#msg_573617
Ian Trimble (Oracle)

David Williams wrote:
> On Tue, 11 Oct 2005 14:21:12 -0400, Raghu Srinivasan
> <raghunathan.srinivasan@oracle.com> wrote:
>
> Thanks for this document. Its always helpful to have concrete items
> to discuss. It looks like a promising start.
>
> Here's some questions building on what we discussed in status call.
>
>>> 1. Register the JSF Implementation.
>
>
> You mentioned "there are several implementations" in the status call ...
> but, as with servers, "we do not ship any". So ... will you be providing
> the
> "adapters" for them? How many? Which ones? Or, is there no adapters,
> and just a set of filenames/paths? If filenames/paths, I assume relative
> to server install? If so, is there an opportunity for improved easy of
> use there?
> That is, is it a mattter of saying where JSF implementation is, or that
> a server (facet) supports JSF?
>
There are no adapters; registering an implementation involves specifying
location of the implementation's JAR files and tag libraries, plus a few
other details. The implementation is not necessarily relative to any server;
a server may or may not include any JSF implementation. We will use the JSF
implementation registry to ensure that the libraries are on the build path,
the libraries are packaged into the web application, hopefully (eventually)
use tag library details to build palettes, etc. The basic idea behind the
registry is that the user need only provide details about an implementation
once per workspace, then consequently (e.g. when the JSF facet is added to a
web module) the user need only select the implementation by name, and not
have to specify all details each and every time.
>
>>>
>>> 4. Create a JSF JSP Page.
>
>
> I know several voiced agreement that "a seperate wizard" would be
> appropriate ... but ... I'm not so sure. So,
> I would like to voice "need" that nothing
> (or little) should be "tied" to the wizard. Anything that the
> wizard accomplishes should be able to be accomplished in other ways,
> just by editing an existing JSP, modifying project properties, for example.
> (I dont' really object to a wizard, per se ... but, just want to be
> sure whole design doesn't depend on it ... I think that's consistent
> with your remarks, I'm just restating the obvious).

Nothing will be tied to the wizard. The wizard will perform some basic tasks
that the user could perform manually in a series of steps. The wizard will
perform such tasks as ensuring that the web module has the JSF facet, that
FacesServlet is configured in web.xml, and producing a "stub" JSP page that
includes appropriate taglib directives for JSF. The wizard provides
convenience by orchestrating a series of tasks that could be performed manually.
>
>>>
>>> 6. Edit the Application Configuration Resource file.
>>>
>>> For this milestone, the Editor will be a basic SSE based XML Source
>>> Editor with the following features.
>>>
>>> * JSF-specific content assist
>
>
> Not sure how his would work, other than what's there for shema's.
> Is there more needed? Do you need new API's from us in WTP Editing,
> if so, probably won't be in your M1 :)
> [e.g. API's to allow content assist for "classes" won't really be there.
> Of course, you could implement with suggestions for what to make API,
> which would be helpful to us!]

We would like to implement such functionality as recognizing particular
regions in the StructuredDocument and where a JSP page is expected as
content, providing the user content assist that lists pages in the project,
or where a class is expected as content, providing the user content assist
that lists classes. We have not yet fully figured out implementation
details, and where we find we have a need for API that doesn't currently
exist, we will begin communicating with the appropriate team(s). Where API
will not be available in time for our M1, then we will table the
functionality for a future milestone (or rethink our strategy).
>
>>> * "Hot linking" (ctrl-click) for classes to their corresponding java
>>> file. If the class doesn't exist, the editor will provide option
>>> to launch wizard to create it
>
>
> Cool. Can we re-use this to edit PDE plugin files :) [just kidding,
> honest]

It's certainly possible that functionality that we intend to provide will be
useful elsewhere; we'd be happy for some of our intended implementations to
trickle out into other areas...now we just have to actually implement such
amazing stuff :)
>
>>> 9. Extensions
>>>
>>> * API to register a JSF implementation
>>> * API to add the JSF Project Facet to a Dynamic Web Project
>>> * API to create an Application Configuration Resource file.
>>> * API to add instances of various artifacts of the Application
>>> Configuration Resource file such as the Managed bean, Navigation
>>> Rule, Validator etc.
>>> * Extension points for the Application Configuration Editor
>
>
> Are these really "APIs"? That others could write code to? First one
> seems maybe could be
> depending on registration means ... but are others needed as API's, or
> are you just
> providing an implementation to do these things? Seems API implies
> someone is
> "going beyond JSF" ... adding something on top of JSF. Maybe I'm reading
> too much
> into it ... but, you know how cautious I am about calling something API :)

Yes, we believe that these will be provided as public APIs. A goal of our
project is to facilitate as much as possible further extension of the
tooling that we will provide. We can envision that clients of our tooling
(as we ourselves will be) may want to programmatically extend the services
that our own wizards and tools will make use of, and so we feel we should
expose significant functionality as API.
>
> Thanks again ... I'll look forward as these plans turning into code!]]>Ian Trimble2005-10-12T21:00:32-00:00