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

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

sam...@ma... wrote:

>>>      
>>>
>>For now I'd even settle for just requiring objects to implement 
>>Informative completely themselves and get the persistence and UI layers 
>>worked out. It'll then be a functional platform to some extent. That's 
>>the approach I've taken so far.
>>    
>>
>
>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.

>My todo list once I've put proxies back in is a little sparse - might thought
>was that I should look at our API for typing the layers together. We want an API
>that lets us configure Spring (or Pico or whatever). I saw a bit of code like
>this written by the developer:
>
>public class MyFigleafApplication extends FigleafApplication {
>  public void setup() {
>    setPersistenceMechanism(new HibernateImpl("config.hbm.xml"));
>    setUIMechanism(new SwingImpl());
>    ...
>    registerClass(MyClass.class);
>    registerClass(AnotherClass.class);
>  }
>
>  public static void main(String[] args) {
>    new MyFigleafApplication().run();   
>  }
>}
>
>We may want to use config files for this later on, but for now doing it using
>Java code makes it easy to test and lets us concentrate on the important stuff.
>What do you think?
>
>  
>
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.

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.

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.

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.

Greg