springframework-developer

[Springframework-developer] Portlet Form Controllers

[John L. <jl...@ar...>]

We've been working on porting a fairly complex enterprise application 
from the Spring Servlet MVC framework to the Spring Portlet MVC 
framework.  As Nick Lothian and Rainer Schmitz discovered, the Form 
Controller hierarchy is difficult to port over from the Servlet area to 
the Portlet area because of the two-phase nature of portlet requests. 
Since we were porting a large number of existing controllers descended 
from AbstractController, AbstractFormController, or 
SimpleFormController, it was critical to that all the former 
functionality of these parent be present and that our logic work the 
same as before.

Nick Lothian's version of SimplePortletFormController gave us a good 
starting point and helped us understand a lot of the issues with portlet 
development in general and with Spring portlets in particular.  However, 
a lot of our controllers manage database content, so we needed proper 
separation between the action and render phase of the request, which 
this controller did not give us.

Rainer Schmitz's work went much further and provided the traditional 
hierarchy of controllers and further demonstrated the issues with 
separating out the two phases of the portlet request.  However, these 
still did not give us the complete control that we needed.  We 
especially needed a version of SimpleFormController that could handle 
the separation of the action logic from the render logic.

Over the past few months we have developed a new set of the 
AbstractController, BaseCommandController, AbstractFormController, and 
SimpleFormController classes that we think rigorously address all the 
issues with portlet development and that have allowed us to port over 
existing servlet controllers with relative ease.

We've included a portlet version of WebContentGenerator to give the 
controller classes their proper ancestry and provide control over things 
like content caching and access to the web application context and to 
centralized logging.

We've also create a new set of the binding classes 
(PortletRequestDataBinder, PortletRequestParameterPropertyValues and 
PortletRequestBindingException) that support special field markers, 
correct problems with form elements such as radio buttons and 
checkboxes, and handle redisplay of invalid submits of non-string 
parameters properly.

All of the classes are fully documented, including workflow descriptions 
in the controllers that cover the special nature of portlet development.

Our hope is that these classes can handle the needs of everyone working 
with form controllers in Spring portlets and that these can be merged 
into the sandbox source code.

The classes are posted in a zip file on the Spring Portlet Wiki page at:
http://opensource.atlassian.com/confluence/spring/display/JSR168/

The link to the file is (sorry for the long link):
http://opensource.atlassian.com/confluence/spring/download/attachments/10/spring-portlet-controllers.zip

Please send me any questions or comments you may have about these 
classes.  We are eager to support their adoption in the Spring Portlet 
community.

John Lewis
jl...@ar...

Re: [Springframework-developer] Portlet Form Controllers

[Juergen H. <ju...@in...>]

Sounds like good stuff :-)

On this occasion: Let's discuss the road to an official release of the
Portlet support. We consider releasing the Portlet support as an official
subproject, i.e. as a separate distribution and with a separate CVS module
(or even separate CVS repository). The association would be similar to the
just-announced Spring subproject status of Acegi Security, and the already
established status of Spring RCP.

Very importantly, the portlet subproject needs a dedicated developer team.
Any volunteers? :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of John Lewis
Sent: Thursday, March 03, 2005 6:53 PM
To: spr...@li...
Subject: [Springframework-developer] Portlet Form Controllers


We've been working on porting a fairly complex enterprise application
from the Spring Servlet MVC framework to the Spring Portlet MVC
framework.  As Nick Lothian and Rainer Schmitz discovered, the Form
Controller hierarchy is difficult to port over from the Servlet area to
the Portlet area because of the two-phase nature of portlet requests.
Since we were porting a large number of existing controllers descended
from AbstractController, AbstractFormController, or
SimpleFormController, it was critical to that all the former
functionality of these parent be present and that our logic work the
same as before.

Nick Lothian's version of SimplePortletFormController gave us a good
starting point and helped us understand a lot of the issues with portlet
development in general and with Spring portlets in particular.  However,
a lot of our controllers manage database content, so we needed proper
separation between the action and render phase of the request, which
this controller did not give us.

Rainer Schmitz's work went much further and provided the traditional
hierarchy of controllers and further demonstrated the issues with
separating out the two phases of the portlet request.  However, these
still did not give us the complete control that we needed.  We
especially needed a version of SimpleFormController that could handle
the separation of the action logic from the render logic.

Over the past few months we have developed a new set of the
AbstractController, BaseCommandController, AbstractFormController, and
SimpleFormController classes that we think rigorously address all the
issues with portlet development and that have allowed us to port over
existing servlet controllers with relative ease.

We've included a portlet version of WebContentGenerator to give the
controller classes their proper ancestry and provide control over things
like content caching and access to the web application context and to
centralized logging.

We've also create a new set of the binding classes
(PortletRequestDataBinder, PortletRequestParameterPropertyValues and
PortletRequestBindingException) that support special field markers,
correct problems with form elements such as radio buttons and
checkboxes, and handle redisplay of invalid submits of non-string
parameters properly.

All of the classes are fully documented, including workflow descriptions
in the controllers that cover the special nature of portlet development.

Our hope is that these classes can handle the needs of everyone working
with form controllers in Spring portlets and that these can be merged
into the sandbox source code.

The classes are posted in a zip file on the Spring Portlet Wiki page at:
http://opensource.atlassian.com/confluence/spring/display/JSR168/

The link to the file is (sorry for the long link):
http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp
ring-portlet-controllers.zip

Please send me any questions or comments you may have about these
classes.  We are eager to support their adoption in the Spring Portlet
community.

John Lewis
jl...@ar...



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet Form Controllers

[Rob B. <cro...@ya...>]

Why would you have a separate sub-project for the
portlet support in Spring?  That would be like having
a separate sub-project for the web MVC stuff, and a
separate sub-project for the DAO related stuff, and
another one for AOP, etc.

Later
Rob
--- Juergen Hoeller <ju...@in...> wrote:

> Sounds like good stuff :-)
> 
> On this occasion: Let's discuss the road to an
> official release of the
> Portlet support. We consider releasing the Portlet
> support as an official
> subproject, i.e. as a separate distribution and with
> a separate CVS module
> (or even separate CVS repository). The association
> would be similar to the
> just-announced Spring subproject status of Acegi
> Security, and the already
> established status of Spring RCP.
> 
> Very importantly, the portlet subproject needs a
> dedicated developer team.
> Any volunteers? :-)
> 
> Juergen
> 
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]On
> Behalf
> Of John Lewis
> Sent: Thursday, March 03, 2005 6:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] Portlet Form
> Controllers
> 
> 
> We've been working on porting a fairly complex
> enterprise application
> from the Spring Servlet MVC framework to the Spring
> Portlet MVC
> framework.  As Nick Lothian and Rainer Schmitz
> discovered, the Form
> Controller hierarchy is difficult to port over from
> the Servlet area to
> the Portlet area because of the two-phase nature of
> portlet requests.
> Since we were porting a large number of existing
> controllers descended
> from AbstractController, AbstractFormController, or
> SimpleFormController, it was critical to that all
> the former
> functionality of these parent be present and that
> our logic work the
> same as before.
> 
> Nick Lothian's version of
> SimplePortletFormController gave us a good
> starting point and helped us understand a lot of the
> issues with portlet
> development in general and with Spring portlets in
> particular.  However,
> a lot of our controllers manage database content, so
> we needed proper
> separation between the action and render phase of
> the request, which
> this controller did not give us.
> 
> Rainer Schmitz's work went much further and provided
> the traditional
> hierarchy of controllers and further demonstrated
> the issues with
> separating out the two phases of the portlet
> request.  However, these
> still did not give us the complete control that we
> needed.  We
> especially needed a version of SimpleFormController
> that could handle
> the separation of the action logic from the render
> logic.
> 
> Over the past few months we have developed a new set
> of the
> AbstractController, BaseCommandController,
> AbstractFormController, and
> SimpleFormController classes that we think
> rigorously address all the
> issues with portlet development and that have
> allowed us to port over
> existing servlet controllers with relative ease.
> 
> We've included a portlet version of
> WebContentGenerator to give the
> controller classes their proper ancestry and provide
> control over things
> like content caching and access to the web
> application context and to
> centralized logging.
> 
> We've also create a new set of the binding classes
> (PortletRequestDataBinder,
> PortletRequestParameterPropertyValues and
> PortletRequestBindingException) that support special
> field markers,
> correct problems with form elements such as radio
> buttons and
> checkboxes, and handle redisplay of invalid submits
> of non-string
> parameters properly.
> 
> All of the classes are fully documented, including
> workflow descriptions
> in the controllers that cover the special nature of
> portlet development.
> 
> Our hope is that these classes can handle the needs
> of everyone working
> with form controllers in Spring portlets and that
> these can be merged
> into the sandbox source code.
> 
> The classes are posted in a zip file on the Spring
> Portlet Wiki page at:
>
http://opensource.atlassian.com/confluence/spring/display/JSR168/
> 
> The link to the file is (sorry for the long link):
>
http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp
> ring-portlet-controllers.zip
> 
> Please send me any questions or comments you may
> have about these
> classes.  We are eager to support their adoption in
> the Spring Portlet
> community.
> 
> John Lewis
> jl...@ar...
> 
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: [Springframework-developer] Portlet Form Controllers

[Jean-Pol L. <jea...@sk...>]

I quite agree with Rob. Except, of course, if you plan to create a=20
subproject for Spring MVC too. This would allow a Spring "=E0 la carte".
This would keep the framework light, but would perhaps be a bit confusing=
 to=20
the users. Perhaps a "plugin" functionnality would be nice if the number =
of=20
projects grows : you would have a core Spring and be able to plug in, for=
=20
example by using a dedicated XML file, the other sub-projects you want to=
=20
use. That's just an idea.

Cheers,
Jean-Pol.

----- Original Message -----=20
From: "Rob Butler" <cro...@ya...>
To: <spr...@li...>
Sent: Friday, March 04, 2005 7:01 PM
Subject: Re: [Springframework-developer] Portlet Form Controllers


