Home » Eclipse Projects » JavaServer Faces » Feedback on the proposal (BEA)
|
| Re: Feedback on the proposal (BEA) [message #469098 is a reply to message #469083] |
Tue, 26 July 2005 01:19   |
 Igor Shabalov
Messages: 38
Registered: July 2009 |
Member |
|
|
"John Rohrlich" <rohrlich@bea.com> wrote in message
news:dc3pd4$fsc$1@news.eclipse.org...
> -------- Tools Section
> 1. Add JSF Project nature to any Web Module
> Agree with IBM team - adding JSF should be done via the features framework
JSF project creation wizard? Support for multiply project templates, or may
be it is outside of the scope for specifically JSF tool?
>
> 3. Wizard for creating a new JSF Page
> - Question whether we need a wizard - Agree we should use the template -
> support.
> - JSF page creation should *also* create the backing bean. The template
> should support this as well so that the backing bean can automatically
> extend a class the user specifies.
> - JSF page and backing bean should be handled as unit for the user in
> respect to creation, deletion and rename.
This rise the question about "supported" architecture. Should we enforce
people to follow specific design pattern, or give them a choice? In general
JSF page does not require to have backing bean and can have a lot of
definitions directly on page. Or it can use BB very intensively. In fact,
one can create entire JSF application using pure Java/XML configurations,
without JSP at all.
>
>
> -------- Editors for JSF
> The proposal calls for two editors, one for JSP pages and one for
> faces-config.xml. I support having both editors but I think the big win
> will be if the user doesn't need to edit faces-config.xml. I think we
> should add to the proposal support for annotations that would reside in
> backing beans and perhaps in JSPs that would be used to generate
> config.xml. These annotations could also be used to generate struts
> mappings or used by other navigation code that vendors might implement.
> After all, JSF navigation, like all of JSF is pluggable.
I'd rather to concentrate on something very well defined, like faces-config,
and have it first.
What about Shale/Clay support?
>
> 3. Graphical Editor for JSF page
> I agree with the IBM feedback that this is a big ticket item but as I see
> JSF as largely a view technology I see this feature as critical to the
> success of the JSF Tooling Project
I do not think this is too critical for JSF Tooling Project. Good source
editor with code assist will do the trick.
>
> What does support for backing beans mean in this context?
>
> Would like to see us create wizards for those cases where round trip
> editing isn't likely but provide round trip editors where iteration is
> likely such as with data tables.
Pure standard DataTable? Or we are going to introduce some runtime
components to put some "common" functionality there, like Sun is doing in
Creator?
>
> John Rohrlich
> BEA Systems
> rohrlich@bea.com
Best,
Igor Shabalov,
Exadel Inc.
|
|
|
| Re: Feedback on the proposal (BEA) [message #469103 is a reply to message #469098] |
Wed, 27 July 2005 20:15 |
Raghu Srinivasan
Messages: 265
Registered: July 2009 |
Senior Member |
|
|
Hi,
Thanks for the feedback on the proposal. I have provided my comments to
each of the issues raised. Lets keep this thread alive!
-Raghu
Igor Shabalov wrote:
> "John Rohrlich" <rohrlich@bea.com> wrote in message
> news:dc3pd4$fsc$1@news.eclipse.org...
>
>>-------- Tools Section
>>1. Add JSF Project nature to any Web Module
>>Agree with IBM team - adding JSF should be done via the features framework
>
>
> JSF project creation wizard? Support for multiply project templates, or may
> be it is outside of the scope for specifically JSF tool?
>
Yes, I agree there is a need for a JSF Project Creation Wizard. What
types of information do you think we can capture and use in the wizard
and in the templates?
>
>
>>3. Wizard for creating a new JSF Page
>>- Question whether we need a wizard - Agree we should use the template -
>>support.
Not clear why you think we don't need a wizard. At minimum, a wizard
will allow user to choose a template, tag libs to include. Others could
extend the wizard with options to select binding options and provide for
generating a page based on some criteria.
>>- JSF page creation should *also* create the backing bean. The template
>>should support this as well so that the backing bean can automatically
>>extend a class the user specifies.
>>>This could be an option that the wizard will support.
>>- JSF page and backing bean should be handled as unit for the user in
>>respect to creation, deletion and rename.
>
>
> This rise the question about "supported" architecture. Should we enforce
> people to follow specific design pattern, or give them a choice? In general
> JSF page does not require to have backing bean and can have a lot of
> definitions directly on page. Or it can use BB very intensively. In fact,
> one can create entire JSF application using pure Java/XML configurations,
> without JSP at all.
>
Agree with Igor. We don't want to enforce a design pattern. This should
allow all the flexibility that is possible with JSF specfication.
However, we should explore the feature to handle the page and backing
bean as a single unit. Maybe a candidate for a later release?
>
>
>>
>>-------- Editors for JSF
>>The proposal calls for two editors, one for JSP pages and one for
>>faces-config.xml. I support having both editors but I think the big win
>>will be if the user doesn't need to edit faces-config.xml.
I think we all agree that this is the most value-add feature. We will
focus on getting this delivered in first release.
I think we
>>should add to the proposal support for annotations that would reside in
>>backing beans and perhaps in JSPs that would be used to generate
>>config.xml. These annotations could also be used to generate struts
>>mappings or used by other navigation code that vendors might implement.
>>After all, JSF navigation, like all of JSF is pluggable.
We should explore opportunities to use Annotations. This again looks
like a candidate for future release once we get the basic feature of
providing an usable editing experience for the application configuration
file. Maybe you can elaborate further on this so we see the benefit etc.
>
>
> I'd rather to concentrate on something very well defined, like faces-config,
> and have it first.
>
> What about Shale/Clay support?
>
>
>
>>3. Graphical Editor for JSF page
>>I agree with the IBM feedback that this is a big ticket item but as I see
>>JSF as largely a view technology I see this feature as critical to the
>>success of the JSF Tooling Project
>
>
> I do not think this is too critical for JSF Tooling Project. Good source
> editor with code assist will do the trick.
>
This is a feature for the next release, unless we get a lot of resources!
>
>>What does support for backing beans mean in this context?
In the proposal, this meant providing content assist.
>>
>>Would like to see us create wizards for those cases where round trip
>>editing isn't likely but provide round trip editors where iteration is
>>likely such as with data tables.
I am not clear on the 'round trip editor', can you please clarify? Also,
the statement implies that wizards and round trip editor are mutually
exclusive. Is that so?
>
> Pure standard DataTable? Or we are going to introduce some runtime
> components to put some "common" functionality there, like Sun is doing in
> Creator?
>
There could be no runtime component in WTP, so we will stick to the
standards.
>
>>John Rohrlich
>>BEA Systems
>>rohrlich@bea.com
>
>
>
> Best,
> Igor Shabalov,
> Exadel Inc.
>
>
Raghu Srinivasan,
Project Lead - JSF
|
|
| |
| Re: Feedback on the proposal (BEA) [message #469925 is a reply to message #469103] |
Tue, 09 August 2005 20:12 |
john rohrlich
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Sorry, to be so long in responding. I was on vacation.
- john
Raghu Srinivasan wrote:
> Hi,
>
> Thanks for the feedback on the proposal. I have provided my comments to
> each of the issues raised. Lets keep this thread alive!
> -Raghu
>
>
> Igor Shabalov wrote:
>
>> "John Rohrlich" <rohrlich@bea.com> wrote in message
>> news:dc3pd4$fsc$1@news.eclipse.org...
>>
>>> -------- Tools Section
>>> 1. Add JSF Project nature to any Web Module
>>> Agree with IBM team - adding JSF should be done via the features
>>> framework
>>
>>
>>
>> JSF project creation wizard? Support for multiply project templates,
>> or may be it is outside of the scope for specifically JSF tool?
>>
>
> Yes, I agree there is a need for a JSF Project Creation Wizard. What
> types of information do you think we can capture and use in the wizard
> and in the templates?
>
>>
>>
>>> 3. Wizard for creating a new JSF Page
>>> - Question whether we need a wizard - Agree we should use the
>>> template - support.
>
>
> Not clear why you think we don't need a wizard. At minimum, a wizard
> will allow user to choose a template, tag libs to include. Others could
> extend the wizard with options to select binding options and provide for
> generating a page based on some criteria.
>
>>> - JSF page creation should *also* create the backing bean. The
>>> template should support this as well so that the backing bean can
>>> automatically extend a class the user specifies.
>
>
>>>> This could be an option that the wizard will support.
>>>
>>> - JSF page and backing bean should be handled as unit for the user in
>>> respect to creation, deletion and rename.
>>
>>
>>
>> This rise the question about "supported" architecture. Should we
>> enforce people to follow specific design pattern, or give them a
>> choice? In general JSF page does not require to have backing bean and
>> can have a lot of definitions directly on page. Or it can use BB very
>> intensively. In fact, one can create entire JSF application using pure
>> Java/XML configurations, without JSP at all.
>>
>
> Agree with Igor. We don't want to enforce a design pattern. This should
> allow all the flexibility that is possible with JSF specfication.
> However, we should explore the feature to handle the page and backing
> bean as a single unit. Maybe a candidate for a later release?
>
[jr] I'm not suggesting that we force any specific design pattern but I
do think we should facilitate common ones and the backing bean is
common. In this case I would suggest that the creation of the backing
bean be optional but that we have good support for it. Having the IDE
help with rename and file add/delete is a real help when you do have use
backing files.
>>
>>
>>>
>>> -------- Editors for JSF
>>> The proposal calls for two editors, one for JSP pages and one for
>>> faces-config.xml. I support having both editors but I think the big
>>> win will be if the user doesn't need to edit faces-config.xml.
>
>
> I think we all agree that this is the most value-add feature. We will
> focus on getting this delivered in first release.
>
> I think we
>
>>> should add to the proposal support for annotations that would reside
>>> in backing beans and perhaps in JSPs that would be used to generate
>>> config.xml. These annotations could also be used to generate struts
>>> mappings or used by other navigation code that vendors might
>>> implement. After all, JSF navigation, like all of JSF is pluggable.
>
>
> We should explore opportunities to use Annotations. This again looks
> like a candidate for future release once we get the basic feature of
> providing an usable editing experience for the application configuration
> file. Maybe you can elaborate further on this so we see the benefit etc.
>
>>
>>
>> I'd rather to concentrate on something very well defined, like
>> faces-config, and have it first.
>>
>> What about Shale/Clay support?
>
>
>>
>>
>>
>>> 3. Graphical Editor for JSF page
>>> I agree with the IBM feedback that this is a big ticket item but as I
>>> see JSF as largely a view technology I see this feature as critical
>>> to the success of the JSF Tooling Project
>>
>>
>>
>> I do not think this is too critical for JSF Tooling Project. Good
>> source editor with code assist will do the trick.
>>
>
> This is a feature for the next release, unless we get a lot of resources!
>
[jr] I support putting this off until we can do it well.
>>
>>> What does support for backing beans mean in this context?
>
>
> In the proposal, this meant providing content assist.
>
>>>
>>> Would like to see us create wizards for those cases where round trip
>>> editing isn't likely but provide round trip editors where iteration
>>> is likely such as with data tables.
>
>
> I am not clear on the 'round trip editor', can you please clarify? Also,
> the statement implies that wizards and round trip editor are mutually
> exclusive. Is that so?
[jr] perhaps it is a matter of terminology. By round trip editing I mean
the capability to use a UI tool to generate code, have that code read
by that tool, use the tool again to generate code from where you left
off. If the wizard makes you start from scratch it is a one-way editing
tool rather than round trip.
>
>>
>> Pure standard DataTable? Or we are going to introduce some runtime
>> components to put some "common" functionality there, like Sun is doing
>> in Creator?
>>
>
> There could be no runtime component in WTP, so we will stick to the
> standards.
>
>>
>>> John Rohrlich
>>> BEA Systems
>>> rohrlich@bea.com
>>
>>
>>
>>
>> Best,
>> Igor Shabalov,
>> Exadel Inc.
>>
>
>
|
|
|
| Re: Feedback on the proposal (BEA) [message #567066 is a reply to message #469083] |
Tue, 26 July 2005 01:19 |
Igor Shabalov
Messages: 38
Registered: July 2009 |
Member |
|
|
"John Rohrlich" <rohrlich@bea.com> wrote in message
news:dc3pd4$fsc$1@news.eclipse.org...
> -------- Tools Section
> 1. Add JSF Project nature to any Web Module
> Agree with IBM team - adding JSF should be done via the features framework
JSF project creation wizard? Support for multiply project templates, or may
be it is outside of the scope for specifically JSF tool?
>
> 3. Wizard for creating a new JSF Page
> - Question whether we need a wizard - Agree we should use the template -
> support.
> - JSF page creation should *also* create the backing bean. The template
> should support this as well so that the backing bean can automatically
> extend a class the user specifies.
> - JSF page and backing bean should be handled as unit for the user in
> respect to creation, deletion and rename.
This rise the question about "supported" architecture. Should we enforce
people to follow specific design pattern, or give them a choice? In general
JSF page does not require to have backing bean and can have a lot of
definitions directly on page. Or it can use BB very intensively. In fact,
one can create entire JSF application using pure Java/XML configurations,
without JSP at all.
>
>
> -------- Editors for JSF
> The proposal calls for two editors, one for JSP pages and one for
> faces-config.xml. I support having both editors but I think the big win
> will be if the user doesn't need to edit faces-config.xml. I think we
> should add to the proposal support for annotations that would reside in
> backing beans and perhaps in JSPs that would be used to generate
> config.xml. These annotations could also be used to generate struts
> mappings or used by other navigation code that vendors might implement.
> After all, JSF navigation, like all of JSF is pluggable.
I'd rather to concentrate on something very well defined, like faces-config,
and have it first.
What about Shale/Clay support?
>
> 3. Graphical Editor for JSF page
> I agree with the IBM feedback that this is a big ticket item but as I see
> JSF as largely a view technology I see this feature as critical to the
> success of the JSF Tooling Project
I do not think this is too critical for JSF Tooling Project. Good source
editor with code assist will do the trick.
>
> What does support for backing beans mean in this context?
>
> Would like to see us create wizards for those cases where round trip
> editing isn't likely but provide round trip editors where iteration is
> likely such as with data tables.
Pure standard DataTable? Or we are going to introduce some runtime
components to put some "common" functionality there, like Sun is doing in
Creator?
>
> John Rohrlich
> BEA Systems
> rohrlich@bea.com
Best,
Igor Shabalov,
Exadel Inc.
|
|
|
| Re: Feedback on the proposal (BEA) [message #567117 is a reply to message #469098] |
Wed, 27 July 2005 20:15 |
Raghu Srinivasan
Messages: 265
Registered: July 2009 |
Senior Member |
|
|
Hi,
Thanks for the feedback on the proposal. I have provided my comments to
each of the issues raised. Lets keep this thread alive!
-Raghu
Igor Shabalov wrote:
> "John Rohrlich" <rohrlich@bea.com> wrote in message
> news:dc3pd4$fsc$1@news.eclipse.org...
>
>>-------- Tools Section
>>1. Add JSF Project nature to any Web Module
>>Agree with IBM team - adding JSF should be done via the features framework
>
>
> JSF project creation wizard? Support for multiply project templates, or may
> be it is outside of the scope for specifically JSF tool?
>
Yes, I agree there is a need for a JSF Project Creation Wizard. What
types of information do you think we can capture and use in the wizard
and in the templates?
>
>
>>3. Wizard for creating a new JSF Page
>>- Question whether we need a wizard - Agree we should use the template -
>>support.
Not clear why you think we don't need a wizard. At minimum, a wizard
will allow user to choose a template, tag libs to include. Others could
extend the wizard with options to select binding options and provide for
generating a page based on some criteria.
>>- JSF page creation should *also* create the backing bean. The template
>>should support this as well so that the backing bean can automatically
>>extend a class the user specifies.
>>>This could be an option that the wizard will support.
>>- JSF page and backing bean should be handled as unit for the user in
>>respect to creation, deletion and rename.
>
>
> This rise the question about "supported" architecture. Should we enforce
> people to follow specific design pattern, or give them a choice? In general
> JSF page does not require to have backing bean and can have a lot of
> definitions directly on page. Or it can use BB very intensively. In fact,
> one can create entire JSF application using pure Java/XML configurations,
> without JSP at all.
>
Agree with Igor. We don't want to enforce a design pattern. This should
allow all the flexibility that is possible with JSF specfication.
However, we should explore the feature to handle the page and backing
bean as a single unit. Maybe a candidate for a later release?
>
>
>>
>>-------- Editors for JSF
>>The proposal calls for two editors, one for JSP pages and one for
>>faces-config.xml. I support having both editors but I think the big win
>>will be if the user doesn't need to edit faces-config.xml.
I think we all agree that this is the most value-add feature. We will
focus on getting this delivered in first release.
I think we
>>should add to the proposal support for annotations that would reside in
>>backing beans and perhaps in JSPs that would be used to generate
>>config.xml. These annotations could also be used to generate struts
>>mappings or used by other navigation code that vendors might implement.
>>After all, JSF navigation, like all of JSF is pluggable.
We should explore opportunities to use Annotations. This again looks
like a candidate for future release once we get the basic feature of
providing an usable editing experience for the application configuration
file. Maybe you can elaborate further on this so we see the benefit etc.
>
>
> I'd rather to concentrate on something very well defined, like faces-config,
> and have it first.
>
> What about Shale/Clay support?
>
>
>
>>3. Graphical Editor for JSF page
>>I agree with the IBM feedback that this is a big ticket item but as I see
>>JSF as largely a view technology I see this feature as critical to the
>>success of the JSF Tooling Project
>
>
> I do not think this is too critical for JSF Tooling Project. Good source
> editor with code assist will do the trick.
>
This is a feature for the next release, unless we get a lot of resources!
>
>>What does support for backing beans mean in this context?
In the proposal, this meant providing content assist.
>>
>>Would like to see us create wizards for those cases where round trip
>>editing isn't likely but provide round trip editors where iteration is
>>likely such as with data tables.
I am not clear on the 'round trip editor', can you please clarify? Also,
the statement implies that wizards and round trip editor are mutually
exclusive. Is that so?
>
> Pure standard DataTable? Or we are going to introduce some runtime
> components to put some "common" functionality there, like Sun is doing in
> Creator?
>
There could be no runtime component in WTP, so we will stick to the
standards.
>
>>John Rohrlich
>>BEA Systems
>>rohrlich@bea.com
>
>
>
> Best,
> Igor Shabalov,
> Exadel Inc.
>
>
Raghu Srinivasan,
Project Lead - JSF
|
|
| |
| Re: Feedback on the proposal (BEA) [message #570628 is a reply to message #469103] |
Tue, 09 August 2005 20:12 |
john rohrlich
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Sorry, to be so long in responding. I was on vacation.
- john
Raghu Srinivasan wrote:
> Hi,
>
> Thanks for the feedback on the proposal. I have provided my comments to
> each of the issues raised. Lets keep this thread alive!
> -Raghu
>
>
> Igor Shabalov wrote:
>
>> "John Rohrlich" <rohrlich@bea.com> wrote in message
>> news:dc3pd4$fsc$1@news.eclipse.org...
>>
>>> -------- Tools Section
>>> 1. Add JSF Project nature to any Web Module
>>> Agree with IBM team - adding JSF should be done via the features
>>> framework
>>
>>
>>
>> JSF project creation wizard? Support for multiply project templates,
>> or may be it is outside of the scope for specifically JSF tool?
>>
>
> Yes, I agree there is a need for a JSF Project Creation Wizard. What
> types of information do you think we can capture and use in the wizard
> and in the templates?
>
>>
>>
>>> 3. Wizard for creating a new JSF Page
>>> - Question whether we need a wizard - Agree we should use the
>>> template - support.
>
>
> Not clear why you think we don't need a wizard. At minimum, a wizard
> will allow user to choose a template, tag libs to include. Others could
> extend the wizard with options to select binding options and provide for
> generating a page based on some criteria.
>
>>> - JSF page creation should *also* create the backing bean. The
>>> template should support this as well so that the backing bean can
>>> automatically extend a class the user specifies.
>
>
>>>> This could be an option that the wizard will support.
>>>
>>> - JSF page and backing bean should be handled as unit for the user in
>>> respect to creation, deletion and rename.
>>
>>
>>
>> This rise the question about "supported" architecture. Should we
>> enforce people to follow specific design pattern, or give them a
>> choice? In general JSF page does not require to have backing bean and
>> can have a lot of definitions directly on page. Or it can use BB very
>> intensively. In fact, one can create entire JSF application using pure
>> Java/XML configurations, without JSP at all.
>>
>
> Agree with Igor. We don't want to enforce a design pattern. This should
> allow all the flexibility that is possible with JSF specfication.
> However, we should explore the feature to handle the page and backing
> bean as a single unit. Maybe a candidate for a later release?
>
[jr] I'm not suggesting that we force any specific design pattern but I
do think we should facilitate common ones and the backing bean is
common. In this case I would suggest that the creation of the backing
bean be optional but that we have good support for it. Having the IDE
help with rename and file add/delete is a real help when you do have use
backing files.
>>
>>
>>>
>>> -------- Editors for JSF
>>> The proposal calls for two editors, one for JSP pages and one for
>>> faces-config.xml. I support having both editors but I think the big
>>> win will be if the user doesn't need to edit faces-config.xml.
>
>
> I think we all agree that this is the most value-add feature. We will
> focus on getting this delivered in first release.
>
> I think we
>
>>> should add to the proposal support for annotations that would reside
>>> in backing beans and perhaps in JSPs that would be used to generate
>>> config.xml. These annotations could also be used to generate struts
>>> mappings or used by other navigation code that vendors might
>>> implement. After all, JSF navigation, like all of JSF is pluggable.
>
>
> We should explore opportunities to use Annotations. This again looks
> like a candidate for future release once we get the basic feature of
> providing an usable editing experience for the application configuration
> file. Maybe you can elaborate further on this so we see the benefit etc.
>
>>
>>
>> I'd rather to concentrate on something very well defined, like
>> faces-config, and have it first.
>>
>> What about Shale/Clay support?
>
>
>>
>>
>>
>>> 3. Graphical Editor for JSF page
>>> I agree with the IBM feedback that this is a big ticket item but as I
>>> see JSF as largely a view technology I see this feature as critical
>>> to the success of the JSF Tooling Project
>>
>>
>>
>> I do not think this is too critical for JSF Tooling Project. Good
>> source editor with code assist will do the trick.
>>
>
> This is a feature for the next release, unless we get a lot of resources!
>
[jr] I support putting this off until we can do it well.
>>
>>> What does support for backing beans mean in this context?
>
>
> In the proposal, this meant providing content assist.
>
>>>
>>> Would like to see us create wizards for those cases where round trip
>>> editing isn't likely but provide round trip editors where iteration
>>> is likely such as with data tables.
>
>
> I am not clear on the 'round trip editor', can you please clarify? Also,
> the statement implies that wizards and round trip editor are mutually
> exclusive. Is that so?
[jr] perhaps it is a matter of terminology. By round trip editing I mean
the capability to use a UI tool to generate code, have that code read
by that tool, use the tool again to generate code from where you left
off. If the wizard makes you start from scratch it is a one-way editing
tool rather than round trip.
>
>>
>> Pure standard DataTable? Or we are going to introduce some runtime
>> components to put some "common" functionality there, like Sun is doing
>> in Creator?
>>
>
> There could be no runtime component in WTP, so we will stick to the
> standards.
>
>>
>>> John Rohrlich
>>> BEA Systems
>>> rohrlich@bea.com
>>
>>
>>
>>
>> Best,
>> Igor Shabalov,
>> Exadel Inc.
>>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 22:29:06 GMT 2024
Powered by FUDForum. Page generated in 0.03736 seconds |
] 
Search
Help
Register
Login
Home
