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

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

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

> sam...@ma... wrote:
> 

> >Well, my code handles objects which haven't implemented Informative (in
> fact
> >thats what 80% of what I've done so far does) so we don't have to worry
> about
> >that. I actually believe one of the big selling points is the lack of work
> a
> >developer has to do to get up and running, for that reason I'd like for the
> 0.1
> >release for the developer to drop a vanilla pojo domain model in and have to
> do
> >no work for it to run.
> >  
> >
> That would be great to have working.
> 

<snip>

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

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

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

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


sam
http://www.magpiebrain.com/