> Why would you have a separate sub-project for the
> portlet support in Spring?  That would be like having
> a separate sub-project for the web MVC stuff, and a
> separate sub-project for the DAO related stuff, and
> another one for AOP, etc.
>
> Later
> Rob
> --- Juergen Hoeller <ju...@in...> wrote:
>
>> Sounds like good stuff :-)
>>
>> On this occasion: Let's discuss the road to an
>> official release of the
>> Portlet support. We consider releasing the Portlet
>> support as an official
>> subproject, i.e. as a separate distribution and with
>> a separate CVS module
>> (or even separate CVS repository). The association
>> would be similar to the
>> just-announced Spring subproject status of Acegi
>> Security, and the already
>> established status of Spring RCP.
>>
>> Very importantly, the portlet subproject needs a
>> dedicated developer team.
>> Any volunteers? :-)
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From:
>>
> spr...@li...
>>
> [mailto:spr...@li...]On
>> Behalf
>> Of John Lewis
>> Sent: Thursday, March 03, 2005 6:53 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] Portlet Form
>> Controllers
>>
>>
>> We've been working on porting a fairly complex
>> enterprise application
>> from the Spring Servlet MVC framework to the Spring
>> Portlet MVC
>> framework.  As Nick Lothian and Rainer Schmitz
>> discovered, the Form
>> Controller hierarchy is difficult to port over from
>> the Servlet area to
>> the Portlet area because of the two-phase nature of
>> portlet requests.
>> Since we were porting a large number of existing
>> controllers descended
>> from AbstractController, AbstractFormController, or
>> SimpleFormController, it was critical to that all
>> the former
>> functionality of these parent be present and that
>> our logic work the
>> same as before.
>>
>> Nick Lothian's version of
>> SimplePortletFormController gave us a good
>> starting point and helped us understand a lot of the
>> issues with portlet
>> development in general and with Spring portlets in
>> particular.  However,
>> a lot of our controllers manage database content, so
>> we needed proper
>> separation between the action and render phase of
>> the request, which
>> this controller did not give us.
>>
>> Rainer Schmitz's work went much further and provided
>> the traditional
>> hierarchy of controllers and further demonstrated
>> the issues with
>> separating out the two phases of the portlet
>> request.  However, these
>> still did not give us the complete control that we
>> needed.  We
>> especially needed a version of SimpleFormController
>> that could handle
>> the separation of the action logic from the render
>> logic.
>>
>> Over the past few months we have developed a new set
>> of the
>> AbstractController, BaseCommandController,
>> AbstractFormController, and
>> SimpleFormController classes that we think
>> rigorously address all the
>> issues with portlet development and that have
>> allowed us to port over
>> existing servlet controllers with relative ease.
>>
>> We've included a portlet version of
>> WebContentGenerator to give the
>> controller classes their proper ancestry and provide
>> control over things
>> like content caching and access to the web
>> application context and to
>> centralized logging.
>>
>> We've also create a new set of the binding classes
>> (PortletRequestDataBinder,
>> PortletRequestParameterPropertyValues and
>> PortletRequestBindingException) that support special
>> field markers,
>> correct problems with form elements such as radio
>> buttons and
>> checkboxes, and handle redisplay of invalid submits
>> of non-string
>> parameters properly.
>>
>> All of the classes are fully documented, including
>> workflow descriptions
>> in the controllers that cover the special nature of
>> portlet development.
>>
>> Our hope is that these classes can handle the needs
>> of everyone working
>> with form controllers in Spring portlets and that
>> these can be merged
>> into the sandbox source code.
>>
>> The classes are posted in a zip file on the Spring
>> Portlet Wiki page at:
>>
> http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>
>> The link to the file is (sorry for the long link):
>>
> http://opensource.atlassian.com/confluence/spring/download/attachments/=
10/sp
>> ring-portlet-controllers.zip
>>
>> Please send me any questions or comments you may
>> have about these
>> classes.  We are eager to support their adoption in
>> the Spring Portlet
>> community.
>>
>> John Lewis
>> jl...@ar...
>>
>>
>>
>>
> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT
>> Products from real users.
>> Discover which products truly live up to the hype.
>> Start reading now.
>>
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT
>> Products from real users.
>> Discover which products truly live up to the hype.
>> Start reading now.
>>
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] Portlet Form Controllers

[Juergen H. <ju...@in...>]

As I said, a subproject is just under consideration. The alternative is to
release the portlet support as part of the core Spring 1.3 distribution. The
rationale of factoring out subprojects is to let the core concentrate on its
current scope and not introduce completely new areas of functionality. A
secondary goal is to limit the size of spring.jar.

The current core web support and web MVC framework is used by the portlet
support underneath, for example to render views (at least that was the case
last year). So Spring Portlet depends on Spring core web (even core web
MVC), but not the other way round: a case for core web MVC staying part of
the core distribution, but Portlet support (optionally) becoming a separate
subproject.

Note that Spring's core web support is of interest to many people: not only
to web application people, but also to rich client developers accessing
HTTP-based remote services (running in a Servlet container). Portlet support
is more specific and has a narrower target audience.

A further advantage of a separate subproject is that it can evolve more
easily. Specific sample applications, tutorials, tools etc can be added
without having to worry about scope or size of the core Spring distribution.

Anyway, this has not been decided yet and does not have to be decided right
now. It's gonna become an important topic after the Spring 1.2 release,
though.

Juergen



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Jean-Pol Landrain
Sent: Friday, March 04, 2005 7:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet Form Controllers


I quite agree with Rob. Except, of course, if you plan to create a
subproject for Spring MVC too. This would allow a Spring "à la carte".
This would keep the framework light, but would perhaps be a bit confusing to
the users. Perhaps a "plugin" functionnality would be nice if the number of
projects grows : you would have a core Spring and be able to plug in, for
example by using a dedicated XML file, the other sub-projects you want to
use. That's just an idea.

Cheers,
Jean-Pol.

----- Original Message -----
From: "Rob Butler" <cro...@ya...>
To: <spr...@li...>
Sent: Friday, March 04, 2005 7:01 PM
Subject: Re: [Springframework-developer] Portlet Form Controllers


> Why would you have a separate sub-project for the
> portlet support in Spring?  That would be like having
> a separate sub-project for the web MVC stuff, and a
> separate sub-project for the DAO related stuff, and
> another one for AOP, etc.
>
> Later
> Rob
> --- Juergen Hoeller <ju...@in...> wrote:
>
>> Sounds like good stuff :-)
>>
>> On this occasion: Let's discuss the road to an
>> official release of the
>> Portlet support. We consider releasing the Portlet
>> support as an official
>> subproject, i.e. as a separate distribution and with
>> a separate CVS module
>> (or even separate CVS repository). The association
>> would be similar to the
>> just-announced Spring subproject status of Acegi
>> Security, and the already
>> established status of Spring RCP.
>>
>> Very importantly, the portlet subproject needs a
>> dedicated developer team.
>> Any volunteers? :-)
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From:
>>
> spr...@li...
>>
> [mailto:spr...@li...]On
>> Behalf
>> Of John Lewis
>> Sent: Thursday, March 03, 2005 6:53 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] Portlet Form
>> Controllers
>>
>>
>> We've been working on porting a fairly complex
>> enterprise application
>> from the Spring Servlet MVC framework to the Spring
>> Portlet MVC
>> framework.  As Nick Lothian and Rainer Schmitz
>> discovered, the Form
>> Controller hierarchy is difficult to port over from
>> the Servlet area to
>> the Portlet area because of the two-phase nature of
>> portlet requests.
>> Since we were porting a large number of existing
>> controllers descended
>> from AbstractController, AbstractFormController, or
>> SimpleFormController, it was critical to that all
>> the former
>> functionality of these parent be present and that
>> our logic work the
>> same as before.
>>
>> Nick Lothian's version of
>> SimplePortletFormController gave us a good
>> starting point and helped us understand a lot of the
>> issues with portlet
>> development in general and with Spring portlets in
>> particular.  However,
>> a lot of our controllers manage database content, so
>> we needed proper
>> separation between the action and render phase of
>> the request, which
>> this controller did not give us.
>>
>> Rainer Schmitz's work went much further and provided
>> the traditional
>> hierarchy of controllers and further demonstrated
>> the issues with
>> separating out the two phases of the portlet
>> request.  However, these
>> still did not give us the complete control that we
>> needed.  We
>> especially needed a version of SimpleFormController
>> that could handle
>> the separation of the action logic from the render
>> logic.
>>
>> Over the past few months we have developed a new set
>> of the
>> AbstractController, BaseCommandController,
>> AbstractFormController, and
>> SimpleFormController classes that we think
>> rigorously address all the
>> issues with portlet development and that have
>> allowed us to port over
>> existing servlet controllers with relative ease.
>>
>> We've included a portlet version of
>> WebContentGenerator to give the
>> controller classes their proper ancestry and provide
>> control over things
>> like content caching and access to the web
>> application context and to
>> centralized logging.
>>
>> We've also create a new set of the binding classes
>> (PortletRequestDataBinder,
>> PortletRequestParameterPropertyValues and
>> PortletRequestBindingException) that support special
>> field markers,
>> correct problems with form elements such as radio
>> buttons and
>> checkboxes, and handle redisplay of invalid submits
>> of non-string
>> parameters properly.
>>
>> All of the classes are fully documented, including
>> workflow descriptions
>> in the controllers that cover the special nature of
>> portlet development.
>>
>> Our hope is that these classes can handle the needs
>> of everyone working
>> with form controllers in Spring portlets and that
>> these can be merged
>> into the sandbox source code.
>>
>> The classes are posted in a zip file on the Spring
>> Portlet Wiki page at:
>>
> http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>
>> The link to the file is (sorry for the long link):
>>
>
http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp
>> ring-portlet-controllers.zip
>>
>> Please send me any questions or comments you may
>> have about these
>> classes.  We are eager to support their adoption in
>> the Spring Portlet
>> community.
>>
>> John Lewis
>> jl...@ar...
>>
>>
>>
>>
> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT
>> Products from real users.
>> Discover which products truly live up to the hype.
>> Start reading now.
>>
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT
>> Products from real users.
>> Discover which products truly live up to the hype.
>> Start reading now.
>>
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet Form Controllers

[Ken K. <kk...@kk...>]

+1 for subproject status.
It makes sense to me to let them evolve in a more loosely coupled way,=20
especially as Juergen points out given the small target audience for=20
portlets.

Juergen Hoeller wrote:

>As I said, a subproject is just under consideration. The alternative is =
to
>release the portlet support as part of the core Spring 1.3 distribution.=
 The
>rationale of factoring out subprojects is to let the core concentrate on=
 its
>current scope and not introduce completely new areas of functionality. A
>secondary goal is to limit the size of spring.jar.
>
>The current core web support and web MVC framework is used by the portle=
t
>support underneath, for example to render views (at least that was the c=
ase
>last year). So Spring Portlet depends on Spring core web (even core web
>MVC), but not the other way round: a case for core web MVC staying part =
of
>the core distribution, but Portlet support (optionally) becoming a separ=
ate
>subproject.
>
>Note that Spring's core web support is of interest to many people: not o=
nly
>to web application people, but also to rich client developers accessing
>HTTP-based remote services (running in a Servlet container). Portlet sup=
port
>is more specific and has a narrower target audience.
>
>A further advantage of a separate subproject is that it can evolve more
>easily. Specific sample applications, tutorials, tools etc can be added
>without having to worry about scope or size of the core Spring distribut=
ion.
>
>Anyway, this has not been decided yet and does not have to be decided ri=
ght
>now. It's gonna become an important topic after the Spring 1.2 release,
>though.
>
>Juergen
>
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Jean-Pol Landrain
>Sent: Friday, March 04, 2005 7:29 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
>I quite agree with Rob. Except, of course, if you plan to create a
>subproject for Spring MVC too. This would allow a Spring "=E0 la carte".
>This would keep the framework light, but would perhaps be a bit confusin=
g to
>the users. Perhaps a "plugin" functionnality would be nice if the number=
 of
