Eclipse Community Forums: JavaServer Faces » Milestone 1 Feature set + Next Status meeting

Help

Home

Home » Eclipse Projects » JavaServer Faces » Milestone 1 Feature set + Next Status meeting

Show: Today's Messages :: Show Polls :: Message Navigator

Milestone 1 Feature set + Next Status meeting [message #470615]

Fri, 07 October 2005 19:07

Raghu Srinivasan

Messages: 265
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------080201030705010809070805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

The JSF Project has been provisioned! We now have CVS access, website
and a dev mailing list. We are fixing the website and will share all the
relevant information.

I have attached a doc that lists the proposed feature set for Milestone
1 of this project. The planned release date for this is around 12/16/05.
Please review and post your feedback to this newsgroup.

We will have the next status call on Tuesday instead of Monday to
accommodate the Canadian Holiday. I propose we meet at 2.00 PM PST.

Thanks
Raghu

Date:10/11/05
Time: 2.00 PM PDT
Conference Call info:

Call one of the MeetingPlace phone numbers:
From the AMER region dial:
1-888-967-2253
+1-650-607-2253

From the APAC region dial:
1800 222 712 (Australia toll-free)
+800 9491 2777
+61 2 8817 6100

From the EMEA region dial:
+44 118 924 9000

Meeting ID : 444461
Meeting Passcode : 573573

Conference Call info:

Call one of the MeetingPlace phone numbers:
From the AMER region dial:
1-888-967-2253
+1-650-607-2253

From the APAC region dial:
1800 222 712 (Australia toll-free)
+800 9491 2777
+61 2 8817 6100

From the EMEA region dial:
+44 118 924 9000

Meeting ID : 444461
Meeting Passcode : 573573

--------------080201030705010809070805
Content-Type: text/html; charset=UTF-8;
name="FeatureSpecs-M1.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="FeatureSpecs-M1.html"

<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="../../default_style.css" type="text/css">
<link rel="stylesheet" href="../../webtools/wtp.css" type="text/css">
<title>JSF Tools Project Features for Milestone 1</title>
</head>
<body>
<table width="100%" cellspacing="5" cellpadding="2" border="0">
<col width="16">
<col width="*">
<tbody>
<tr>
<td valign="top" bgcolor="#0080c0" align="left" colspan="2"><b><font face="Arial,Helvetica" color="#ffffff">Introduction</font></b></td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>
This document defines the set of features that will be
delivered in the Milestone 1 of the project. This document
is a draft meant to solicit community feedback.
<b>
Please send all feedback to the
<a class="bodylink" href="news://news.eclipse.org/eclipse.webtools.jsf">
eclipse.webtools.jsf
</a>
newsgroup.
</b>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>
Following are the main themes for this milestone release:
<li>Define the JSF Facet</li>

<li>
Provide a first-class editor for the Application
Configuration resource file
</li>

<li>
Define the complete JSF Application model including all
the JSF specific artifacts.
</li>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </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"> </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>

<li>Name</li>

<li>JSF Version supported</li>

<li>Libraries</li>

<li>Tag libraries</li>

<li>Default servlet name</li>

<li>Default servlet class</li>

</ul>
A JSF implementation can be selected during project creation
or when adding JSF facets to an existing web project.
</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>
2. Create a Dynamic Web Project with the JSF Project
Facet.
</h4>

<h4>
3. Add the JSF Project Facet to an existing Dynamic Web
Project.
</h4>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>
In both the scenarios, a user has the following options to
choose:
<ul>

<li>Select JSF implementation from registry</li>

<li>Select the JSF Version</li>

<li>
Create single application configuration resource
file
</li>

<ul>

<li>
Filename defaults to preference, overridable
Location defaults to ".../WEB-INF", allows
overridable
</li>

<li>
Updates context-param in web.xml if selected
location/filename is not
"WEB-INF/faces-config.xml"
</li>

</ul>

<li>
Update the web.xml with servlet and servlet-mapping
information
</li>

<ul>

<li>
Servlet name/classname default to preferences,
overridable
</li>

<li>
Servlet-mapping defaults to preference,
overridable
</li>

</ul>

</ul>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>4. Create a JSF JSP Page.</h4>
This will be similar to the New JSP Wizard. The user can
specify the following.
<ul>

<li>Name</li>

<li>Location</li>

<li>JSF template (optional)</li>

</ul>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>5. Create Application Configuration Resource file.</h4>
User can specify the following.
<ul>

<li>
File Name, defaults to the name specified in the
preference
</li>

<li>
Location, defaults to the path specified in the
preference
</li>

</ul>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>6. Edit the Application Configuration Resource file.</h4>
For this milestone, the Editor will be a basic SSE based XML
Source Editor with the following features.
<ul>

<li>JSF-specific content assist</li>

<li>
"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

</li>

</ul>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>
7. Run/ Debug a JSF JSP Page (and Application
Configuration file) on the Server.
</h4>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>
8. User will be able to specify the following
preferences.
</h4>

<ul>

<li>Default JSF implementation</li>

<li>Default JSF Version</li>

<li>
Default FileName of the Application Configuration
Resource file.
</li>

<li>
Default location of the Application Configuration
Resource file.
</li>

<li>Default JSF Template</li>

</ul>

</p>
</td>
</tr>
<tr>
<td valign="top" align="right"> </td><td valign="top">
<p>

<h4>9. Extensions</h4>

<ul>

<li>API to register a JSF implementation</li>

<li>
API to add the JSF Project Facet to a Dynamic Web
Project
</li>

<li>
API to create an Application Configuration Resource
file.
</li>

<li>
API to add instances of various artifacts of the
Application Configuration Resource file such as the
Managed bean, Navigation Rule, Validator etc.
</li>

<li>
Extension points for the Application Configuration
Editor
</li>

</ul>

</p>
</td>
</tr>
</tbody>
</table>
</body>
</html>

--------------080201030705010809070805--

Raghu Srinivasan,
Project Lead - JSF

Report message to a moderator

Re: Milestone 1 Feature set + Next Status meeting: Reminder Meeting is at 2.00 PM PDT. [message #470616 is a reply to message #470615]

Tue, 11 October 2005 18:21

Raghu Srinivasan

Messages: 265
Registered: July 2009

Senior Member

The meeting is at 2.00 PM PDT.

Raghu Srinivasan wrote:
> Hi,
>
> The JSF Project has been provisioned! We now have CVS access, website
> and a dev mailing list. We are fixing the website and will share all the
> relevant information.
>
> I have attached a doc that lists the proposed feature set for Milestone
> 1 of this project. The planned release date for this is around 12/16/05.
> Please review and post your feedback to this newsgroup.
>
> We will have the next status call on Tuesday instead of Monday to
> accommodate the Canadian Holiday. I propose we meet at 2.00 PM PST.
>
> Thanks
> Raghu
>
> Date:10/11/05
> Time: 2.00 PM PDT
> Conference Call info:
>
> Call one of the MeetingPlace phone numbers:
> From the AMER region dial:
> 1-888-967-2253
> +1-650-607-2253
>
> From the APAC region dial:
> 1800 222 712 (Australia toll-free)
> +800 9491 2777
> +61 2 8817 6100
>
> From the EMEA region dial:
> +44 118 924 9000
>
> Meeting ID : 444461
> Meeting Passcode : 573573
>
>
>
>
>
>
>
>
>
>
> Conference Call info:
>
> Call one of the MeetingPlace phone numbers:
> From the AMER region dial:
> 1-888-967-2253
> +1-650-607-2253
>
> From the APAC region dial:
> 1800 222 712 (Australia toll-free)
> +800 9491 2777
> +61 2 8817 6100
>
> From the EMEA region dial:
> +44 118 924 9000
>
> Meeting ID : 444461
> Meeting Passcode : 573573
>
> ------------------------------------------------------------ ------------
>
> *Introduction*
>
>
> This document defines the set of features that will be delivered in the
> Milestone 1 of the project. This document is a draft meant to solicit
> community feedback. * Please send all feedback to the
> eclipse.webtools.jsf <news://news.eclipse.org/eclipse.webtools.jsf>
> newsgroup. *
>
>
>
> Following are the main themes for this milestone release:
>
> # Define the JSF Facet
> # Provide a first-class editor for the Application Configuration resource
> file
> # Define the complete JSF Application model including all the JSF specific
> artifacts.
>
>
>
> 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.
>
> *Use Cases*
>
>
>
> 1. Register the JSF Implementation.
>
> The user experience will be similar to that of registering the JRE. For
> each implementation registered, a user can specify:
>
> * Name
> * JSF Version supported
> * Libraries
> * Tag libraries
> * Default servlet name
> * Default servlet class
>
> A JSF implementation can be selected during project creation or when
> adding JSF facets to an existing web project.
>
>
>
>
> 2. Create a Dynamic Web Project with the JSF Project Facet.
>
>
> 3. Add the JSF Project Facet to an existing Dynamic Web Project.
>
>
>
> In both the scenarios, a user has the following options to choose:
>
> * Select JSF implementation from registry
> * Select the JSF Version
> * Create single application configuration resource file
> o Filename defaults to preference, overridable Location
> defaults to ".../WEB-INF", allows overridable
> o Updates context-param in web.xml if selected
> location/filename is not "WEB-INF/faces-config.xml"
> * Update the web.xml with servlet and servlet-mapping information
> o Servlet name/classname default to preferences, overridable
> o Servlet-mapping defaults to preference, overridable
>
>
>
>
> 4. Create a JSF JSP Page.
>
> This will be similar to the New JSP Wizard. The user can specify the
> following.
>
> * Name
> * Location
> * JSF template (optional)
>
>
>
>
> 5. Create Application Configuration Resource file.
>
> User can specify the following.
>
> * File Name, defaults to the name specified in the preference
> * Location, defaults to the path specified in the preference
>
>
>
>
> 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
> * "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
>
>
>
>
> 7. Run/ Debug a JSF JSP Page (and Application Configuration
> file) on the Server.
>
>
>
>
> 8. User will be able to specify the following preferences.
>
> * Default JSF implementation
> * Default JSF Version
> * Default FileName of the Application Configuration Resource file.
> * Default location of the Application Configuration Resource file.
> * Default JSF Template
>
>
>
>
> 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
>

Raghu Srinivasan,
Project Lead - JSF

Report message to a moderator

Re: Milestone 1 Feature set + Next Status meeting: Reminder Meeting is at 2.00 PM PDT. [message #470618 is a reply to message #470616]

Tue, 11 October 2005 22:02

David Williams

Messages: 722
Registered: July 2009

Senior Member

On Tue, 11 Oct 2005 14:21:12 -0400, Raghu Srinivasan <raghunathan.sriniv=
asan@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 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

Cool. Can we re-use this to edit PDE plugin files :) [just kidding, hon=
est]

>> 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, Navigatio=
n
>> Rule, Validator etc.
>> * Extension points for the Application Configuration Editor

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 again ... I'll look forward as these plans turning into code!

Report message to a moderator

Re: Milestone 1 Feature set + Next Status meeting: Reminder Meeting is at 2.00 PM PDT. [message #470620 is a reply to message #470618]

Wed, 12 October 2005 21:00

Ian Trimble

Messages: 137
Registered: July 2009

Senior Member

Thanks for the questions and feedback. Please see my responses inline, below.

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!

Report message to a moderator