Re: [Figleaf-developer] No need for proxies - at least at the moment

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:


> >I think we need to abstract out the reliance on Spring. Using an
> >ApplicationContext.xml is fine if you are using spring, but it would be nice
> if
> >we couls have a unified API for configuring the layers - the default
> >Bootstrapper would use spring, but you could just as easily use a different
> >implementation.
> >
> >  
> >
> The benefits of Spring are the dependency injection and implementation 
> of a lot of useful classes in the areas of AOP, transactions, and 
> persistence. It isn't required to configure Spring with an xml file. 
> That's just the method I've chosen now because it was fastest to get 
> something running. We should be able to put our own configuration 
> mechanism in place and still use Spring for various things. I know in 
> its manual it mentions which interface/class to implement to get 
> configuration information from somewhere other than an XML file.

I understand that - but the ability to use something other than Spring makes
testing easier (it means you don't have to invoke Spirng when attemtping to Unit
test some things). Spring is a good fit for what we want, but thins can change -
by keeping any association abstract we make transition to something else later
on a lot easier.

> >>So, the developer doesn't have to write any main class! The bootstrapper 
> >>talks to Spring to handle the dependency injection and "running" the 
> >>class specified with the -bean command line parameter.

> >Which I like! Not sure if this will apply as easily with a client-server
> >application though.
> >
> >  
> >
> It should work. Just swap out the bean definitions with those that do 
> something else: client work or server work.

Yep - I guess we'll worry about that when it happens


> >As you say the problem is getting this information into the system in the
> first
> >instance. Again pre-seeding the database is one potential mechanism for
> getting
> >information into figleaf, but how about we keep it simple for now? Lets add
> a
> >method to Bootstrapper registerClass, which we could even configure using a
> >Spring and its ApplicationContext context file. Personally I would love to
> be
> >able to run an app without having to edit any config files and just specify
> >everything using a simple piece Java code, and have config files call this
> API -
> >it makes it easy to test, and many people are happy configuring applications
> in
> >code.  
> >
> I don't think class registration and configuration are necessarily the 
> same thing. The reason is because class accessibility should integrate 
> with the security mechanism. By having a class that describes classes, 
> it enables all of the functionality that Informative has but at a sort 
> of meta-level.

Agree

> So far to bootstrap the system you have to insert 1 record in the 
> database for the core InformativeDescriptor that describes itself. After 
> that the GUI can be used to create the rest of the classes in the 
> system. I hope to have that working very soon.

Which sounds good, but I'd still like an abstract ClassRegistry-type thing so
people don't have to seed their persistence mechanism.

> >
> >If we have an abstratc notion of a ClassRegistry, the SwingViewer could look
> at
> >this rather than the database. Then along with the other things, we
> configure a
> >ClassRegistry. Why don't I look at implementing that code?
> >
> I guess the question is, should the ClassRegistry be any different than 
> the standard persistence mechanism? It would seem easier to use the 
> standard persistence mechanism, since it's already used to store and 
> retrieve data. Then the same framework can be used everywhere to 
> edit/view the classes as regular objects.

The problem with this is that developers will always have to seed their
persistence mechanism which increases the amount of work. In fact they'll have
to do that before the deployment of every new version of the software that
introduces new classes. I really want figleaf (or whatever we call it!) to
emphasise how easy it is to drop the code in and run. What benifits does having
the classes registration handled by the persistence mechanism have over handling
it like standard application configuration? 

sam
http://www.magpiebrain.com/