>projects grows : you would have a core Spring and be able to plug in, fo=
r
>example by using a dedicated XML file, the other sub-projects you want t=
o
>use. That's just an idea.
>
>Cheers,
>Jean-Pol.
>
>----- Original Message -----
>From: "Rob Butler" <cro...@ya...>
>To: <spr...@li...>
>Sent: Friday, March 04, 2005 7:01 PM
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
> =20
>
>>Why would you have a separate sub-project for the
>>portlet support in Spring?  That would be like having
>>a separate sub-project for the web MVC stuff, and a
>>separate sub-project for the DAO related stuff, and
>>another one for AOP, etc.
>>
>>Later
>>Rob
>>--- Juergen Hoeller <ju...@in...> wrote:
>>
>>   =20
>>
>>>Sounds like good stuff :-)
>>>
>>>On this occasion: Let's discuss the road to an
>>>official release of the
>>>Portlet support. We consider releasing the Portlet
>>>support as an official
>>>subproject, i.e. as a separate distribution and with
>>>a separate CVS module
>>>(or even separate CVS repository). The association
>>>would be similar to the
>>>just-announced Spring subproject status of Acegi
>>>Security, and the already
>>>established status of Spring RCP.
>>>
>>>Very importantly, the portlet subproject needs a
>>>dedicated developer team.
>>>Any volunteers? :-)
>>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From:
>>>
>>>     =20
>>>
>>spr...@li...
>>   =20
>>
>>[mailto:spr...@li...]On
>>   =20
>>
>>>Behalf
>>>Of John Lewis
>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>To: spr...@li...
>>>Subject: [Springframework-developer] Portlet Form
>>>Controllers
>>>
>>>
>>>We've been working on porting a fairly complex
>>>enterprise application
>>>from the Spring Servlet MVC framework to the Spring
>>>Portlet MVC
>>>framework.  As Nick Lothian and Rainer Schmitz
>>>discovered, the Form
>>>Controller hierarchy is difficult to port over from
>>>the Servlet area to
>>>the Portlet area because of the two-phase nature of
>>>portlet requests.
>>>Since we were porting a large number of existing
>>>controllers descended
>>>from AbstractController, AbstractFormController, or
>>>SimpleFormController, it was critical to that all
>>>the former
>>>functionality of these parent be present and that
>>>our logic work the
>>>same as before.
>>>
>>>Nick Lothian's version of
>>>SimplePortletFormController gave us a good
>>>starting point and helped us understand a lot of the
>>>issues with portlet
>>>development in general and with Spring portlets in
>>>particular.  However,
>>>a lot of our controllers manage database content, so
>>>we needed proper
>>>separation between the action and render phase of
>>>the request, which
>>>this controller did not give us.
>>>
>>>Rainer Schmitz's work went much further and provided
>>>the traditional
>>>hierarchy of controllers and further demonstrated
>>>the issues with
>>>separating out the two phases of the portlet
>>>request.  However, these
>>>still did not give us the complete control that we
>>>needed.  We
>>>especially needed a version of SimpleFormController
>>>that could handle
>>>the separation of the action logic from the render
>>>logic.
>>>
>>>Over the past few months we have developed a new set
>>>of the
>>>AbstractController, BaseCommandController,
>>>AbstractFormController, and
>>>SimpleFormController classes that we think
>>>rigorously address all the
>>>issues with portlet development and that have
>>>allowed us to port over
>>>existing servlet controllers with relative ease.
>>>
>>>We've included a portlet version of
>>>WebContentGenerator to give the
>>>controller classes their proper ancestry and provide
>>>control over things
>>>like content caching and access to the web
>>>application context and to
>>>centralized logging.
>>>
>>>We've also create a new set of the binding classes
>>>(PortletRequestDataBinder,
>>>PortletRequestParameterPropertyValues and
>>>PortletRequestBindingException) that support special
>>>field markers,
>>>correct problems with form elements such as radio
>>>buttons and
>>>checkboxes, and handle redisplay of invalid submits
>>>of non-string
>>>parameters properly.
>>>
>>>All of the classes are fully documented, including
>>>workflow descriptions
>>>in the controllers that cover the special nature of
>>>portlet development.
>>>
>>>Our hope is that these classes can handle the needs
>>>of everyone working
>>>with form controllers in Spring portlets and that
>>>these can be merged
>>>into the sandbox source code.
>>>
>>>The classes are posted in a zip file on the Spring
>>>Portlet Wiki page at:
>>>
>>>     =20
>>>
>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>   =20
>>
>>>The link to the file is (sorry for the long link):
>>>
>>>     =20
>>>
>http://opensource.atlassian.com/confluence/spring/download/attachments/1=
0/sp
> =20
>
>>>ring-portlet-controllers.zip
>>>
>>>Please send me any questions or comments you may
>>>have about these
>>>classes.  We are eager to support their adoption in
>>>the Spring Portlet
>>>community.
>>>
>>>John Lewis
>>>jl...@ar...
>>>
>>>
>>>
>>>
>>>     =20
>>>

Re: [Springframework-developer] Portlet Form Controllers

[Juergen H. <ju...@in...>]

We don't need to vote right now; we're just gathering opinions :-)

The decision will also depend on the final size of the Portlet support. If
it turns out to be too small for a separate subproject, including it in the
core distribution might be the only feasible way to go.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ken Krebs
Sent: Friday, March 04, 2005 11:47 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet Form Controllers


+1 for subproject status.
It makes sense to me to let them evolve in a more loosely coupled way,
especially as Juergen points out given the small target audience for
portlets.

Juergen Hoeller wrote:

>As I said, a subproject is just under consideration. The alternative is to
>release the portlet support as part of the core Spring 1.3 distribution.
The
>rationale of factoring out subprojects is to let the core concentrate on
its
>current scope and not introduce completely new areas of functionality. A
>secondary goal is to limit the size of spring.jar.
>
>The current core web support and web MVC framework is used by the portlet
>support underneath, for example to render views (at least that was the case
>last year). So Spring Portlet depends on Spring core web (even core web
>MVC), but not the other way round: a case for core web MVC staying part of
>the core distribution, but Portlet support (optionally) becoming a separate
>subproject.
>
>Note that Spring's core web support is of interest to many people: not only
>to web application people, but also to rich client developers accessing
>HTTP-based remote services (running in a Servlet container). Portlet
support
>is more specific and has a narrower target audience.
>
>A further advantage of a separate subproject is that it can evolve more
>easily. Specific sample applications, tutorials, tools etc can be added
>without having to worry about scope or size of the core Spring
distribution.
>
>Anyway, this has not been decided yet and does not have to be decided right
>now. It's gonna become an important topic after the Spring 1.2 release,
>though.
>
>Juergen
>
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Jean-Pol Landrain
>Sent: Friday, March 04, 2005 7:29 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
>I quite agree with Rob. Except, of course, if you plan to create a
>subproject for Spring MVC too. This would allow a Spring "à la carte".
>This would keep the framework light, but would perhaps be a bit confusing
to
>the users. Perhaps a "plugin" functionnality would be nice if the number of
>projects grows : you would have a core Spring and be able to plug in, for
>example by using a dedicated XML file, the other sub-projects you want to
>use. That's just an idea.
>
>Cheers,
>Jean-Pol.
>
>----- Original Message -----
>From: "Rob Butler" <cro...@ya...>
>To: <spr...@li...>
>Sent: Friday, March 04, 2005 7:01 PM
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
>
>
>>Why would you have a separate sub-project for the
>>portlet support in Spring?  That would be like having
>>a separate sub-project for the web MVC stuff, and a
>>separate sub-project for the DAO related stuff, and
>>another one for AOP, etc.
>>
>>Later
>>Rob
>>--- Juergen Hoeller <ju...@in...> wrote:
>>
>>
>>
>>>Sounds like good stuff :-)
>>>
>>>On this occasion: Let's discuss the road to an
>>>official release of the
>>>Portlet support. We consider releasing the Portlet
>>>support as an official
>>>subproject, i.e. as a separate distribution and with
>>>a separate CVS module
>>>(or even separate CVS repository). The association
>>>would be similar to the
>>>just-announced Spring subproject status of Acegi
>>>Security, and the already
>>>established status of Spring RCP.
>>>
>>>Very importantly, the portlet subproject needs a
>>>dedicated developer team.
>>>Any volunteers? :-)
>>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From:
>>>
>>>
>>>
>>spr...@li...
>>
>>
>>[mailto:spr...@li...]On
>>
>>
>>>Behalf
>>>Of John Lewis
>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>To: spr...@li...
>>>Subject: [Springframework-developer] Portlet Form
>>>Controllers
>>>
>>>
>>>We've been working on porting a fairly complex
>>>enterprise application
>>>from the Spring Servlet MVC framework to the Spring
>>>Portlet MVC
>>>framework.  As Nick Lothian and Rainer Schmitz
>>>discovered, the Form
>>>Controller hierarchy is difficult to port over from
>>>the Servlet area to
>>>the Portlet area because of the two-phase nature of
>>>portlet requests.
>>>Since we were porting a large number of existing
>>>controllers descended
>>>from AbstractController, AbstractFormController, or
>>>SimpleFormController, it was critical to that all
>>>the former
>>>functionality of these parent be present and that
>>>our logic work the
>>>same as before.
>>>
>>>Nick Lothian's version of
>>>SimplePortletFormController gave us a good
>>>starting point and helped us understand a lot of the
>>>issues with portlet
>>>development in general and with Spring portlets in
>>>particular.  However,
>>>a lot of our controllers manage database content, so
>>>we needed proper
>>>separation between the action and render phase of
>>>the request, which
>>>this controller did not give us.
>>>
>>>Rainer Schmitz's work went much further and provided
>>>the traditional
>>>hierarchy of controllers and further demonstrated
>>>the issues with
>>>separating out the two phases of the portlet
>>>request.  However, these
>>>still did not give us the complete control that we
>>>needed.  We
>>>especially needed a version of SimpleFormController
>>>that could handle
>>>the separation of the action logic from the render
>>>logic.
>>>
>>>Over the past few months we have developed a new set
>>>of the
>>>AbstractController, BaseCommandController,
>>>AbstractFormController, and
>>>SimpleFormController classes that we think
>>>rigorously address all the
>>>issues with portlet development and that have
>>>allowed us to port over
>>>existing servlet controllers with relative ease.
>>>
>>>We've included a portlet version of
>>>WebContentGenerator to give the
>>>controller classes their proper ancestry and provide
>>>control over things
>>>like content caching and access to the web
>>>application context and to
>>>centralized logging.
>>>
>>>We've also create a new set of the binding classes
>>>(PortletRequestDataBinder,
>>>PortletRequestParameterPropertyValues and
>>>PortletRequestBindingException) that support special
>>>field markers,
>>>correct problems with form elements such as radio
>>>buttons and
>>>checkboxes, and handle redisplay of invalid submits
>>>of non-string
>>>parameters properly.
>>>
>>>All of the classes are fully documented, including
>>>workflow descriptions
>>>in the controllers that cover the special nature of
>>>portlet development.
>>>
>>>Our hope is that these classes can handle the needs
>>>of everyone working
>>>with form controllers in Spring portlets and that
>>>these can be merged
>>>into the sandbox source code.
>>>
>>>The classes are posted in a zip file on the Spring
>>>Portlet Wiki page at:
>>>
>>>
>>>
>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>
>>
>>>The link to the file is (sorry for the long link):
>>>
>>>
>>>
>http://opensource.atlassian.com/confluence/spring/download/attachments/10/s
p
>
>
>>>ring-portlet-controllers.zip
>>>
>>>Please send me any questions or comments you may
>>>have about these
>>>classes.  We are eager to support their adoption in
>>>the Spring Portlet
>>>community.
>>>
>>>John Lewis
>>>jl...@ar...
>>>
>>>
>>>
>>>
>>>
>>>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet Form Controllers

[Tim K. <tim...@vi...>]

I am also in favor of the option that allows the portlet subproject to =
move
ahead as quickly as it can.  We are working on a portlet project here at =
my
company and we've decided to settle on Spring's MVC, and am more than
willing to contribute any improvements that may come along to the =
Portlet
subproject as well. =20

-tim

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Juergen Hoeller
Sent: Friday, March 04, 2005 5:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet Form Controllers

We don't need to vote right now; we're just gathering opinions :-)

The decision will also depend on the final size of the Portlet support. =
If
it turns out to be too small for a separate subproject, including it in =
the
core distribution might be the only feasible way to go.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ken Krebs
Sent: Friday, March 04, 2005 11:47 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet Form Controllers


+1 for subproject status.
It makes sense to me to let them evolve in a more loosely coupled way,
especially as Juergen points out given the small target audience for
portlets.

Juergen Hoeller wrote:

