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