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

[Greg S. <ste...@on...>]

sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>
>  
>
>>Have a look at ApplicationContext.xml (the Spring config file), now in 
>>the /conf directory, and also Bootstrapper.java. The 
>>ApplicationContext.xml specifies which persistence implementation to 
>>use, which ObjectManager class to use, and which viewer to use. The 
>>Bootstrapper takes command line arguments to tell it which "bean" to run 
>>(SwingViewer is runnable). I also added a run.sh script last night, 
>>which will let you see how it all fits together. I got it fired up last 
>>night.
>>    
>>
>
>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.

>>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.

>>One missing piece of the puzzle: registration of classes. I made an 
>>InformativeDescriptor interface who's job is to describe an Informative 
>>class. There is an InformativeDescriptorImpl as well. All the developer 
>>needs to do is pre-seed the database (or whatever the persistence 
>>mechanism is) with InformativeDescriptor records.
>>    
>>
>
>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.

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.

>>Right now, when the SwingViewer starts it searches for all 
>>InformativeDescriptor's in the database, and shows those. The 
>>InformativeDescriptor has a "newInstance" method that the UI will use to 
>>allow the user to create a new instance of the class described by the 
>>InformativeDescriptor. In a future implementation when we have logins, I 
>>believe the set of InformativeDescriptors retrieved should be dependent 
>>on the user, so different users can have access to different classes. 
>>And then with a security layer it can control if a user can create new 
>>instances of a class, etc.
>>    
>>
>
>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.

Greg