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