Re: [Springframework-developer] =?utf-8?q?Some_questions_about_Spring?= =?utf-8?q?_Portlet=09MVC?=

[Joerg H. <joe...@gm...>]

John Lewis <jlewis <at> unicon.net> writes:

> Whew!  That is a long and complicated set of questions.

Hello John,

thanks very much for your time and effort to dive into it.

> Issue 1:
> 
> First, please realize that the concrete Controller hierarchies that come 
> with Spring Portlet MVC (and Spring Web MVC, for that matter) are 
> designed for certain common usage patterns.  While they are very 
> flexible, it is certainly possible to come up with a way of operating 
> that does not lend itself to using these controller directly.  It sound 
> like this might be the case in your instance.

Independent from my more complex use case it's very easy to create a setup that
breaks: you need 2 Controllers using a different command and a HandlerMapping
that selects the one for the ActionRequest and the other one for the
RenderRequest. The render phase Controller will fail since it retrieves the
command in a way that it gets the one from the action phase. I don't know if
that setup is that unlikely.

>  >From what I can tell from your description, it sounds like you might 
> want to factor out the display of the search results from the form 
> controller that edits search criteria in order to make things simple.  
> So, I might recommend redesigning things slightly as follows:

My setup is nearly as you describe it. I have two objects for criteria and
config in the session and some meaningful default for the first access. It's
wrapped by a DTO used as command. The only difference seems to be the splitting
of my TableViewController into a TableViewController (render phase) and a
TableViewCriteriaController (action phase). Unfortunately, I don't think it
can't help. Only solution is IMO to exactly use the same command object for both
my controllers. Currently they are slightly different because of a third object
not needed for the TableViewConfigController.

So I know how to work around it. Reporting this issue was more about the general
thing I rephrased above. And possibly there could have been a work around I was
not aware of. Somehow enforcing the render phase controller to recreate the
command instead of just relying on finding it in the PortletSession ...

> Issue 2:
> 
> I agree there is no easy mechanism to detect if values in the command 
> object have in fact changed.  There are a few server-side optionsI can 
> think of:
> - Use all custom PropertyEditors in the DataBinder, register 
> PropertyChangeListeners and react to PropertyChangeEvents.  This is all 
> really intended for GUI programming, but could be used here.  Yuck.

I already had a short look on it. Since the listener is called on every
setValue() I can't see how to use it:

rendering:
PropertyEditor editor = new PropertyEditor();
editor.setValue(value); // initial value => first change event
editor.getAsText();

binding:
editor.setAsText(valueFromRequestParam); // new value => next change event

How to determine if the value has actually changed?

The funny thing is the BeanWrapperImpl instantiates some PropertyChangeEvents,
but only uses them for exception handling.

> - Create some kind of custom PortletRequestDataBinder that will watch 
> for changes in value -- add this to your controllers by overriding the 
> createBinder method.  Also not pretty.

In this case I live with the easier (but hacky) work around to set a hidden
field value on the client.

> Anyway, I agree this is a good idea.  I added it to my list of thing to 
> implement someday.  You should go create a JIRA item for this feature.

http://opensource.atlassian.com/projects/spring/browse/SPR-3516

> Issue 3:
> 
> This really isn't a portlet question at all -- this is a straight JSP 
> problem.

Yes, the root issue is not Spring related. It gets one with the mentioned work
around with form:options since it resolves the expression internally, but I
can't influence the labels [4]. And the general way to handle the latter fails
with form:option as I have to use c:forEach then.

Thanks very much,

Joerg

> > [4] http://opensource.atlassian.com/projects/spring/browse/SPR-3484