Re: [Springide-eclip-developer] Brainstorming about validator improvements

[Torsten J. <tor...@on...>]

> P.S.  Speaking of validation, the problem marker on 'anonymous'
> inner beans doesn't give enough information to pinpoint the bean
> without relying on line number hacks.  It would be nice to come
> up with a 'path' for beans i.e.
>
> outerBean/middleInnerBean/innerInnerBean
>
> Though, we'd have to be carefull on the seperator (/ is not a good
> one!)

A bean path is not needed anymore. Anonymous inner beans have a unique 
name (pattern  "<class name>[#<occurrence counter>]") now (for details 
refer to my previous mail).

Cheers,
Torsten


On 15.11.2004, at 20:14, Watkins, David wrote:

>  Hi,
> I've been having a (slow) think about this and haven't really
> come up with any good options :(
>
> My current thinking.....Problem markers should be split into
> two broad categories:
>
> 1) Definate problems/errors - property doesn't exist/class
> not found etc.
>
> 2) Context warnings/information - referenced/parent bean
> not found in 'this' config file.
>
> These are the only markers attached to the resource.
>
> A second level of problem 'markers' (though not really markers)
> would operate on the config sets (only visible in the bean view)
> which indicate that a config set is incomplete (i.e. a bean ref
> is unresolvable) - this works only if we assume that there are
> no 'partial' config sets - which implies that a config set
> is roughly equivalent to a standard Spring Context.
>
> If this isn't acceptable then a flag could be included in the
> config set definition which indicates "I should be complete"
> - this flag would basically be a manual way of saying this
> config set is equivalent to a context.  In this scenario the
> validation steps in the above paragraph would only be applied
> if the flag is set.
>
> If we adopt the config set =~ context approach it gets us
> someway towards the idea put forward by Andreas Oberhack
> (some weeks ago - 4 Oct) that we could add a 'launch context'
> extension.  Perhaps a simpler option would be to add a
> 'Generate Spring Boot Class' action by resolving the
> config set into an array of classpath resources and
> feeding them into a spring ClassPathXmlApplicationContext.
>
> Anyway, just thought I'd chip in now before the question gets
> forgotten about!
>
> Cheers,
>   dw
>
> P.S.  Speaking of validation, the problem marker on 'anonymous'
> inner beans doesn't give enough information to pinpoint the bean
> without relying on line number hacks.  It would be nice to come
> up with a 'path' for beans i.e.
>
> outerBean/middleInnerBean/innerInnerBean
>
> Though, we'd have to be carefull on the seperator (/ is not a good
> one!)
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Springide-eclip-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springide-eclip-developer
>