It is currently Sat Nov 26, 2011 7:54 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Domain Model
PostPosted: Mon Oct 26, 2009 9:17 pm 
Offline
Developer

Joined: Thu Oct 08, 2009 1:18 am
Posts: 62
Hello Devs,

I'm looking for input on the image I added to:

https://ted.nu/wiki/index.php/Shows.ted

It shows the object hierarchy of objects that could be in the Shows.ted file.

I'm looking to better define the domain model, and figure out which objects should be transient. This will allow us to create a better, less coupled, domain model that is needed for a proper web ui.

What I would like help with is identifying which objects in that image hold state that is required between restarts of the program.

I can slowly figure this out by seeing where the objects are created, and what information they store, but I'm hoping one of you will know already.

For example I'd like to decide that SeasonEpisodeScheduler is transient, and therefor doesn't need to be saved. I already know that they are created the first time you ask for one, so it's not a problem to create a new one. What I don't yet know is if they are customizable by the user, or if any of the objects they hold are customizable by the user.

Once I know this I can work on a translation/upgrader layer to a simple jaxb domain model. Then I'll be able to eliminate the binary shows.ted domain.

If you guys don't know, that's fine as well, I can figure it out.

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 26, 2009 9:38 pm 
Offline
Lead Developer
User avatar

Joined: Mon Jan 16, 2006 4:11 pm
Posts: 645
Location: Netherlands
I think this diagram is almost correct.

A 'standardstructure' is a superclass of a DailyDate or SeasonEpisode class. But a TedSerie only has 1 of those instances. The vector of episodes is kept in the SeasonEpisodeScheduler

The SeasonEpisodeScheduler now holds the whole schedule of a show. We might want to move that to the TedSerie class, or split the class in a schedule and a schedulecontroller.

In the end, it would be nice if we could lose the TedDailyShow as well, such that only the class of the schedule determines the episodes we are looking for (Daily episodes/Season Episodes/Sequential episodes). But we kept the difference because the way of parsing is different. , can you explain why that is? I think it had something to do with the fact that you can set a maximum number of episodes for a daily show, but you can't for a normal season/episode show.

In my view, you have one show class that has a schedule which contains episodes. Those episodes are where the difference between the kinds of show become clear. We now have a DailyDate, SeasonEpisode datastructure. In my ideal view, that is the only difference between a normal show and a daily show.

_________________
Roel

i watch: simpsons, south park, lost, top gear, true blood & fringe
download - documentation - bugs/feature requests - sourceforge -


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 26, 2009 9:51 pm 
Offline
Developer

Joined: Thu Oct 08, 2009 1:18 am
Posts: 62
roel wrote:
I think this diagram is almost correct.

A 'standardstructure' is a superclass of a DailyDate or SeasonEpisode class. But a TedSerie only has 1 of those instances. The vector of episodes is kept in the SeasonEpisodeScheduler


Correct, good catch. I missed one link from a TedSerie to a StandardStructure

roel wrote:
The SeasonEpisodeScheduler now holds the whole schedule of a show. We might want to move that to the TedSerie class, or split the class in a schedule and a schedulecontroller.


How come? Could we not look up the show schedule again when we needed it? Would a user change this schedule?

I think the main problem now is that it holds on to so many other classes. I'd like to start with just generating this data on startup, and then add caching to the different schedule sources (ted.guide.*), so they can look locally for most of their information.

TVDB already supports this by saving the XML files as you load information, and querying the server for just what has changed since the last update.

roel wrote:
In the end, it would be nice if we could lose the TedDailyShow as well, such that only the class of the schedule determines the episodes we are looking for (Daily episodes/Season Episodes/Sequential episodes). But we kept the difference because the way of parsing is different. , can you explain why that is? I think it had something to do with the fact that you can set a maximum number of episodes for a daily show, but you can't for a normal season/episode show.

In my view, you have one show class that has a schedule which contains episodes. Those episodes are where the difference between the kinds of show become clear. We now have a DailyDate, SeasonEpisode datastructure. In my ideal view, that is the only difference between a normal show and a daily show.


I completely agree, and this would be the direction I'd be moving in.

Thank you for the comments. Any other of the classes you can help me with? I'm really hopeful most of these objects won't need to be serialized.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 26, 2009 10:02 pm 
Offline
Lead Developer
User avatar