>As I said, a subproject is just under consideration. The alternative is =
to
>release the portlet support as part of the core Spring 1.3 =
distribution.
The
>rationale of factoring out subprojects is to let the core concentrate =
on
its
>current scope and not introduce completely new areas of functionality. =
A
>secondary goal is to limit the size of spring.jar.
>
>The current core web support and web MVC framework is used by the =
portlet
>support underneath, for example to render views (at least that was the =
case
>last year). So Spring Portlet depends on Spring core web (even core web
>MVC), but not the other way round: a case for core web MVC staying part =
of
>the core distribution, but Portlet support (optionally) becoming a =
separate
>subproject.
>
>Note that Spring's core web support is of interest to many people: not =
only
>to web application people, but also to rich client developers accessing
>HTTP-based remote services (running in a Servlet container). Portlet
support
>is more specific and has a narrower target audience.
>
>A further advantage of a separate subproject is that it can evolve more
>easily. Specific sample applications, tutorials, tools etc can be added
>without having to worry about scope or size of the core Spring
distribution.
>
>Anyway, this has not been decided yet and does not have to be decided =
right
>now. It's gonna become an important topic after the Spring 1.2 release,
>though.
>
>Juergen
>
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Jean-Pol Landrain
>Sent: Friday, March 04, 2005 7:29 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
>I quite agree with Rob. Except, of course, if you plan to create a
>subproject for Spring MVC too. This would allow a Spring "=E0 la =
carte".
>This would keep the framework light, but would perhaps be a bit =
confusing
to
>the users. Perhaps a "plugin" functionnality would be nice if the =
number of
>projects grows : you would have a core Spring and be able to plug in, =
for
>example by using a dedicated XML file, the other sub-projects you want =
to
>use. That's just an idea.
>
>Cheers,
>Jean-Pol.
>
>----- Original Message -----
>From: "Rob Butler" <cro...@ya...>
>To: <spr...@li...>
>Sent: Friday, March 04, 2005 7:01 PM
>Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
>
>
>>Why would you have a separate sub-project for the
>>portlet support in Spring?  That would be like having
>>a separate sub-project for the web MVC stuff, and a
>>separate sub-project for the DAO related stuff, and
>>another one for AOP, etc.
>>
>>Later
>>Rob
>>--- Juergen Hoeller <ju...@in...> wrote:
>>
>>
>>
>>>Sounds like good stuff :-)
>>>
>>>On this occasion: Let's discuss the road to an
>>>official release of the
>>>Portlet support. We consider releasing the Portlet
>>>support as an official
>>>subproject, i.e. as a separate distribution and with
>>>a separate CVS module
>>>(or even separate CVS repository). The association
>>>would be similar to the
>>>just-announced Spring subproject status of Acegi
>>>Security, and the already
>>>established status of Spring RCP.
>>>
>>>Very importantly, the portlet subproject needs a
>>>dedicated developer team.
>>>Any volunteers? :-)
>>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From:
>>>
>>>
>>>
>>spr...@li...
>>
>>
>>[mailto:spr...@li...]On
>>
>>
>>>Behalf
>>>Of John Lewis
>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>To: spr...@li...
>>>Subject: [Springframework-developer] Portlet Form
>>>Controllers
>>>
>>>
>>>We've been working on porting a fairly complex
>>>enterprise application
>>>from the Spring Servlet MVC framework to the Spring
>>>Portlet MVC
>>>framework.  As Nick Lothian and Rainer Schmitz
>>>discovered, the Form
>>>Controller hierarchy is difficult to port over from
>>>the Servlet area to
>>>the Portlet area because of the two-phase nature of
>>>portlet requests.
>>>Since we were porting a large number of existing
>>>controllers descended
>>>from AbstractController, AbstractFormController, or
>>>SimpleFormController, it was critical to that all
>>>the former
>>>functionality of these parent be present and that
>>>our logic work the
>>>same as before.
>>>
>>>Nick Lothian's version of
>>>SimplePortletFormController gave us a good
>>>starting point and helped us understand a lot of the
>>>issues with portlet
>>>development in general and with Spring portlets in
>>>particular.  However,
>>>a lot of our controllers manage database content, so
>>>we needed proper
>>>separation between the action and render phase of
>>>the request, which
>>>this controller did not give us.
>>>
>>>Rainer Schmitz's work went much further and provided
>>>the traditional
>>>hierarchy of controllers and further demonstrated
>>>the issues with
>>>separating out the two phases of the portlet
>>>request.  However, these
>>>still did not give us the complete control that we
>>>needed.  We
>>>especially needed a version of SimpleFormController
>>>that could handle
>>>the separation of the action logic from the render
>>>logic.
>>>
>>>Over the past few months we have developed a new set
>>>of the
>>>AbstractController, BaseCommandController,
>>>AbstractFormController, and
>>>SimpleFormController classes that we think
>>>rigorously address all the
>>>issues with portlet development and that have
>>>allowed us to port over
>>>existing servlet controllers with relative ease.
>>>
>>>We've included a portlet version of
>>>WebContentGenerator to give the
>>>controller classes their proper ancestry and provide
>>>control over things
>>>like content caching and access to the web
>>>application context and to
>>>centralized logging.
>>>
>>>We've also create a new set of the binding classes
>>>(PortletRequestDataBinder,
>>>PortletRequestParameterPropertyValues and
>>>PortletRequestBindingException) that support special
>>>field markers,
>>>correct problems with form elements such as radio
>>>buttons and
>>>checkboxes, and handle redisplay of invalid submits
>>>of non-string
>>>parameters properly.
>>>
>>>All of the classes are fully documented, including
>>>workflow descriptions
>>>in the controllers that cover the special nature of
>>>portlet development.
>>>
>>>Our hope is that these classes can handle the needs
>>>of everyone working
>>>with form controllers in Spring portlets and that
>>>these can be merged
>>>into the sandbox source code.
>>>
>>>The classes are posted in a zip file on the Spring
>>>Portlet Wiki page at:
>>>
>>>
>>>
>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>
>>
>>>The link to the file is (sorry for the long link):
>>>
>>>
>>>
>http://opensource.atlassian.com/confluence/spring/download/attachments/1=
0/s
p
>
>
>>>ring-portlet-controllers.zip
>>>
>>>Please send me any questions or comments you may
>>>have about these
>>>classes.  We are eager to support their adoption in
>>>the Spring Portlet
>>>community.
>>>
>>>John Lewis
>>>jl...@ar...
>>>
>>>
>>>
>>>
>>>
>>>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet Form Controllers

[William G. T. Jr. <wg...@ru...>]

I'm also in favor of a subproject that can move ahead with independent 
release dates.  We already have Portlets in production based on the 
sandbox support for Portlet API.  We are interested in seeing this move 
out to a GA release.

Bill


Tim Kettering wrote:
> 
> I am also in favor of the option that allows the portlet subproject to move
> ahead as quickly as it can.  We are working on a portlet project here at my
> company and we've decided to settle on Spring's MVC, and am more than
> willing to contribute any improvements that may come along to the Portlet
> subproject as well.  
> 
> -tim
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Juergen Hoeller
> Sent: Friday, March 04, 2005 5:54 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
> 
> We don't need to vote right now; we're just gathering opinions :-)
> 
> The decision will also depend on the final size of the Portlet support. If
> it turns out to be too small for a separate subproject, including it in the
> core distribution might be the only feasible way to go.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ken Krebs
> Sent: Friday, March 04, 2005 11:47 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
> 
> 
> +1 for subproject status.
> It makes sense to me to let them evolve in a more loosely coupled way,
> especially as Juergen points out given the small target audience for
> portlets.
> 
> Juergen Hoeller wrote:
> 
> 
>>As I said, a subproject is just under consideration. The alternative is to
>>release the portlet support as part of the core Spring 1.3 distribution.
> 
> The
> 
>>rationale of factoring out subprojects is to let the core concentrate on
> 
> its
> 
>>current scope and not introduce completely new areas of functionality. A
>>secondary goal is to limit the size of spring.jar.
>>
>>The current core web support and web MVC framework is used by the portlet
>>support underneath, for example to render views (at least that was the case
>>last year). So Spring Portlet depends on Spring core web (even core web
>>MVC), but not the other way round: a case for core web MVC staying part of
>>the core distribution, but Portlet support (optionally) becoming a separate
>>subproject.
>>
>>Note that Spring's core web support is of interest to many people: not only
>>to web application people, but also to rich client developers accessing
>>HTTP-based remote services (running in a Servlet container). Portlet
> 
> support
> 
>>is more specific and has a narrower target audience.
>>
>>A further advantage of a separate subproject is that it can evolve more
>>easily. Specific sample applications, tutorials, tools etc can be added
>>without having to worry about scope or size of the core Spring
> 
> distribution.
> 
>>Anyway, this has not been decided yet and does not have to be decided right
>>now. It's gonna become an important topic after the Spring 1.2 release,
>>though.
>>
>>Juergen
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Jean-Pol Landrain
>>Sent: Friday, March 04, 2005 7:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>I quite agree with Rob. Except, of course, if you plan to create a
>>subproject for Spring MVC too. This would allow a Spring "à la carte".
>>This would keep the framework light, but would perhaps be a bit confusing
> 
> to
> 
>>the users. Perhaps a "plugin" functionnality would be nice if the number of
>>projects grows : you would have a core Spring and be able to plug in, for
>>example by using a dedicated XML file, the other sub-projects you want to
>>use. That's just an idea.
>>
>>Cheers,
>>Jean-Pol.
>>
>>----- Original Message -----
>>From: "Rob Butler" <cro...@ya...>
>>To: <spr...@li...>
>>Sent: Friday, March 04, 2005 7:01 PM
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>
>>
>>
>>>Why would you have a separate sub-project for the
>>>portlet support in Spring?  That would be like having
>>>a separate sub-project for the web MVC stuff, and a
>>>separate sub-project for the DAO related stuff, and
>>>another one for AOP, etc.
>>>
>>>Later
>>>Rob
>>>--- Juergen Hoeller <ju...@in...> wrote:
>>>
>>>
>>>
>>>
>>>>Sounds like good stuff :-)
>>>>
>>>>On this occasion: Let's discuss the road to an
>>>>official release of the
>>>>Portlet support. We consider releasing the Portlet
>>>>support as an official
>>>>subproject, i.e. as a separate distribution and with
>>>>a separate CVS module
>>>>(or even separate CVS repository). The association
>>>>would be similar to the
>>>>just-announced Spring subproject status of Acegi
>>>>Security, and the already
>>>>established status of Spring RCP.
>>>>
>>>>Very importantly, the portlet subproject needs a
>>>>dedicated developer team.
>>>>Any volunteers? :-)
>>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From:
>>>>
>>>>
>>>>
>>>
>>>spr...@li...
>>>
>>>
>>>[mailto:spr...@li...]On
>>>
>>>
>>>
>>>>Behalf
>>>>Of John Lewis
>>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>>To: spr...@li...
>>>>Subject: [Springframework-developer] Portlet Form
>>>>Controllers
>>>>
>>>>
>>>>We've been working on porting a fairly complex
>>>>enterprise application
>>>
>>>>from the Spring Servlet MVC framework to the Spring
>>>
>>>>Portlet MVC
>>>>framework.  As Nick Lothian and Rainer Schmitz
>>>>discovered, the Form
>>>>Controller hierarchy is difficult to port over from
>>>>the Servlet area to
>>>>the Portlet area because of the two-phase nature of
>>>>portlet requests.
>>>>Since we were porting a large number of existing
>>>>controllers descended
>>>
>>>>from AbstractController, AbstractFormController, or
>>>
>>>>SimpleFormController, it was critical to that all
>>>>the former
>>>>functionality of these parent be present and that
>>>>our logic work the
>>>>same as before.
>>>>
>>>>Nick Lothian's version of
>>>>SimplePortletFormController gave us a good
>>>>starting point and helped us understand a lot of the
>>>>issues with portlet
>>>>development in general and with Spring portlets in
>>>>particular.  However,
>>>>a lot of our controllers manage database content, so
>>>>we needed proper
>>>>separation between the action and render phase of
>>>>the request, which
>>>>this controller did not give us.
>>>>
>>>>Rainer Schmitz's work went much further and provided
>>>>the traditional
>>>>hierarchy of controllers and further demonstrated
>>>>the issues with
>>>>separating out the two phases of the portlet
>>>>request.  However, these
>>>>still did not give us the complete control that we
>>>>needed.  We
>>>>especially needed a version of SimpleFormController
>>>>that could handle
>>>>the separation of the action logic from the render
>>>>logic.
>>>>
>>>>Over the past few months we have developed a new set
>>>>of the
>>>>AbstractController, BaseCommandController,
>>>>AbstractFormController, and
>>>>SimpleFormController classes that we think
>>>>rigorously address all the
>>>>issues with portlet development and that have
>>>>allowed us to port over
>>>>existing servlet controllers with relative ease.
>>>>
>>>>We've included a portlet version of
>>>>WebContentGenerator to give the
>>>>controller classes their proper ancestry and provide
>>>>control over things
>>>>like content caching and access to the web
>>>>application context and to
>>>>centralized logging.
>>>>
>>>>We've also create a new set of the binding classes
>>>>(PortletRequestDataBinder,
>>>>PortletRequestParameterPropertyValues and
>>>>PortletRequestBindingException) that support special
>>>>field markers,
>>>>correct problems with form elements such as radio
>>>>buttons and
>>>>checkboxes, and handle redisplay of invalid submits
>>>>of non-string
>>>>parameters properly.
>>>>
>>>>All of the classes are fully documented, including
>>>>workflow descriptions
>>>>in the controllers that cover the special nature of
>>>>portlet development.
>>>>
>>>>Our hope is that these classes can handle the needs
>>>>of everyone working
>>>>with form controllers in Spring portlets and that
>>>>these can be merged
>>>>into the sandbox source code.
>>>>
>>>>The classes are posted in a zip file on the Spring
>>>>Portlet Wiki page at:
>>>>
>>>>
>>>>
>>>
>>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>>
>>>
>>>
>>>>The link to the file is (sorry for the long link):
>>>>
>>>>
>>>>
>>
>>http://opensource.atlassian.com/confluence/spring/download/attachments/10/s
> 
> p
> 
>>
>>>>ring-portlet-controllers.zip
>>>>
>>>>Please send me any questions or comments you may
>>>>have about these
>>>>classes.  We are eager to support their adoption in
>>>>the Spring Portlet
>>>>community.
>>>>
>>>>John Lewis
>>>>jl...@ar...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

