Re: Model Theory 101 - Video Sharing App

2009-11-13 Thread Preston Holmes


On Aug 26, 4:17 pm, thornomad  wrote:

>
> Caveats: I would like to keep the original "synced" data in its own
> field and the "approved" data (as edited) in separate field.  I
> imagine that the data first gets brought into the "edit" field, admin
> may make changes and save, but the "originating" data will remain
> separate and continue to be updated (synced).

Create a copy of the data in a new record - don't duplicate the fields

Have a field on the model that designated whether its original or
edited

have a self relation based on URL that links the synced and edited
versions

>
> This means I need at least
>
> I am stuck, though, on the most appropriate/logical approach to this
> app.  Some approaches I've considered.
>
> [1] My first thought is to create base model "Video" (with the main
> fields) and then create child models like YoutubeVideo and VimeoVideo
> and BlipVideo ... when the user submits a url, would do a regex on it
> in the view, and send it through the appropriate child class.  I could
> then grab the base Video model in my views (not having to distinguish
> the type of video) and use a "leaf" technique 
> (eg,http://www.djangosnippets.org/snippets/1031/) to run the child's
> "sync" or "update" command.  CONS: seems tacky and not easy to build
> on.  The leaf technique isn't working when I override the save()
> function in leaf models.
>
> [2] Perhaps create only a single model and then create separate
> classes/functions to handle the the syncing of data based on the
> URLField data ... so, perhaps when Video.update() is called, it would
> run the logic then to see what kind of url it has, and how to update
> it.  CONS: I thought maybe I could just create a ForeignKey field to a
> non-model group of classes with common functions (update, sync,
> etc) ... but I am not sure how, or if, I can do that.

You don't need to have your syncing code be in django models - you can
just write a python module that given a URL, will return a dictionary
of data representing the common fields you are interested in.  You
model would just use that.  There is probably an undocumented dict
like behavior on models that would allow you to update() the model
given a dict - but I'm just speculating.

>
> [3] Outsourcing.
>
> Hope this makes sense and folks have some feedback about how they
> might approach this.  I would like this to be easily expandable -- for
> example, add YouTube and Vimeo support to start, and easily add other
> sites without having to "hack" it.

What I'm proposing is you have one model, it calls one entry point in
a 'non-django' set of python code.  This code either returns a valid
dictionary, or raises some exception like "URL not handled"  You can
add to that python code as much as you like as you go without having
to change the model or django code.

-Preston

>
> I know this is a huge question, but am interested in your "Design
> Approach" thoughts ...
>
> Thanks,
> Damon

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=.




Re: Model Theory 101 - Video Sharing App

2009-11-12 Thread Fred Chevitarese
Hello ...
I've made one app as you like...

http://code.google.com/p/django-youtube-syncronizer/

;)

http://chevitarese.wordpress.com
Fred Chevitarese - GNU/Linux


2009/8/28 thornomad 

