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