RE: [Springframework-developer] Portlet Form Controllers

[Tim K. <tim...@vi...>]

Related to this portlet stuff, will John Lewis' contribution be finding =
its
way in the sandbox cvs anytime soon?

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
William G. Thompson, Jr.
Sent: Tuesday, March 08, 2005 1:12 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet Form Controllers

I'm also in favor of a subproject that can move ahead with independent=20
release dates.  We already have Portlets in production based on the=20
sandbox support for Portlet API.  We are interested in seeing this move=20
out to a GA release.

Bill


Tim Kettering wrote:
>=20
> I am also in favor of the option that allows the portlet subproject to
move
> ahead as quickly as it can.  We are working on a portlet project here =
at
my
> company and we've decided to settle on Spring's MVC, and am more than
> willing to contribute any improvements that may come along to the =
Portlet
> subproject as well. =20
>=20
> -tim
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
Of
> Juergen Hoeller
> Sent: Friday, March 04, 2005 5:54 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
>=20
> We don't need to vote right now; we're just gathering opinions :-)
>=20
> The decision will also depend on the final size of the Portlet =
support. If
> it turns out to be too small for a separate subproject, including it =
in
the
> core distribution might be the only feasible way to go.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Ken Krebs
> Sent: Friday, March 04, 2005 11:47 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
>=20
>=20
> +1 for subproject status.
> It makes sense to me to let them evolve in a more loosely coupled way,
> especially as Juergen points out given the small target audience for
> portlets.
>=20
> Juergen Hoeller wrote:
>=20
>=20
>>As I said, a subproject is just under consideration. The alternative =
is to
>>release the portlet support as part of the core Spring 1.3 =
distribution.
>=20
> The
>=20
>>rationale of factoring out subprojects is to let the core concentrate =
on
>=20
> its
>=20
>>current scope and not introduce completely new areas of functionality. =
A
>>secondary goal is to limit the size of spring.jar.
>>
>>The current core web support and web MVC framework is used by the =
portlet
>>support underneath, for example to render views (at least that was the
case
>>last year). So Spring Portlet depends on Spring core web (even core =
web
>>MVC), but not the other way round: a case for core web MVC staying =
part of
>>the core distribution, but Portlet support (optionally) becoming a
separate
>>subproject.
>>
>>Note that Spring's core web support is of interest to many people: not
only
>>to web application people, but also to rich client developers =
accessing
>>HTTP-based remote services (running in a Servlet container). Portlet
>=20
> support
>=20
>>is more specific and has a narrower target audience.
>>
>>A further advantage of a separate subproject is that it can evolve =
more
>>easily. Specific sample applications, tutorials, tools etc can be =
added
>>without having to worry about scope or size of the core Spring
>=20
> distribution.
>=20
>>Anyway, this has not been decided yet and does not have to be decided
right
>>now. It's gonna become an important topic after the Spring 1.2 =
release,
>>though.
>>
>>Juergen
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On =
Behalf
>>Of Jean-Pol Landrain
>>Sent: Friday, March 04, 2005 7:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>I quite agree with Rob. Except, of course, if you plan to create a
>>subproject for Spring MVC too. This would allow a Spring "=E0 la =
carte".
>>This would keep the framework light, but would perhaps be a bit =
confusing
>=20
> to
>=20
>>the users. Perhaps a "plugin" functionnality would be nice if the =
number
of
>>projects grows : you would have a core Spring and be able to plug in, =
for
>>example by using a dedicated XML file, the other sub-projects you want =
to
>>use. That's just an idea.
>>
>>Cheers,
>>Jean-Pol.
>>
>>----- Original Message -----
>>From: "Rob Butler" <cro...@ya...>
>>To: <spr...@li...>
>>Sent: Friday, March 04, 2005 7:01 PM
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>
>>
>>
>>>Why would you have a separate sub-project for the
>>>portlet support in Spring?  That would be like having
>>>a separate sub-project for the web MVC stuff, and a
>>>separate sub-project for the DAO related stuff, and
>>>another one for AOP, etc.
>>>
>>>Later
>>>Rob
>>>--- Juergen Hoeller <ju...@in...> wrote:
>>>
>>>
>>>
>>>
>>>>Sounds like good stuff :-)
>>>>
>>>>On this occasion: Let's discuss the road to an
>>>>official release of the
>>>>Portlet support. We consider releasing the Portlet
>>>>support as an official
>>>>subproject, i.e. as a separate distribution and with
>>>>a separate CVS module
>>>>(or even separate CVS repository). The association
>>>>would be similar to the
>>>>just-announced Spring subproject status of Acegi
>>>>Security, and the already
>>>>established status of Spring RCP.
>>>>
>>>>Very importantly, the portlet subproject needs a
>>>>dedicated developer team.
>>>>Any volunteers? :-)
>>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From:
>>>>
>>>>
>>>>
>>>
>>>spr...@li...
>>>
>>>
>>>[mailto:spr...@li...]On
>>>
>>>
>>>
>>>>Behalf
>>>>Of John Lewis
>>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>>To: spr...@li...
>>>>Subject: [Springframework-developer] Portlet Form
>>>>Controllers
>>>>
>>>>
>>>>We've been working on porting a fairly complex
>>>>enterprise application
>>>
>>>>from the Spring Servlet MVC framework to the Spring
>>>
>>>>Portlet MVC
>>>>framework.  As Nick Lothian and Rainer Schmitz
>>>>discovered, the Form
>>>>Controller hierarchy is difficult to port over from
>>>>the Servlet area to
>>>>the Portlet area because of the two-phase nature of
>>>>portlet requests.
>>>>Since we were porting a large number of existing
>>>>controllers descended
>>>
>>>>from AbstractController, AbstractFormController, or
>>>
>>>>SimpleFormController, it was critical to that all
>>>>the former
>>>>functionality of these parent be present and that
>>>>our logic work the
>>>>same as before.
>>>>
>>>>Nick Lothian's version of
>>>>SimplePortletFormController gave us a good
>>>>starting point and helped us understand a lot of the
>>>>issues with portlet
>>>>development in general and with Spring portlets in
>>>>particular.  However,
>>>>a lot of our controllers manage database content, so
>>>>we needed proper
>>>>separation between the action and render phase of
>>>>the request, which
>>>>this controller did not give us.
>>>>
>>>>Rainer Schmitz's work went much further and provided
>>>>the traditional
>>>>hierarchy of controllers and further demonstrated
>>>>the issues with
>>>>separating out the two phases of the portlet
>>>>request.  However, these
>>>>still did not give us the complete control that we
>>>>needed.  We
>>>>especially needed a version of SimpleFormController
>>>>that could handle
>>>>the separation of the action logic from the render
>>>>logic.
>>>>
>>>>Over the past few months we have developed a new set
>>>>of the
>>>>AbstractController, BaseCommandController,
>>>>AbstractFormController, and
>>>>SimpleFormController classes that we think
>>>>rigorously address all the
>>>>issues with portlet development and that have
>>>>allowed us to port over
>>>>existing servlet controllers with relative ease.
>>>>
>>>>We've included a portlet version of
>>>>WebContentGenerator to give the
>>>>controller classes their proper ancestry and provide
>>>>control over things
>>>>like content caching and access to the web
>>>>application context and to
>>>>centralized logging.
>>>>
>>>>We've also create a new set of the binding classes
>>>>(PortletRequestDataBinder,
>>>>PortletRequestParameterPropertyValues and
>>>>PortletRequestBindingException) that support special
>>>>field markers,
>>>>correct problems with form elements such as radio
>>>>buttons and
>>>>checkboxes, and handle redisplay of invalid submits
>>>>of non-string
>>>>parameters properly.
>>>>
>>>>All of the classes are fully documented, including
>>>>workflow descriptions
>>>>in the controllers that cover the special nature of
>>>>portlet development.
>>>>
>>>>Our hope is that these classes can handle the needs
>>>>of everyone working
>>>>with form controllers in Spring portlets and that
>>>>these can be merged
>>>>into the sandbox source code.
>>>>
>>>>The classes are posted in a zip file on the Spring
>>>>Portlet Wiki page at:
>>>>
>>>>
>>>>
>>>
>>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>>
>>>
>>>
>>>>The link to the file is (sorry for the long link):
>>>>
>>>>
>>>>
>>
>>http://opensource.atlassian.com/confluence/spring/download/attachments/=
10/
s
>=20
> p
>=20
>>
>>>>ring-portlet-controllers.zip
>>>>
>>>>Please send me any questions or comments you may
>>>>have about these
>>>>classes.  We are eager to support their adoption in
>>>>the Spring Portlet
>>>>community.
>>>>
>>>>John Lewis
>>>>jl...@ar...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Portlet Form Controllers

[John L. <jl...@ar...>]

I agree that it could go either way.  The reasons I might be supportive 
of making it part of core Spring are that the number of classes is 
relatively small (around 30 at this point), and that it is all pretty 
tightly coupled with the web servlet framework.  But I could go either 
way with it.

I would be happy to volunteer to be a dedicated developer for the 
portlet framework.  We are going to be using it extensively for the next 
few years so we have a big vested interest in making it work well.

I'd love to go ahead and commit the new controller hierarchy into the 
sandbox.  What would it take to get approved to do that?  Juergen, my 
SourceForge user ID is 'johnalewis' if that is all you need.

Thanks!
John