Joined: Mon Jan 16, 2006 5:46 pm
Posts: 904
Location: Netherlands
KenMacD wrote:
roel wrote:
The SeasonEpisodeScheduler now holds the whole schedule of a show. We might want to move that to the TedSerie class, or split the class in a schedule and a schedulecontroller.


How come? Could we not look up the show schedule again when we needed it?

Well, the schedule is needed all the time to display the release date in the main dialog to give an example. Don't know if that is a good reason to store it at its current position but that's why it's done.

Quote:
Would a user change this schedule?

How do you mean? To give him the option to adjust the schedule? That would be nice, but also quite tricky. Currently the schedule is created from 2 different sources so you don't know where specific information comes from. You would have to store that information then somewhere which gives extra overhead.

Quote:
In the end, it would be nice if we could lose the TedDailyShow as well, such that only the class of the schedule determines the episodes we are looking for (Daily episodes/Season Episodes/Sequential episodes). But we kept the difference because the way of parsing is different. , can you explain why that is? I think it had something to do with the fact that you can set a maximum number of episodes for a daily show, but you can't for a normal season/episode show.

The DailySerie indeed only downloads the latest x released episoded. This is done so ted doesn't download 30 episodes after you've been on vacation. Also you are most of the time only interested in the latest episodes.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 26, 2009 10:11 pm 
Offline
Developer

Joined: Thu Oct 08, 2009 1:18 am
Posts: 62
Jofo wrote:
KenMacD wrote:
roel wrote:
The SeasonEpisodeScheduler now holds the whole schedule of a show. We might want to move that to the TedSerie class, or split the class in a schedule and a schedulecontroller.


How come? Could we not look up the show schedule again when we needed it?

Well, the schedule is needed all the time to display the release date in the main dialog to give an example. Don't know if that is a good reason to store it at its current position but that's why it's done.


Sorry Jofo, I think I'm being confusing. I meant could we look up the information each time ted is started. Instead of persisting it to disk between restarts. I'm trying to figure out the minimum set of 'user data' that we need to persist between restarts of the program.

Quote:
Quote:
Would a user change this schedule?

How do you mean? To give him the option to adjust the schedule? That would be nice, but also quite tricky. Currently the schedule is created from 2 different sources so you don't know where specific information comes from. You would have to store that information then somewhere which gives extra overhead.


:). Actually at the moment I'd rather a user not be able to change the schedule. If the user doesn't customize it, then we shouldn't have to persist it.

If I'm reading your response correctly, then currently a user cannot change the schedule. That's perfect.

Quote:
Quote:
In the end, it would be nice if we could lose the TedDailyShow as well, such that only the class of the schedule determines the episodes we are looking for (Daily episodes/Season Episodes/Sequential episodes). But we kept the difference because the way of parsing is different. , can you explain why that is? I think it had something to do with the fact that you can set a maximum number of episodes for a daily show, but you can't for a normal season/episode show.

The DailySerie indeed only downloads the latest x released episoded. This is done so ted doesn't download 30 episodes after you've been on vacation. Also you are most of the time only interested in the latest episodes.


Very good to know. I'll keep this design decision in mind with any refactoring of that code.

Thanks Jofo.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 26, 2009 10:22 pm 
Offline
Lead Developer
User avatar

Joined: Mon Jan 16, 2006 5:46 pm
Posts: 904
Location: Netherlands
KenMacD wrote:
Sorry Jofo, I think I'm being confusing. I meant could we look up the information each time ted is started. Instead of persisting it to disk between restarts. I'm trying to figure out the minimum set of 'user data' that we need to persist between restarts of the program.

Note that one thing we always tried to do was to not overload other services. So at this point we load the schedule one time a week and that's it (unless you press the update button). We could do this more often but we're not sure if these services would like that :)

Quote:
If I'm reading your response correctly, then currently a user cannot change the schedule. That's perfect.

That's correct, at one point in time they could make there own schedule (well, at a release day or put ted on hold till a certain date) but we removed that feature as we think it's obsolete. Apparently some people don't like that.

Quote:
Thanks Jofo.

Thank you :)I think your diagram nicely shows what is currently wrong. You even didn't draw all the lines coming from the TedDailySerie class :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group