[ANN] IdeaSpring 1.1

I forgot :
+ Completion in attributes (local, bean, parent, depends-on, ...)

Wow! New version is just great - new improvements are very useful!

However, I've found minor annoyance and hope my comments about it could
be helpful. I understand that probably this my particular case is not
common situation but yet...

The issue is as follows - there are several Spring config files. They
represents the entire Spring Application context and bean definition
from one config may refer to bean declared in another config. There are
no appropriate import statements in config and all configs are included
into ApplicationContext during ApplicationContext creation.

Since there are no import within config file that refers to bean from
another config, Idea Spring considers reference to external bean as
error and this is really not convenient.

My suggestion is as follows- is is possible to change functionality that
checks whether "ref" attribute is valid will consider wider scope and
will try to find reference not in currently file only, but in the entire
set of config files (and this is probably related to autocomplete
function for bean references too)? I suppose that with such change
IdeaSpring will be just perfect tool to work with Spring.

Thank you.

Best regards,
Andrew Sazonov.

Just another small suggestions - it could be very useful if IdeaSpring
will provide the user ability to specify some filter for beans that are
shown within IdeaSpring tool window - say, based on some pattern/regexp
that could be applied to bean name.... or some pattern applied to bean
class....

Best regards,
Andrew Sazonov

Can you please check if you added all your config files ?

Reference to external bean from another config (]]> for example) is not considered as an error. I look throught alll the registered config files.


Thank you.

Hello Maurice,

Some ideas/suggestions:
1) Insert...Dependency action (java editor):
-Select a dependency in the context files
-A typed field (prefer interface) plus setter/ctor argument is created
-All definitions of the class inside context files are update to include
the new dependency

2) Extract Parent Bean refactoring (xml context editor)
-Select a number of defined properties for a bean
-Select id/name for parent definition
-Create a parent definition (abtract=true), and a parent reference from current
bean
-Check for candidates to update (similar to extract method)

3) Inline Parent Bean refactoring (xml context editor)
-Related to (2), similar to inline method

4) Inspection + QuickFix for 'old style' long value declaration (xml context)
-Search for 'bar' and suggest quickfix to ']]>'
(there are a number of similar shorthand notations)

Regards,
-tt

Taras,

I'm already working on 4.

I'm understanding 2 and 3 but i don't see what you mean in 1.


Can you please explain it a little bit more ?


Thank you

Hi Maurice,

Do you intend to make this a commercial product, or will you make it a open source plugin?

1) In the current version 1.1, it seems that cross-context file references do not work properly:

(Where 'keyProvider' is a bean declared in another context file, included in config set) 2) A typical Spring webapp has its context files set up in a hierarchical manner: -The context file loaded by the ContextLoaderListener -The DispatchServlet-specific web contexts (xxx-servlet.xml) Beans from xxx-servlet can refer to the beans in the parent context, while beans in the parent context cannot refer to beans in xxx-servlet. The definition of config sets should be modeled is a hierarchical fashion. 3) Usability improvements in dialog: -Allow multiple select/multiple remove -provide hotkeys for the available buttons -Is it so that 'current selected' == 'current config set'? A nice feature would be SmartType completion in context file. To be more specific, in the following locations: 4) -retrieve all accessible constructors
-retrieve all ctor args from all ctors
-only suggest beans that are compatible with at least one ctor-argument

6) Specialization of (2): if "index" attribute is provided, retrieve only the types at that index for all available ctors.

7) Specialization of (2): if "type" attribute is provided, use that to filter matching beans.

8) As a nice addition, provide an inspection to check the "type" attribute on all "constructor-arg" elements: is there actually a ctor that has such a parameter type?

Hi Maurice,

I'll try to explain (I think it would be a really powerful addition to the current plugin)...

In our application, one way to categorize components would be the following:
-The component is registered only once (in all context files) (type "1")
-The component is registered a number of times (type "2")

In the typical Spring web application, type 1 is much more common. Typical examples of beans that are registered only once are:
-Controllers
-DAO classes
-Service components

For such components, it's quite commons to have the following flow (in terms of developer activity):
pre 1) The component need to implement some additional functionality
pre 2) To do this, the component needs a collaborator (which is likely already registered in the context)
3) Add a (private) field for the given component
4) If the collaborator has a service interface, use that as type
5a) If the collaborator is optional, add a property setter
5b) If the collaborator is required, add a constructor arg
6) Update our declaration in the context to include the required or element. This request is essentialy about automating step 3,4,5 and 6 in one fluid action: a) User selects "Insert->]]>Dependency"
b) Present a list similar to "Ctrl-F12"
c) User types CamelBack pattern
(For instance, I need the bean called "securityAuthorityDAO", I type "sAD and it's quite likely that there is only one match left, which I accept)
d) User select or

Result:
-Field of required type is added
-Constructor arg or property added to component
-Component definition in context is update to reflect dependency on new collaborator

Another (minor) addition would be support for PropertyPlaceholderConfigurer.

Example context chunk:
-

${jdbc.driver} ${jdbc.url} ${jdbc.user} ${jdbc.password} ]]>
-

Als the fragments like "${jdbc.driver}" should allow navigation, in a fashion similar to how other "Resource bundle key" reference providers work (<fmt:message> for instance).

As a bonus, add a reference provider for "classpath:" and "classpath*:" pseudo-urls, to allow transparent navigation to the files referenced.

Other wishes:
-Deleting all config sets does not remove plugin warnings for context files
-property name validation
-rename (rename id or name, update all references)
-change the Ctrl-Shift-F7 to make distinction between definition (pink) versus usage/dependency (blue), similar to variable definition/reference in Java files.
(I guess there should be something in OpenAPI, since the JSP editor can do it for JSP variables)
-Show warnings for classes/FQN references that can not be found in project classpath
-Inspection: bean depends on abstract bean
-Inspection: non-abstract bean with no class specified

Spring MVC specific:
-Provide navigation for "formView"/"successView" properties, if ViewResolver configuration can be parsed.

Hello Andrew,

Just curious, what kind of beans would you like to filter out?

Just another small suggestions - it could be very useful if IdeaSpring
will provide the user ability to specify some filter for beans that
are shown within IdeaSpring tool window - say, based on some
pattern/regexp that could be applied to bean name.... or some pattern
applied to bean class....

Best regards,
Andrew Sazonov

1) It's a bug with shortcut forms.... i made a mistake as i thought that shortcut forms were working like ]]>

I'll make a patch release tonight or tomorrow.

3) Is it so that 'current selected' == 'current config set'?

Well config sets works like groups right now so you could hav a config set for security, one for database access, ....

Do you intend to make this a commercial product, or will you make it a open source plugin?

I really don't know....
I don't have any plan right now.