Juergen Hoeller wrote:
> We don't need to vote right now; we're just gathering opinions :-)
> 
> The decision will also depend on the final size of the Portlet support. If
> it turns out to be too small for a separate subproject, including it in the
> core distribution might be the only feasible way to go.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ken Krebs
> Sent: Friday, March 04, 2005 11:47 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
> 
> 
> +1 for subproject status.
> It makes sense to me to let them evolve in a more loosely coupled way,
> especially as Juergen points out given the small target audience for
> portlets.
> 
> Juergen Hoeller wrote:
> 
> 
>>As I said, a subproject is just under consideration. The alternative is to
>>release the portlet support as part of the core Spring 1.3 distribution.
> 
> The
> 
>>rationale of factoring out subprojects is to let the core concentrate on
> 
> its
> 
>>current scope and not introduce completely new areas of functionality. A
>>secondary goal is to limit the size of spring.jar.
>>
>>The current core web support and web MVC framework is used by the portlet
>>support underneath, for example to render views (at least that was the case
>>last year). So Spring Portlet depends on Spring core web (even core web
>>MVC), but not the other way round: a case for core web MVC staying part of
>>the core distribution, but Portlet support (optionally) becoming a separate
>>subproject.
>>
>>Note that Spring's core web support is of interest to many people: not only
>>to web application people, but also to rich client developers accessing
>>HTTP-based remote services (running in a Servlet container). Portlet
> 
> support
> 
>>is more specific and has a narrower target audience.
>>
>>A further advantage of a separate subproject is that it can evolve more
>>easily. Specific sample applications, tutorials, tools etc can be added
>>without having to worry about scope or size of the core Spring
> 
> distribution.
> 
>>Anyway, this has not been decided yet and does not have to be decided right
>>now. It's gonna become an important topic after the Spring 1.2 release,
>>though.
>>
>>Juergen
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Jean-Pol Landrain
>>Sent: Friday, March 04, 2005 7:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>I quite agree with Rob. Except, of course, if you plan to create a
>>subproject for Spring MVC too. This would allow a Spring "à la carte".
>>This would keep the framework light, but would perhaps be a bit confusing
> 
> to
> 
>>the users. Perhaps a "plugin" functionnality would be nice if the number of
>>projects grows : you would have a core Spring and be able to plug in, for
>>example by using a dedicated XML file, the other sub-projects you want to
>>use. That's just an idea.
>>
>>Cheers,
>>Jean-Pol.
>>
>>----- Original Message -----
>>From: "Rob Butler" <cro...@ya...>
>>To: <spr...@li...>
>>Sent: Friday, March 04, 2005 7:01 PM
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>
>>
>>
>>>Why would you have a separate sub-project for the
>>>portlet support in Spring?  That would be like having
>>>a separate sub-project for the web MVC stuff, and a
>>>separate sub-project for the DAO related stuff, and
>>>another one for AOP, etc.
>>>
>>>Later
>>>Rob
>>>--- Juergen Hoeller <ju...@in...> wrote:
>>>
>>>
>>>
>>>
>>>>Sounds like good stuff :-)
>>>>
>>>>On this occasion: Let's discuss the road to an
>>>>official release of the
>>>>Portlet support. We consider releasing the Portlet
>>>>support as an official
>>>>subproject, i.e. as a separate distribution and with
>>>>a separate CVS module
>>>>(or even separate CVS repository). The association
>>>>would be similar to the
>>>>just-announced Spring subproject status of Acegi
>>>>Security, and the already
>>>>established status of Spring RCP.
>>>>
>>>>Very importantly, the portlet subproject needs a
>>>>dedicated developer team.
>>>>Any volunteers? :-)
>>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From:
>>>>
>>>>
>>>>
>>>
>>>spr...@li...
>>>
>>>
>>>[mailto:spr...@li...]On
>>>
>>>
>>>
>>>>Behalf
>>>>Of John Lewis
>>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>>To: spr...@li...
>>>>Subject: [Springframework-developer] Portlet Form
>>>>Controllers
>>>>
>>>>
>>>>We've been working on porting a fairly complex
>>>>enterprise application
>>>
>>>>from the Spring Servlet MVC framework to the Spring
>>>
>>>>Portlet MVC
>>>>framework.  As Nick Lothian and Rainer Schmitz
>>>>discovered, the Form
>>>>Controller hierarchy is difficult to port over from
>>>>the Servlet area to
>>>>the Portlet area because of the two-phase nature of
>>>>portlet requests.
>>>>Since we were porting a large number of existing
>>>>controllers descended
>>>
>>>>from AbstractController, AbstractFormController, or
>>>
>>>>SimpleFormController, it was critical to that all
>>>>the former
>>>>functionality of these parent be present and that
>>>>our logic work the
>>>>same as before.
>>>>
>>>>Nick Lothian's version of
>>>>SimplePortletFormController gave us a good
>>>>starting point and helped us understand a lot of the
>>>>issues with portlet
>>>>development in general and with Spring portlets in
>>>>particular.  However,
>>>>a lot of our controllers manage database content, so
>>>>we needed proper
>>>>separation between the action and render phase of
>>>>the request, which
>>>>this controller did not give us.
>>>>
>>>>Rainer Schmitz's work went much further and provided
>>>>the traditional
>>>>hierarchy of controllers and further demonstrated
>>>>the issues with
>>>>separating out the two phases of the portlet
>>>>request.  However, these
>>>>still did not give us the complete control that we
>>>>needed.  We
>>>>especially needed a version of SimpleFormController
>>>>that could handle
>>>>the separation of the action logic from the render
>>>>logic.
>>>>
>>>>Over the past few months we have developed a new set
>>>>of the
>>>>AbstractController, BaseCommandController,
>>>>AbstractFormController, and
>>>>SimpleFormController classes that we think
>>>>rigorously address all the
>>>>issues with portlet development and that have
>>>>allowed us to port over
>>>>existing servlet controllers with relative ease.
>>>>
>>>>We've included a portlet version of
>>>>WebContentGenerator to give the
>>>>controller classes their proper ancestry and provide
>>>>control over things
>>>>like content caching and access to the web
>>>>application context and to
>>>>centralized logging.
>>>>
>>>>We've also create a new set of the binding classes
>>>>(PortletRequestDataBinder,
>>>>PortletRequestParameterPropertyValues and
>>>>PortletRequestBindingException) that support special
>>>>field markers,
>>>>correct problems with form elements such as radio
>>>>buttons and
>>>>checkboxes, and handle redisplay of invalid submits
>>>>of non-string
>>>>parameters properly.
>>>>
>>>>All of the classes are fully documented, including
>>>>workflow descriptions
>>>>in the controllers that cover the special nature of
>>>>portlet development.
>>>>
>>>>Our hope is that these classes can handle the needs
>>>>of everyone working
>>>>with form controllers in Spring portlets and that
>>>>these can be merged
>>>>into the sandbox source code.
>>>>
>>>>The classes are posted in a zip file on the Spring
>>>>Portlet Wiki page at:
>>>>
>>>>
>>>>
>>>
>>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>>
>>>
>>>
>>>>The link to the file is (sorry for the long link):
>>>>
>>>>
>>>>
>>
>>http://opensource.atlassian.com/confluence/spring/download/attachments/10/s
> 
> p
> 
>>
>>>>ring-portlet-controllers.zip
>>>>
>>>>Please send me any questions or comments you may
>>>>have about these
>>>>classes.  We are eager to support their adoption in
>>>>the Spring Portlet
>>>>community.
>>>>
>>>>John Lewis
>>>>jl...@ar...

Re: [Springframework-developer] Re: Portlet Form Controllers

[Juergen H. <ju...@in...>]

John,

Sorry for the late reply. Thanks for volunteering! :-)

Let's continue to proceed in the Portlet area once Spring 1.2 is out. Both
Spring Web Flows and the Portlet support are currently planned to be
cornerstones of Spring 1.3.

Regarding commit rights, let's discuss this once 1.2 is out too. We're
willing to extend the developer team, but there's a couple of things to be
clarified (CLA etc).

In the meantime, feel free to create a JIRA issue for your enhancements! I'm
sure that Dmitriy, Bill and co will be happy to have an early look at this.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of John Lewis
Sent: Wednesday, March 09, 2005 3:34 AM
To: spr...@li...
Subject: [Springframework-developer] Re: Portlet Form Controllers


I agree that it could go either way.  The reasons I might be supportive
of making it part of core Spring are that the number of classes is
relatively small (around 30 at this point), and that it is all pretty
tightly coupled with the web servlet framework.  But I could go either
way with it.

I would be happy to volunteer to be a dedicated developer for the
portlet framework.  We are going to be using it extensively for the next
few years so we have a big vested interest in making it work well.

I'd love to go ahead and commit the new controller hierarchy into the
sandbox.  What would it take to get approved to do that?  Juergen, my
SourceForge user ID is 'johnalewis' if that is all you need.

Thanks!
John

Juergen Hoeller wrote:
> We don't need to vote right now; we're just gathering opinions :-)
>
> The decision will also depend on the final size of the Portlet support. If
> it turns out to be too small for a separate subproject, including it in
the
> core distribution might be the only feasible way to go.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ken Krebs
> Sent: Friday, March 04, 2005 11:47 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet Form Controllers
>
>
> +1 for subproject status.
> It makes sense to me to let them evolve in a more loosely coupled way,
> especially as Juergen points out given the small target audience for
> portlets.
>
> Juergen Hoeller wrote:
>
>
>>As I said, a subproject is just under consideration. The alternative is to
>>release the portlet support as part of the core Spring 1.3 distribution.
>
> The
>
>>rationale of factoring out subprojects is to let the core concentrate on
>
> its
>
>>current scope and not introduce completely new areas of functionality. A
>>secondary goal is to limit the size of spring.jar.
>>
>>The current core web support and web MVC framework is used by the portlet
>>support underneath, for example to render views (at least that was the
case
>>last year). So Spring Portlet depends on Spring core web (even core web
>>MVC), but not the other way round: a case for core web MVC staying part of
>>the core distribution, but Portlet support (optionally) becoming a
separate
>>subproject.
>>
>>Note that Spring's core web support is of interest to many people: not
only
>>to web application people, but also to rich client developers accessing
>>HTTP-based remote services (running in a Servlet container). Portlet
>
> support
>
>>is more specific and has a narrower target audience.
>>
>>A further advantage of a separate subproject is that it can evolve more
>>easily. Specific sample applications, tutorials, tools etc can be added
>>without having to worry about scope or size of the core Spring
>
> distribution.
>
>>Anyway, this has not been decided yet and does not have to be decided
right
>>now. It's gonna become an important topic after the Spring 1.2 release,
>>though.
>>
>>Juergen
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Jean-Pol Landrain
>>Sent: Friday, March 04, 2005 7:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>I quite agree with Rob. Except, of course, if you plan to create a
>>subproject for Spring MVC too. This would allow a Spring "à la carte".
>>This would keep the framework light, but would perhaps be a bit confusing
>
> to
>
>>the users. Perhaps a "plugin" functionnality would be nice if the number
of
>>projects grows : you would have a core Spring and be able to plug in, for
>>example by using a dedicated XML file, the other sub-projects you want to
>>use. That's just an idea.
>>
>>Cheers,
>>Jean-Pol.
>>
>>----- Original Message -----
>>From: "Rob Butler" <cro...@ya...>
>>To: <spr...@li...>
>>Sent: Friday, March 04, 2005 7:01 PM
>>Subject: Re: [Springframework-developer] Portlet Form Controllers
>>
>>
>>
>>
>>
>>>Why would you have a separate sub-project for the
>>>portlet support in Spring?  That would be like having
>>>a separate sub-project for the web MVC stuff, and a
>>>separate sub-project for the DAO related stuff, and
>>>another one for AOP, etc.
>>>
>>>Later
>>>Rob
>>>--- Juergen Hoeller <ju...@in...> wrote:
>>>
>>>
>>>
>>>
>>>>Sounds like good stuff :-)
>>>>
>>>>On this occasion: Let's discuss the road to an
>>>>official release of the
>>>>Portlet support. We consider releasing the Portlet
>>>>support as an official
>>>>subproject, i.e. as a separate distribution and with
>>>>a separate CVS module
>>>>(or even separate CVS repository). The association
>>>>would be similar to the
>>>>just-announced Spring subproject status of Acegi
>>>>Security, and the already
>>>>established status of Spring RCP.
>>>>
>>>>Very importantly, the portlet subproject needs a
>>>>dedicated developer team.
>>>>Any volunteers? :-)
>>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From:
>>>>
>>>>
>>>>
>>>
>>>spr...@li...
>>>
>>>
>>>[mailto:spr...@li...]On
>>>
>>>
>>>
>>>>Behalf
>>>>Of John Lewis
>>>>Sent: Thursday, March 03, 2005 6:53 PM
>>>>To: spr...@li...
>>>>Subject: [Springframework-developer] Portlet Form
>>>>Controllers
>>>>
>>>>
>>>>We've been working on porting a fairly complex
>>>>enterprise application
>>>
>>>>from the Spring Servlet MVC framework to the Spring
>>>
>>>>Portlet MVC
>>>>framework.  As Nick Lothian and Rainer Schmitz
>>>>discovered, the Form
>>>>Controller hierarchy is difficult to port over from
>>>>the Servlet area to
>>>>the Portlet area because of the two-phase nature of
>>>>portlet requests.
>>>>Since we were porting a large number of existing
>>>>controllers descended
>>>
>>>>from AbstractController, AbstractFormController, or
>>>
>>>>SimpleFormController, it was critical to that all
>>>>the former
>>>>functionality of these parent be present and that
>>>>our logic work the
>>>>same as before.
>>>>
>>>>Nick Lothian's version of
>>>>SimplePortletFormController gave us a good
>>>>starting point and helped us understand a lot of the
>>>>issues with portlet
>>>>development in general and with Spring portlets in
>>>>particular.  However,
>>>>a lot of our controllers manage database content, so
>>>>we needed proper
>>>>separation between the action and render phase of
>>>>the request, which
>>>>this controller did not give us.
>>>>
>>>>Rainer Schmitz's work went much further and provided
>>>>the traditional
>>>>hierarchy of controllers and further demonstrated
>>>>the issues with
>>>>separating out the two phases of the portlet
>>>>request.  However, these
>>>>still did not give us the complete control that we
>>>>needed.  We
>>>>especially needed a version of SimpleFormController
>>>>that could handle
>>>>the separation of the action logic from the render
>>>>logic.
>>>>
>>>>Over the past few months we have developed a new set
>>>>of the
>>>>AbstractController, BaseCommandController,
>>>>AbstractFormController, and
>>>>SimpleFormController classes that we think
>>>>rigorously address all the
>>>>issues with portlet development and that have
>>>>allowed us to port over
>>>>existing servlet controllers with relative ease.
>>>>
>>>>We've included a portlet version of
>>>>WebContentGenerator to give the
>>>>controller classes their proper ancestry and provide
>>>>control over things
>>>>like content caching and access to the web
>>>>application context and to
>>>>centralized logging.
>>>>
>>>>We've also create a new set of the binding classes
>>>>(PortletRequestDataBinder,
>>>>PortletRequestParameterPropertyValues and
>>>>PortletRequestBindingException) that support special
>>>>field markers,
>>>>correct problems with form elements such as radio
>>>>buttons and
>>>>checkboxes, and handle redisplay of invalid submits
>>>>of non-string
>>>>parameters properly.
>>>>
>>>>All of the classes are fully documented, including
>>>>workflow descriptions
>>>>in the controllers that cover the special nature of
>>>>portlet development.
>>>>
>>>>Our hope is that these classes can handle the needs
>>>>of everyone working
>>>>with form controllers in Spring portlets and that
>>>>these can be merged
>>>>into the sandbox source code.
>>>>
>>>>The classes are posted in a zip file on the Spring
>>>>Portlet Wiki page at:
>>>>
>>>>
>>>>
>>>
>>>http://opensource.atlassian.com/confluence/spring/display/JSR168/
>>>
>>>
>>>
>>>>The link to the file is (sorry for the long link):
>>>>
>>>>
>>>>
>>
>>http://opensource.atlassian.com/confluence/spring/download/attachments/10/
s
>
> p
>
>>
>>>>ring-portlet-controllers.zip
>>>>
>>>>Please send me any questions or comments you may
>>>>have about these
>>>>classes.  We are eager to support their adoption in
>>>>the Spring Portlet
>>>>community.
>>>>
>>>>John Lewis
>>>>jl...@ar...



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Portlet Form Controllers

