[ID3 Dev] Implementation question

[Jud White]

TIPL, TLAN, TCON come to mind as Txxx frames you'd (probably) want to implement as something other than a TextFrame.

I like the delegate idea, I've thought about implementing it for lazy creation.  I haven't had a performance problem with creating all the types up front, but with delegates the dictionaries could be kept static.  I'll have to try this out, thanks Andy.


----- Original Message -----
From: Brian Mearns [mailto:bmearns at coe.neu.edu]
To: id3v2 at id3.org
Sent: Wed, 24 Jan 2007 12:08:48 -0500
Subject: Re: [ID3 Dev] Implementation question

Thanks Jud and Andy, for the response.

The factory method Andy described is more or less how I do it now, but 
with a dictionary like Jud described. The problem is that I want more 
general coverage than having to specifically register every frameID. For 
instance, as I mentioned, I have a class TextFrame that is the base 
class for implementing T*** frames like title and artist. Instead of 
having to register TextFrame for all the different T*** frame ids, I'd 
like it to be smart enough to figure that out, while still delegating to 
the dictionary for other frames.

I guess there's no reason I can't just IF it in to check if the frame id 
starts with T, and handle it correctly. That just seems ugly. Ideally, 
I'd like to be able to register different classes or factories for 
general classes of frames (not OO classes, just general groupings like 
the T*** class of frames) as well as for specific frame IDs. But I 
suppose the T*** and non-T*** are the only real classes of frames there 
are, so it wouldn't be difficult to kluge it. But I still feel like it 
is a kluge.

Thanks,
-Brian

Jud White wrote:
> Brian,
> I keep two dictionaries for each tag format, one for single occurrence 
> frames and one for multiple occurrence frames.  The keys are always 
> FrameID's.  The single occurrence dictionary's value is of type IFrame, 
> so without knowing the actual type of the specific frame you can call 
> the Read/Write methods, you just need to know the FrameID.  The multiple 
> occurrence dictionary's value implements another interface with an Add 
> method that returns an IFrame, which can then have its Read/Write 
> methods called.  I also use a type (UnknownFrame) to catch values not in 
> either dictionary and ensure they are written back.  Adding another 
> supported frame just requires adding another key/value to the 
> appropriate dictionaries, no need to update the Read/Write methods of 
> the ID3 class.
> 
> Brian Mearns wrote:
>> I have a question for developers who use an OO paradigm for ID3 work: 
>> Assuming there are different classes to implement different frames, 
>> but not neccessarily one class per frame (for instance, a class to 
>> handle text-frames and another to handle everything else), what 
>> pattern do you use to decide which class will be called on while 
>> parsing a tag? I'd like to keep it as abstract as possible so that, 
>> for instance, if I add another class to handle another type of frame 
>> later, it will be easy and consistent to work it in.
>>
>> Is that at all clear?
>>
>> Thanks,
>> -Brian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org