[Figleaf-developer] Class registration and data seeding

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

sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>
>  
>
>>>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? 
>
>  
>
I guess I take the seeding problem as a given. The more we can avoid 
seeding then great. But it seems like there is always some startup data 
needed - like when you install a new OS it needs to ask you for a root 
password. The task becomes how to make the data initialization as simple 
as possible. Also, we need to decide where to draw the line between what 
system required data is stored in configuration files and what is stored 
in the persistence mechanism.

Greg