[Biococoa-dev] Design question

[Koen van der Drift]

>> One thing I'd argue for is an enumeration of defined feature types.  
>> The
>> user should be free to create their own, but there are huge 
>> advantages of a
>> set of non-custom ones.  Imagine being able to search an institute 
>> wide
>> plasmid collection for everything with a Vertebrate promoter, protein 
>> tag,
>> and unique BamHI site....
> True, we should try to keep a defined set, perhaps we need a 
> intermediate categories level here, like restriction enzyme or 
> structure type with defined subtypes like BamHI for the first, and 
> helix, beta strand for the second. Let's see how far we can come, a 
> plist with proposed categories and subtypes might be an option here. 
> Keep in mind that the list might be pretty long, already containing at 
> least 700 restriction enzymes.

Mmmmm - I love BamHI  (sorry, I couldn't resist the joke ;)


>>> Another thought I would like you to comment on is the addition of a
>>> "history/editing dictionary" which keeps track of who added/edited a
>>> sequence and when/what things were edited. In general, I think it 
>>> would
>>> be nice if we would go for the "non-destructive editing approach"
>>> wherever possible. My would-be Biococoa based DNAStrider-like app 
>>> would
>>> for instance allow the user to cut and paste fragments and vectors, 
>>> and
>>> it would be very nice if many of the editing could always be undone,
>>> and the original sequence could always be viewed. Think along the 
>>> lines
>>> of a modern video editing approach, the files are unchanged, only the
>>> displayed parts are changed. This could save a lot of memory/disk
>>> reusal/writing as well. Of course there must be methods to "crop" 
>>> your
>>> file as it has no use to keep a complete genome around if your only
>>> interested in one gene right...
>> As you point out, the danger here would be that we'd have to guess in
>> advance the information content that would best suit the user.  
>> Permanent
>> undo's are also out of keeping with most AppKit design practices, 
>> where the
>> UndoManager doesn't survive application quits.  I'm all for keeping an
>> internal Undo list in each sequence object and allowing that to 
>> transfer
>> with drag/drop actions and such, but I'm hesitant about writing it to 
>> disk.
>> Something like that might be better implemented on a per-program 
>> basis,
>> rather than at the root of BioCocoa.


I'm not sure if we should focus on saving, undo, etc right now. This 
should be left as an exercise for the user, because there are probably 
many different situations for as many different apps.


- Koen.