[Rainer S. <Rai...@ab...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While the "official" work on the Portlet support are postponed to Spring
1.3 I still would like to have a place for discussions and code
contributions. At this time the discussion is spread across this list,
the forum, confluence, and JIRA, which makes it hard to follow.

As for discussions, I would propose to stick to this list - we *are*
talking about Spring development, and this way the experienced Spring
developers may take the opportunity to participate.

As for code contributios: during the past couple of month several people
(William, Nick, John, and me) have contributed some code, but after each
contribution there was a big gap. One reason might be that it's very
inconvenient to get the up-to-date version of the code (none of the
changes made it into CVS; you have to fetch the sandbox version and copy
the content of several zip files from confluence). Without a proper code
management facility it's pointless to add more contributions.

I'm undecided wether portlet support should be part of main Spring or a
sub project, but for the time being it would really help if the portlet
code would be located at a place where all interested people could find
the up-to-date version and contribute enhancements. When the official
work in the Spring 1.3 context begins, this code could be an
implementation base for any portlet code handled in the traditional way.

What do you think?

Rainer



Juergen Hoeller schrieb:
> John,
> 
> Sorry for the late reply. Thanks for volunteering! :-)
> 
> Let's continue to proceed in the Portlet area once Spring 1.2 is out. Both
> Spring Web Flows and the Portlet support are currently planned to be
> cornerstones of Spring 1.3.
> 
> Regarding commit rights, let's discuss this once 1.2 is out too. We're
> willing to extend the developer team, but there's a couple of things to be
> clarified (CLA etc).
> 
> In the meantime, feel free to create a JIRA issue for your enhancements! I'm
> sure that Dmitriy, Bill and co will be happy to have an early look at this.
> 
> Juergen
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
rv556WE9CYsBzgbrTtkRqLU=
=qCQl
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Re: Portlet Form Controllers

[Juergen H. <ju...@in...>]

That sounds like a good plan to me! It would be great to get this going
ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
waiting till after 1.2 final might not leave enough time.

Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
meantime? :-) This would have to be someone with commit rights, after all,
and ideally someone already using the Portlet code.

First step would be to merge all existing contributions in. Let's assume
that the Portlet code will become part of Spring 1.3 proper (which is
likely), and continue to work on it in the sandbox.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rainer Schmitz
Sent: Wednesday, March 30, 2005 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Portlet Form Controllers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While the "official" work on the Portlet support are postponed to Spring
1.3 I still would like to have a place for discussions and code
contributions. At this time the discussion is spread across this list,
the forum, confluence, and JIRA, which makes it hard to follow.

As for discussions, I would propose to stick to this list - we *are*
talking about Spring development, and this way the experienced Spring
developers may take the opportunity to participate.

As for code contributios: during the past couple of month several people
(William, Nick, John, and me) have contributed some code, but after each
contribution there was a big gap. One reason might be that it's very
inconvenient to get the up-to-date version of the code (none of the
changes made it into CVS; you have to fetch the sandbox version and copy
the content of several zip files from confluence). Without a proper code
management facility it's pointless to add more contributions.

I'm undecided wether portlet support should be part of main Spring or a
sub project, but for the time being it would really help if the portlet
code would be located at a place where all interested people could find
the up-to-date version and contribute enhancements. When the official
work in the Spring 1.3 context begins, this code could be an
implementation base for any portlet code handled in the traditional way.

What do you think?

Rainer



Juergen Hoeller schrieb:
> John,
>
> Sorry for the late reply. Thanks for volunteering! :-)
>
> Let's continue to proceed in the Portlet area once Spring 1.2 is out. Both
> Spring Web Flows and the Portlet support are currently planned to be
> cornerstones of Spring 1.3.
>
> Regarding commit rights, let's discuss this once 1.2 is out too. We're
> willing to extend the developer team, but there's a couple of things to be
> clarified (CLA etc).
>
> In the meantime, feel free to create a JIRA issue for your enhancements!
I'm
> sure that Dmitriy, Bill and co will be happy to have an early look at
this.
>
> Juergen
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
rv556WE9CYsBzgbrTtkRqLU=
=qCQl
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Portlet Form Controllers

[Erwin V. <erw...@er...>]

I also have some Spring Web Flow integration with Portlets code that was 
contributed a while back laying around.

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Juergen Hoeller" <ju...@in...>
To: <spr...@li...>
Sent: Wednesday, March 30, 2005 12:29 PM
Subject: Re: [Springframework-developer] Re: Portlet Form Controllers


> That sounds like a good plan to me! It would be great to get this going
> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
> waiting till after 1.2 final might not leave enough time.
>
> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
> meantime? :-) This would have to be someone with commit rights, after all,
> and ideally someone already using the Portlet code.
>
> First step would be to merge all existing contributions in. Let's assume
> that the Portlet code will become part of Spring 1.3 proper (which is
> likely), and continue to work on it in the sandbox.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rainer Schmitz
> Sent: Wednesday, March 30, 2005 11:53 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> While the "official" work on the Portlet support are postponed to Spring
> 1.3 I still would like to have a place for discussions and code
> contributions. At this time the discussion is spread across this list,
> the forum, confluence, and JIRA, which makes it hard to follow.
>
> As for discussions, I would propose to stick to this list - we *are*
> talking about Spring development, and this way the experienced Spring
> developers may take the opportunity to participate.
>
> As for code contributios: during the past couple of month several people
> (William, Nick, John, and me) have contributed some code, but after each
> contribution there was a big gap. One reason might be that it's very
> inconvenient to get the up-to-date version of the code (none of the
> changes made it into CVS; you have to fetch the sandbox version and copy
> the content of several zip files from confluence). Without a proper code
> management facility it's pointless to add more contributions.
>
> I'm undecided wether portlet support should be part of main Spring or a
> sub project, but for the time being it would really help if the portlet
> code would be located at a place where all interested people could find
> the up-to-date version and contribute enhancements. When the official
> work in the Spring 1.3 context begins, this code could be an
> implementation base for any portlet code handled in the traditional way.
>
> What do you think?
>
> Rainer
>
>
>
> Juergen Hoeller schrieb:
>> John,
>>
>> Sorry for the late reply. Thanks for volunteering! :-)
>>
>> Let's continue to proceed in the Portlet area once Spring 1.2 is out. 
>> Both
>> Spring Web Flows and the Portlet support are currently planned to be
>> cornerstones of Spring 1.3.
>>
>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>> willing to extend the developer team, but there's a couple of things to 
>> be
>> clarified (CLA etc).
>>
>> In the meantime, feel free to create a JIRA issue for your enhancements!
> I'm
>> sure that Dmitriy, Bill and co will be happy to have an early look at
> this.
>>
>> Juergen
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
> rv556WE9CYsBzgbrTtkRqLU=
> =qCQl
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

Re: [Springframework-developer] Re: Portlet Form Controllers

[William G. T. Jr. <wg...@ru...>]

Juergen Hoeller wrote:
> That sounds like a good plan to me! It would be great to get this going
> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
> waiting till after 1.2 final might not leave enough time.
> 
> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
> meantime? :-) This would have to be someone with commit rights, after all,
> and ideally someone already using the Portlet code.

I should be able to get the all the latest patches in next week.

Bill

