Re: [Figleaf-developer] Proxies back in and some thoughts on the Bootstrapper

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

sam...@ma... wrote:

>Right, the InfromativeFactoryImpl now creates proxies as requested.
>  
>
We've got an Introspector, InformativeFactory, and ObjectIntrospector 
interfaces. I think that's at least 1 too many. ObjectIntrospector has a 
method "ClassDescriptor createInformative(Object o)" that doesn't seem 
to be right. Shouldn't it return an Informative?

Is it necessary for the ObjectIntrospector interface to have methods 
getDescription, getDisplayName, getProperties and getProperty? Those are 
all things that the ClassDescriptor interface provides. I think not, so 
it then is essentially the same as Introspector.

>By way of a proof of concept, I've written a new ConfigurableBootstrapper based
>on your original code. The only difference being that it now hands-off the
>determination of which beans to use to a new ApplicationConfiguration class
>(more specifically a SpringApplicationCnfiguration). The only other difference
>is that rather than having the user specify which bean is runnable, I've assumed
>a bean called Runnable - my aim here is for things to be simple. I also added a
>TransientObjectManager which will hold objects in memory, although at present it
>doesn't do anything. The SimpleApplicationContext I use looks like this:
>
><bean id="Introspector" class="net.sourceforge.figleaf.impl.IntrospectorImpl" />
>	
><bean id="ObjectManager"
>class="net.sourceforge.figleaf.impl.TransientObjectManager" />
>
><bean id="Runnable"
>class="net.sourceforge.figleaf.viewer.swing.ConfigurableSwingViewer">
>  <constructor-arg>
>    <ref bean="ObjectManager"/>
>  </constructor-arg>
>
>  <constructor-arg>
>    <!-- Insert classes to register here -->
>    <list>
>      <value>net.sourceforge.figleaf.example.imageviewer.ImageAlbum</value>
>    </list>
>  </constructor-arg>
></bean>
>
>The ConfigurableBootstrapper like this:
>
>String springConfigFile = line.getOptionValue("config");
>SpringApplicationConfiguration config = new  
>  SpringApplicationConfiguration(springConfigFile);
>getInstance().setObjectManager(config.getObjectManager());
>
>//load the worker bean
>config.getRunnable().run();
>
>  
>
I guess your main objective is to get ConfigurableBootstrapper to the 
point to where it can use something other than 
SpringApplicationConfiguration?


>Next, I've created a slightly different SwingViewer - my version takes all
>dependencies via constructors (which I think is neater than using setters to
>define dependencies). I've also defined internally a default view map as I think
>it's OK for us to assume default views (e.g. text entry fields) and then allow
>the developer to override it. I've also changed it so the list of registered
>classes to be passed in. All of this is by way of a test to see how simple we
>can make application setup - I'd appreciate your comments. My
>ConfigurableSwingViewer isn't as functional as yours - I originally based the
>code on yours but then realised I didn't need to reinvent the wheel, just show
>how it could be invoked.
>
Setters somehow seemed more flexible when using dependency injection, 
perhaps not.

Do you have in mind how to allow the developer to override the default 
view types and to provide additional view types?

Now to the classes. We have to think about this carefully. Currently a 
class is represented by an InformativeDescriptor instance. It includes 
information about the class (it's class name, a display name, and a 
description) as well as methods that can be used to do things with that 
class, such as get a new instance of it. Of course that can be done 
other ways as long as you have the class name. But I wanted to 
eventually be able to associate security information with the class, 
such as restricting which users could create a new instance of the class 
represented by a given instance of InformativeDescriptor, who can delete 
an instance, etc. Additionally I wanted to be able create "context 
groups" that are collections of InformativeDescriptors. So for instance 
if there are classes A, B, C, and D, I can assign A and B to one context 
group and C and D to a second context group. Then I can assign one user 
so that on startup he sees the classes in the first context group but 
not the second, and vice-versa for a second user. A user could be 
allowed to see multiple context groups, for example an administrator or 
other super user would have access to all context groups.

I believe this kind of complex security and relational model of classes 
is only possible if there is a first-class object representing the 
class. My approach was to need only 1 class seeded in the database, and 
that was an InformativeDescriptor that describes itself. With that you 
can create objects for all other classes needed and setup their 
security, assign them to context groups, etc.

I think the best approach is to write a "system initializer" program 
that would take some config file or even user input and setup the system 
the first time. This would include classes for which to create default 
InformativeDescptors, a super-user account, etc. Long term I think this 
is right way to do it because user passwords should be stored in the 
database using a 1-way hash or some other scrambling method, not in 
clear text, which means we need to write a program to get the first user 
in the system so they can log in and create all the others.

Greg