[Springframework-developer] Summary of pending points

[JP P. <jp....@ti...>]

Hi everybody,

I just summarize the few points I discussed recently + 1 new.

1) INHERITANCE OF attributeCSV
The cause of the changed behaviour was found by Juergen. In abstract, we
could say it's a mapped property. As this, the current behaviour is
cleaner. Just, for completeness, it should be possible to changing or
adding new keys in the parent defined map with a syntax like :
My_view.CSVAttribute.header=head.jsp.

Perhaps, it still works. Anyway, it's minor and none of us has now time
for this kind of problematic. We simply know that the CSVAttribute is no
more merged with parent's one.

2) JBOSS DEPLOYMENT FEATURES CRASH
I found the responsible: com.interface21.web.util.Log4jConfigListener.
I simply don't use any more the listener and the application can
normally be un-deployed and redeployed. It's not surprising as JBoss
itself uses log4j and numerous people have or had troubles with
application use of log4j with JBoss.


3) SHORT LIVED CONTEXTUAL INFO IN MappingSqlQuery
I discussed with a few people about this topic. The SQL parameters are
not always sufficient to be able to create the correct object in the
mapRow method. If the extra information is only valid during the request
process, instance variables are not a good way. The cleanest way is
clearly adding the data as new parameter in the "execute" methods typed
as Object. The framework has only to provide this information in a new
(optional) parameter in mapRow.

No one seems, for time being, understand the need, but it's clear: I
will simply create the Objects with a target Locale. For now, I don't
use anymore the MappingSqlQuery, MappingSqlQueryWithParameters and
SqlQuery classes from the framework. I use instead a modified set of
them which is completely backward compatible and don't break tests.
Nevertheless it adds the possibility of using an extraneous Object
parameter for the described need by adding some new signatures.

I have for now not implemented the convenience methods with the new
feature as I use only the core signature. I also have not updated the
doc. It's why I cannot propose them in this status. The only drawback is
that I have to check changes in these classes in the framework. I will
put them in the sandbox when they will look cleaner.


4) CHECKBOXES AND MULTISELECT LIST BOXES
They exist in Html. We can't say: Don't use them when you work with
Spring (web). I provided a solution that works with very little change
and without design hacks. But we could have a design choice to make.
Clearly, Html user data are generally Strings, but can be
multi-dimensional (array, collection, map or what you want). See JSTL,
you have param.xxx and paramValues.xxx. The same in the javax API:
request.getParameter() and request.getParameterMap(). So, despite my
solution works, it's possibly not completely mature.


5) NEW CONTROLLER
That is a new topic. I'm using a self made Controller which I will soon
propose beside the WizardController. Its goal is to enclose a complete
CRUD scenario.
List of existing items with links to edition + link to new(add) - Form
edition - optional confirm views for RUD operations - easy separate
methods for each task. It will come with two AbstractControllers and a
ConcreteControllerExample. The whole in a tiny Demo Application. It's a
largely reusable set, notably for administration pages like handling
reference tables.

That's all areas for now,

Regards,
Jean-Pierre