> 
> First step would be to merge all existing contributions in. Let's assume
> that the Portlet code will become part of Spring 1.3 proper (which is
> likely), and continue to work on it in the sandbox.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rainer Schmitz
> Sent: Wednesday, March 30, 2005 11:53 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> While the "official" work on the Portlet support are postponed to Spring
> 1.3 I still would like to have a place for discussions and code
> contributions. At this time the discussion is spread across this list,
> the forum, confluence, and JIRA, which makes it hard to follow.
> 
> As for discussions, I would propose to stick to this list - we *are*
> talking about Spring development, and this way the experienced Spring
> developers may take the opportunity to participate.
> 
> As for code contributios: during the past couple of month several people
> (William, Nick, John, and me) have contributed some code, but after each
> contribution there was a big gap. One reason might be that it's very
> inconvenient to get the up-to-date version of the code (none of the
> changes made it into CVS; you have to fetch the sandbox version and copy
> the content of several zip files from confluence). Without a proper code
> management facility it's pointless to add more contributions.
> 
> I'm undecided wether portlet support should be part of main Spring or a
> sub project, but for the time being it would really help if the portlet
> code would be located at a place where all interested people could find
> the up-to-date version and contribute enhancements. When the official
> work in the Spring 1.3 context begins, this code could be an
> implementation base for any portlet code handled in the traditional way.
> 
> What do you think?
> 
> Rainer
> 
> 
> 
> Juergen Hoeller schrieb:
> 
>>John,
>>
>>Sorry for the late reply. Thanks for volunteering! :-)
>>
>>Let's continue to proceed in the Portlet area once Spring 1.2 is out. Both
>>Spring Web Flows and the Portlet support are currently planned to be
>>cornerstones of Spring 1.3.
>>
>>Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>willing to extend the developer team, but there's a couple of things to be
>>clarified (CLA etc).
>>
>>In the meantime, feel free to create a JIRA issue for your enhancements!
> 
> I'm
> 
>>sure that Dmitriy, Bill and co will be happy to have an early look at
> 
> this.
> 
>>Juergen
>>
>>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
> rv556WE9CYsBzgbrTtkRqLU=
> =qCQl
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-- 
William G. Thompson, Jr.
Associate Director for New Technology
Enterprise Systems and Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...

[Springframework-developer] Portlet MVC Status

[John L. <jl...@ar...>]

It's been over a month since this discussion and there is still no 
progress on merging together the contributions to the Portlet MVC 
framework.  Several of us are working with this framework on critical 
projects and would really like to start moving it forward in a reliable 
direction.

Would it be better for us to start a separate sourceforge or java.net 
project for this until we can work on merging back into Spring proper, 
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after 
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is 
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things 
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your 
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

RE: [Springframework-developer] Portlet MVC Status

[Tim K. <tim...@vi...>]

We too have an interest in the portlet integration with Spring, and this
state of limbo is starting to get a bit distressing.  I suspect that
Juergen's simply trying to get 1.2 out the door - and that once he does so
tomorrow, there will be more progress on this end when 1.3 dev begins in
earnest - at least I hope so.  I don't profess to know what exactly is on
the Spring developer's minds right now.  :)

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
John Lewis
Sent: Wednesday, May 11, 2005 7:55 PM
To: spr...@li...
Subject: [Springframework-developer] Portlet MVC Status

It's been over a month since this discussion and there is still no 
progress on merging together the contributions to the Portlet MVC 
framework.  Several of us are working with this framework on critical 
projects and would really like to start moving it forward in a reliable 
direction.

Would it be better for us to start a separate sourceforge or java.net 
project for this until we can work on merging back into Spring proper, 
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after 
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is 
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things 
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your 
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet MVC Status

[Juergen H. <ju...@in...>]

Quite accurate, that assumption :-)

My single most important concern is 1.2 final - has been for the past few
weeks. There's a whole load of new stuff in 1.2, and it shows in terms of
refinement and maintenance effort. The TopLink support alone took far more
time than expected...

Anyway, the Portlet support is a key feature for Spring 1.3, alongside
Spring Web Flow. I intend to kick that work off right after 1.2 final, so
please stay tuned :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Kettering
Sent: Thursday, May 12, 2005 5:37 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet MVC Status



We too have an interest in the portlet integration with Spring, and this
state of limbo is starting to get a bit distressing.  I suspect that
Juergen's simply trying to get 1.2 out the door - and that once he does so
tomorrow, there will be more progress on this end when 1.3 dev begins in
earnest - at least I hope so.  I don't profess to know what exactly is on
the Spring developer's minds right now.  :)

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
John Lewis
Sent: Wednesday, May 11, 2005 7:55 PM
To: spr...@li...
Subject: [Springframework-developer] Portlet MVC Status

It's been over a month since this discussion and there is still no
progress on merging together the contributions to the Portlet MVC
framework.  Several of us are working with this framework on critical
projects and would really like to start moving it forward in a reliable
direction.

Would it be better for us to start a separate sourceforge or java.net
project for this until we can work on merging back into Spring proper,
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet Form Controllers

[Rob B. <cro...@ya...>]

I thought I heard somewhere a while ago the Spring
portlet support would be in 1.2?

Later
Rob
--- Juergen Hoeller <ju...@in...> wrote:

> As I said, a subproject is just under consideration.
> The alternative is to
> release the portlet support as part of the core
> Spring 1.3 distribution. The
> rationale of factoring out subprojects is to let the
> core concentrate on its
> current scope and not introduce completely new areas
> of functionality. A
> secondary goal is to limit the size of spring.jar.
> 
> The current core web support and web MVC framework
> is used by the portlet
> support underneath, for example to render views (at
> least that was the case
> last year). So Spring Portlet depends on Spring core
> web (even core web
> MVC), but not the other way round: a case for core
> web MVC staying part of
> the core distribution, but Portlet support
> (optionally) becoming a separate
> subproject.
> 
> Note that Spring's core web support is of interest
> to many people: not only
> to web application people, but also to rich client
> developers accessing
> HTTP-based remote services (running in a Servlet
> container). Portlet support
> is more specific and has a narrower target audience.
> 
> A further advantage of a separate subproject is that
> it can evolve more
> easily. Specific sample applications, tutorials,
> tools etc can be added
> without having to worry about scope or size of the
> core Spring distribution.
> 
> Anyway, this has not been decided yet and does not
> have to be decided right
> now. It's gonna become an important topic after the
> Spring 1.2 release,
> though.
> 
> Juergen
> 
> 
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]On
> Behalf
> Of Jean-Pol Landrain
> Sent: Friday, March 04, 2005 7:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet
> Form Controllers
> 
> 
> I quite agree with Rob. Except, of course, if you
> plan to create a
> subproject for Spring MVC too. This would allow a
> Spring "à la carte".
> This would keep the framework light, but would
> perhaps be a bit confusing to
> the users. Perhaps a "plugin" functionnality would
> be nice if the number of
> projects grows : you would have a core Spring and be
> able to plug in, for
> example by using a dedicated XML file, the other
> sub-projects you want to
> use. That's just an idea.
> 
> Cheers,
> Jean-Pol.
> 
> ----- Original Message -----
> From: "Rob Butler" <cro...@ya...>
> To:
> <spr...@li...>
> Sent: Friday, March 04, 2005 7:01 PM
> Subject: Re: [Springframework-developer] Portlet
> Form Controllers
> 
> 
> > Why would you have a separate sub-project for the
> > portlet support in Spring?  That would be like
> having
> > a separate sub-project for the web MVC stuff, and
> a
> > separate sub-project for the DAO related stuff,
> and
> > another one for AOP, etc.
> >
> > Later
> > Rob
> > --- Juergen Hoeller <ju...@in...>
> wrote:
> >
> >> Sounds like good stuff :-)
> >>
> >> On this occasion: Let's discuss the road to an
> >> official release of the
> >> Portlet support. We consider releasing the
> Portlet
> >> support as an official
> >> subproject, i.e. as a separate distribution and
> with
> >> a separate CVS module
> >> (or even separate CVS repository). The
> association
> >> would be similar to the
> >> just-announced Spring subproject status of Acegi
> >> Security, and the already
> >> established status of Spring RCP.
> >>
> >> Very importantly, the portlet subproject needs a
> >> dedicated developer team.
> >> Any volunteers? :-)
> >>
> >> Juergen
> >>
> >>
> >> -----Original Message-----
> >> From:
> >>
> >
>
spr...@li...
> >>
> >
>
[mailto:spr...@li...]On
> >> Behalf
> >> Of John Lewis
> >> Sent: Thursday, March 03, 2005 6:53 PM
> >> To:
> spr...@li...
> >> Subject: [Springframework-developer] Portlet Form
> >> Controllers
> >>
> >>
> >> We've been working on porting a fairly complex
> >> enterprise application
> >> from the Spring Servlet MVC framework to the
> Spring
> >> Portlet MVC
> >> framework.  As Nick Lothian and Rainer Schmitz
> >> discovered, the Form
> >> Controller hierarchy is difficult to port over
> from
> >> the Servlet area to
> >> the Portlet area because of the two-phase nature
> of
> >> portlet requests.
> >> Since we were porting a large number of existing
> >> controllers descended
> >> from AbstractController, AbstractFormController,
> or
> >> SimpleFormController, it was critical to that all
> >> the former
> >> functionality of these parent be present and that
> >> our logic work the
> >> same as before.
> >>
> >> Nick Lothian's version of
> >> SimplePortletFormController gave us a good
> >> starting point and helped us understand a lot of
> the
> >> issues with portlet
> >> development in general and with Spring portlets
> in
> >> particular.  However,
> >> a lot of our controllers manage database content,
> so
> >> we needed proper
> >> separation between the action and render phase of
> >> the request, which
> >> this controller did not give us.
> >>
> >> Rainer Schmitz's work went much further and
> provided
> >> the traditional
> >> hierarchy of controllers and further demonstrated
> >> the issues with
> >> separating out the two phases of the portlet
> >> request.  However, these
> >> still did not give us the complete control that
> we
> >> needed.  We
> >> especially needed a version of
> SimpleFormController
> >> that could handle
> >> the separation of the action logic from the
> render
> >> logic.
> >>
> >> Over the past few months we have developed a new
> set
> >> of the
> >> AbstractController, BaseCommandController,
> >> AbstractFormController, and
> >> SimpleFormController classes that we think
> >> rigorously address all the
> >> issues with portlet development and that have
> >> allowed us to port over
> >> existing servlet controllers with relative ease.
> >>
> >> We've included a portlet version of
> >> WebContentGenerator to give the
> >> controller classes their proper ancestry and
> provide
> >> control over things
> >> like content caching and access to the web
> >> application context and to
> >> centralized logging.
> >>
> >> We've also create a new set of the binding
> classes
> >> (PortletRequestDataBinder,
> >> PortletRequestParameterPropertyValues and
> >> PortletRequestBindingException) that support
> special
> >> field markers,
> >> correct problems with form elements such as radio
> >> buttons and
> >> checkboxes, and handle redisplay of invalid
> submits
> >> of non-string
> >> parameters properly.
> >>
> >> All of the classes are fully documented,
> including
> >> workflow descriptions
> >> in the controllers that cover the special nature
> of
> >> portlet development.
> >>
> >> Our hope is that these classes can handle the
> needs
> >> of everyone working
> >> with form controllers in Spring portlets and that
> >> these can be merged
> >> into the sandbox source code.
> >>
> >> The classes are posted in a zip file on the
> Spring
> >> Portlet Wiki page at:
> >>
> >
>
http://opensource.atlassian.com/confluence/spring/display/JSR168/
> >>
> >> The link to the file is (sorry for the long
> link):
> >>
> >
>
http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp
> >> ring-portlet-controllers.zip
> >>
> >> Please send me any questions or comments you may
> >> have about these
> >> classes.  We are eager to support their adoption
> in
> >> the Spring Portlet
> >> community.
> >>
> >> John Lewis
> >> jl...@ar...
> >>
> >>
> >>
> >>
> >
>
-------------------------------------------------------
> >> SF email is sponsored by - The IT Product Guide
> >> Read honest & candid reviews on hundreds of IT
> >> Products from real users.
> >> Discover which products truly live up to the
> hype.
> >> Start reading now.
> >>
> >
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >
>
-------------------------------------------------------
> >> SF email is sponsored by - The IT Product Guide
> >> Read honest & candid reviews on hundreds of IT
> >> Products from real users.
> >> Discover which products truly live up to the
> hype.
> >> Start reading now.
> >>
> >
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >
> >
> >
> >
> >
> > __________________________________
> > Celebrate Yahoo!'s 10th Birthday!
> > Yahoo! Netrospective: 100 Moments of the Web
> > http://birthday.yahoo.com/netrospective/
> >
> >
> >
>
-------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT
> Products from real users.
> > Discover which products truly live up to the hype.
> Start reading now.
> >
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> 
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/