>
> Hi thanks for the response - I had looked at oembed, but it didn't
> seem like it would grab the title, description, play count, etc ...
> which was the information I was going for.  There is also a markdown
> plugin, that seems to work similiar.  If I went the route of just
> posting video (which I may, if I get tired of working on the complex)
> this would work great.  I'm also looked at django-syncr, which is
> similiar to what I am aiming for ...
>
> On Aug 27, 10:08 am, Bill Freeman  wrote:
> > Look at django-oembed.  A CharField will serve for every (supported)
> > provider.
> >
> > On Wed, Aug 26, 2009 at 8:17 PM, thornomad  wrote:
> >
> > > Hi - need some suggestions.
> >
> > > I am trying to put together an app that allows users to submit links
> > > to videos at popular video sharing sites (e.g., youtube, vimeo, etc)
> > > -- the links get submitted, data about the video (title, description,
> > > play count, etc) is collected from the respective site and populates
> > > model fields, and the video entry is queued for review.
> >
> > > Caveats: I would like to keep the original "synced" data in its own
> > > field and the "approved" data (as edited) in separate field.  I
> > > imagine that the data first gets brought into the "edit" field, admin
> > > may make changes and save, but the "originating" data will remain
> > > separate and continue to be updated (synced).
> >
> > > This means I need at least
> >
> > > I am stuck, though, on the most appropriate/logical approach to this
> > > app.  Some approaches I've considered.
> >
> > > [1] My first thought is to create base model "Video" (with the main
> > > fields) and then create child models like YoutubeVideo and VimeoVideo
> > > and BlipVideo ... when the user submits a url, would do a regex on it
> > > in the view, and send it through the appropriate child class.  I could
> > > then grab the base Video model in my views (not having to distinguish
> > > the type of video) and use a "leaf" technique (eg,
> > >http://www.djangosnippets.org/snippets/1031/) to run the child's
> > > "sync" or "update" command.  CONS: seems tacky and not easy to build
> > > on.  The leaf technique isn't working when I override the save()
> > > function in leaf models.
> >
> > > [2] Perhaps create only a single model and then create separate
> > > classes/functions to handle the the syncing of data based on the
> > > URLField data ... so, perhaps when Video.update() is called, it would
> > > run the logic then to see what kind of url it has, and how to update
> > > it.  CONS: I thought maybe I could just create a ForeignKey field to a
> > > non-model group of classes with common functions (update, sync,
> > > etc) ... but I am not sure how, or if, I can do that.
> >
> > > [3] Outsourcing.
> >
> > > Hope this makes sense and folks have some feedback about how they
> > > might approach this.  I would like this to be easily expandable -- for
> > > example, add YouTube and Vimeo support to start, and easily add other
> > > sites without having to "hack" it.
> >
> > > I know this is a huge question, but am interested in your "Design
> > > Approach" thoughts ...
> >
> > > Thanks,
> > > Damon
> --~--~-~--~~~---~--~~
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en
> -~--~~~~--~~--~--~---
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=.




Re: Model Theory 101 - Video Sharing App

2009-08-28 Thread thornomad

Hi thanks for the response - I had looked at oembed, but it didn't
seem like it would grab the title, description, play count, etc ...
which was the information I was going for.  There is also a markdown
plugin, that seems to work similiar.  If I went the route of just
posting video (which I may, if I get tired of working on the complex)
this would work great.  I'm also looked at django-syncr, which is
similiar to what I am aiming for ...

On Aug 27, 10:08 am, Bill Freeman  wrote:
> Look at django-oembed.  A CharField will serve for every (supported)
> provider.
>
> On Wed, Aug 26, 2009 at 8:17 PM, thornomad  wrote:
>
> > Hi - need some suggestions.
>
> > I am trying to put together an app that allows users to submit links
> > to videos at popular video sharing sites (e.g., youtube, vimeo, etc)
> > -- the links get submitted, data about the video (title, description,
> > play count, etc) is collected from the respective site and populates
> > model fields, and the video entry is queued for review.
>
> > Caveats: I would like to keep the original "synced" data in its own
> > field and the "approved" data (as edited) in separate field.  I
> > imagine that the data first gets brought into the "edit" field, admin
> > may make changes and save, but the "originating" data will remain
> > separate and continue to be updated (synced).
>
> > This means I need at least
>
> > I am stuck, though, on the most appropriate/logical approach to this
> > app.  Some approaches I've considered.
>
> > [1] My first thought is to create base model "Video" (with the main
> > fields) and then create child models like YoutubeVideo and VimeoVideo
> > and BlipVideo ... when the user submits a url, would do a regex on it
> > in the view, and send it through the appropriate child class.  I could
> > then grab the base Video model in my views (not having to distinguish
> > the type of video) and use a "leaf" technique (eg,
> >http://www.djangosnippets.org/snippets/1031/) to run the child's
> > "sync" or "update" command.  CONS: seems tacky and not easy to build
> > on.  The leaf technique isn't working when I override the save()
> > function in leaf models.
>
> > [2] Perhaps create only a single model and then create separate
> > classes/functions to handle the the syncing of data based on the
> > URLField data ... so, perhaps when Video.update() is called, it would
> > run the logic then to see what kind of url it has, and how to update
> > it.  CONS: I thought maybe I could just create a ForeignKey field to a
> > non-model group of classes with common functions (update, sync,
> > etc) ... but I am not sure how, or if, I can do that.
>
> > [3] Outsourcing.
>
> > Hope this makes sense and folks have some feedback about how they
> > might approach this.  I would like this to be easily expandable -- for
> > example, add YouTube and Vimeo support to start, and easily add other
> > sites without having to "hack" it.
>
> > I know this is a huge question, but am interested in your "Design
> > Approach" thoughts ...
>
> > Thanks,
> > Damon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Model Theory 101 - Video Sharing App

2009-08-27 Thread Bill Freeman
Look at django-oembed.  A CharField will serve for every (supported)
provider.

On Wed, Aug 26, 2009 at 8:17 PM, thornomad  wrote:

>
> Hi - need some suggestions.
>
> I am trying to put together an app that allows users to submit links
> to videos at popular video sharing sites (e.g., youtube, vimeo, etc)
> -- the links get submitted, data about the video (title, description,
> play count, etc) is collected from the respective site and populates
> model fields, and the video entry is queued for review.
>
> Caveats: I would like to keep the original "synced" data in its own
> field and the "approved" data (as edited) in separate field.  I
> imagine that the data first gets brought into the "edit" field, admin
> may make changes and save, but the "originating" data will remain
> separate and continue to be updated (synced).
>
> This means I need at least
>
> I am stuck, though, on the most appropriate/logical approach to this
> app.  Some approaches I've considered.
>
> [1] My first thought is to create base model "Video" (with the main
> fields) and then create child models like YoutubeVideo and VimeoVideo
> and BlipVideo ... when the user submits a url, would do a regex on it
> in the view, and send it through the appropriate child class.  I could
> then grab the base Video model in my views (not having to distinguish
> the type of video) and use a "leaf" technique (eg,
> http://www.djangosnippets.org/snippets/1031/) to run the child's
> "sync" or "update" command.  CONS: seems tacky and not easy to build
> on.  The leaf technique isn't working when I override the save()
> function in leaf models.
>
> [2] Perhaps create only a single model and then create separate
> classes/functions to handle the the syncing of data based on the
> URLField data ... so, perhaps when Video.update() is called, it would
> run the logic then to see what kind of url it has, and how to update
> it.  CONS: I thought maybe I could just create a ForeignKey field to a
> non-model group of classes with common functions (update, sync,
> etc) ... but I am not sure how, or if, I can do that.
>
> [3] Outsourcing.
>
> Hope this makes sense and folks have some feedback about how they
> might approach this.  I would like this to be easily expandable -- for
> example, add YouTube and Vimeo support to start, and easily add other
> sites without having to "hack" it.
>
> I know this is a huge question, but am interested in your "Design
> Approach" thoughts ...
>
> Thanks,
> Damon
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Model Theory 101 - Video Sharing App

2009-08-26 Thread thornomad

Hi - need some suggestions.

I am trying to put together an app that allows users to submit links
to videos at popular video sharing sites (e.g., youtube, vimeo, etc)
-- the links get submitted, data about the video (title, description,
play count, etc) is collected from the respective site and populates
model fields, and the video entry is queued for review.

Caveats: I would like to keep the original "synced" data in its own
field and the "approved" data (as edited) in separate field.  I
imagine that the data first gets brought into the "edit" field, admin
may make changes and save, but the "originating" data will remain
separate and continue to be updated (synced).

This means I need at least

I am stuck, though, on the most appropriate/logical approach to this
app.  Some approaches I've considered.

[1] My first thought is to create base model "Video" (with the main
fields) and then create child models like YoutubeVideo and VimeoVideo
and BlipVideo ... when the user submits a url, would do a regex on it
in the view, and send it through the appropriate child class.  I could
then grab the base Video model in my views (not having to distinguish
the type of video) and use a "leaf" technique (eg,
http://www.djangosnippets.org/snippets/1031/) to run the child's
"sync" or "update" command.  CONS: seems tacky and not easy to build
on.  The leaf technique isn't working when I override the save()
function in leaf models.

[2] Perhaps create only a single model and then create separate
classes/functions to handle the the syncing of data based on the
URLField data ... so, perhaps when Video.update() is called, it would
run the logic then to see what kind of url it has, and how to update
it.  CONS: I thought maybe I could just create a ForeignKey field to a
non-model group of classes with common functions (update, sync,
etc) ... but I am not sure how, or if, I can do that.

[3] Outsourcing.

Hope this makes sense and folks have some feedback about how they
might approach this.  I would like this to be easily expandable -- for
example, add YouTube and Vimeo support to start, and easily add other
sites without having to "hack" it.

I know this is a huge question, but am interested in your "Design
Approach" thoughts ...

Thanks,
Damon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---