Re: Application decoupling - project architecture question

[kmike]

I wrote a simple app that may be useful for avatar management:
http://bitbucket.org/kmike/django-generic-images/wiki/Home
It's similar to django-tagging in aspect that images can be attached
to any model using generic relations and then fetched in a few sql
queries.
Avatar-uploading view example can be found in another app
(upload_main_image view):
http://bitbucket.org/kmike/django-photo-albums/wiki/Home
However it is easy to write your own view or extend your
editProfileForm.

On 8 авг, 00:29, Andrin Riiet  wrote:
> Thanks for your replies,
>
> I read the book and indeed I found what I needed.
>
> For anyone who happens to read this and is wondering the same thing,
> here's how it goes:
>
> You extend the base form class (eg editProfileForm), add the avatar
> field to it and you use the new form class by passing it as parameter
> to the view function that displays it ( the view functions should be
> designed to accept such parameters). You pass the correct values for
> the parameters in the urlconf.
> And you can decouple the form handling code by putting it all in the
> form.save() method (as opposed to the view function) - that way when
> you extend the base form you can extend the form handling code as
> well.
>
> Thanks everyone,
>
> Andrin
>
> On Aug 7, 5:08 pm, grElement  wrote:
>
>
>
> > There is a good tutorial on this in Practical Django Projects
>
> >http://www.amazon.com/Practical-Django-Projects-Pratical/dp/1590599969
>
> > It goes a bit more into theory that I found helpful.
>
> > On Aug 6, 8:07 am, Andrin Riiet  wrote:
>
> > > Hi, I'd like to shed some light on the "the right way" to make
> > > applications in django by an example and a few questions.
>
> > > Let's say that I have a 'users' application (acting as "user profiles"
> > > on the built-in user authentication system) and I want to add an
> > > avatar image feature to it.
> > > I'd like to have the avatars in a separate application in case my next
> > > project doesn't require them (this is the right way to do things i
> > > guess?)
>
> > > Now I want to have the user to be able to upload an avatar image in
> > > the "edit profile" form. The default edit-profile form is defined in
> > > my 'users' application of course. I'd like to "add" the avatar feature
> > > (form field) to it somehow. - This is part 1 of the problem
>
> > > The 2nd part is in the form handling: the request object is going to
> > > contain form field values from 2 different applications, none of which
> > > should be responsible for processing the other's forms.
>
> > > Obviously the 'avatars' application is dependent on the 'users'
> > > application but the 'users' application should be oblivious of the
> > > avatars...
>
> > > How would I go about doing that?
>
> > > Andrin
--~--~-~--~~~---~--~~
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: Application decoupling - project architecture question

[kmike]

I wrote a simple app that may be useful for avatar management:
http://bitbucket.org/kmike/django-generic-images/wiki/Home

It's similar to django-tagging in aspect that images can be attached
to any model using generic relations and then fetched in a few sql
queries.

Avatar-uploading view example can be found in another app
(upload_main_image view):
http://bitbucket.org/kmike/django-photo-albums/wiki/Home

However it is easy to write your own view or combine it with profile
editing view.

On 8 авг, 00:29, Andrin Riiet  wrote:
> Thanks for your replies,
>
> I read the book and indeed I found what I needed.
>
> For anyone who happens to read this and is wondering the same thing,
> here's how it goes:
>
> You extend the base form class (eg editProfileForm), add the avatar
> field to it and you use the new form class by passing it as parameter
> to the view function that displays it ( the view functions should be
> designed to accept such parameters). You pass the correct values for
> the parameters in the urlconf.
> And you can decouple the form handling code by putting it all in the
> form.save() method (as opposed to the view function) - that way when
> you extend the base form you can extend the form handling code as
> well.
>
> Thanks everyone,
>
> Andrin
>
> On Aug 7, 5:08 pm, grElement  wrote:
>
>
>
> > There is a good tutorial on this in Practical Django Projects
>
> >http://www.amazon.com/Practical-Django-Projects-Pratical/dp/1590599969
>
> > It goes a bit more into theory that I found helpful.
>
> > On Aug 6, 8:07 am, Andrin Riiet  wrote:
>
> > > Hi, I'd like to shed some light on the "the right way" to make
> > > applications in django by an example and a few questions.
>
> > > Let's say that I have a 'users' application (acting as "user profiles"
> > > on the built-in user authentication system) and I want to add an
> > > avatar image feature to it.
> > > I'd like to have the avatars in a separate application in case my next
> > > project doesn't require them (this is the right way to do things i
> > > guess?)
>
> > > Now I want to have the user to be able to upload an avatar image in
> > > the "edit profile" form. The default edit-profile form is defined in
> > > my 'users' application of course. I'd like to "add" the avatar feature
> > > (form field) to it somehow. - This is part 1 of the problem
>
> > > The 2nd part is in the form handling: the request object is going to
> > > contain form field values from 2 different applications, none of which
> > > should be responsible for processing the other's forms.
>
> > > Obviously the 'avatars' application is dependent on the 'users'
> > > application but the 'users' application should be oblivious of the
> > > avatars...
>
> > > How would I go about doing that?
>
> > > Andrin
--~--~-~--~~~---~--~~
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: Application decoupling - project architecture question

[Andrin Riiet]

Thanks for your replies,

I read the book and indeed I found what I needed.

For anyone who happens to read this and is wondering the same thing,
here's how it goes:

You extend the base form class (eg editProfileForm), add the avatar
field to it and you use the new form class by passing it as parameter
to the view function that displays it ( the view functions should be
designed to accept such parameters). You pass the correct values for
the parameters in the urlconf.
And you can decouple the form handling code by putting it all in the
form.save() method (as opposed to the view function) - that way when
you extend the base form you can extend the form handling code as
well.

Thanks everyone,

Andrin

On Aug 7, 5:08 pm, grElement  wrote:
> There is a good tutorial on this in Practical Django Projects
>
> http://www.amazon.com/Practical-Django-Projects-Pratical/dp/1590599969
>
> It goes a bit more into theory that I found helpful.
>
> On Aug 6, 8:07 am, Andrin Riiet  wrote:
>
> > Hi, I'd like to shed some light on the "the right way" to make
> > applications in django by an example and a few questions.
>
> > Let's say that I have a 'users' application (acting as "user profiles"
> > on the built-in user authentication system) and I want to add an
> > avatar image feature to it.
> > I'd like to have the avatars in a separate application in case my next
> > project doesn't require them (this is the right way to do things i
> > guess?)
>
> > Now I want to have the user to be able to upload an avatar image in
> > the "edit profile" form. The default edit-profile form is defined in
> > my 'users' application of course. I'd like to "add" the avatar feature
> > (form field) to it somehow. - This is part 1 of the problem
>
> > The 2nd part is in the form handling: the request object is going to
> > contain form field values from 2 different applications, none of which
> > should be responsible for processing the other's forms.
>
> > Obviously the 'avatars' application is dependent on the 'users'
> > application but the 'users' application should be oblivious of the
> > avatars...
>
> > How would I go about doing that?
>
> > Andrin
--~--~-~--~~~---~--~~
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: Application decoupling - project architecture question

[grElement]

There is a good tutorial on this in Practical Django Projects

http://www.amazon.com/Practical-Django-Projects-Pratical/dp/1590599969

It goes a bit more into theory that I found helpful.





On Aug 6, 8:07 am, Andrin Riiet  wrote:
> Hi, I'd like to shed some light on the "the right way" to make
> applications in django by an example and a few questions.
>
> Let's say that I have a 'users' application (acting as "user profiles"
> on the built-in user authentication system) and I want to add an
> avatar image feature to it.
> I'd like to have the avatars in a separate application in case my next
> project doesn't require them (this is the right way to do things i
> guess?)
>
> Now I want to have the user to be able to upload an avatar image in
> the "edit profile" form. The default edit-profile form is defined in
> my 'users' application of course. I'd like to "add" the avatar feature
> (form field) to it somehow. - This is part 1 of the problem
>
> The 2nd part is in the form handling: the request object is going to
> contain form field values from 2 different applications, none of which
> should be responsible for processing the other's forms.
>
> Obviously the 'avatars' application is dependent on the 'users'
> application but the 'users' application should be oblivious of the
> avatars...
>
> How would I go about doing that?
>
> Andrin
--~--~-~--~~~---~--~~
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: Application decoupling - project architecture question

[Paulo Almeida]

I'm far from being an expert, but maybe you can look at the django-tagging
code for inspiration:

http://code.google.com/p/django-tagging/

What they do is to provide a TagField in the tagging application, and then
you can use that field in the form of the application using tags. You can
probably do something similar with an AvatarField.

- Paulo

On Thu, Aug 6, 2009 at 4:07 PM, Andrin Riiet  wrote:

>
> Hi, I'd like to shed some light on the "the right way" to make
> applications in django by an example and a few questions.
>
> Let's say that I have a 'users' application (acting as "user profiles"
> on the built-in user authentication system) and I want to add an
> avatar image feature to it.
> I'd like to have the avatars in a separate application in case my next
> project doesn't require them (this is the right way to do things i
> guess?)
>
> Now I want to have the user to be able to upload an avatar image in
> the "edit profile" form. The default edit-profile form is defined in
> my 'users' application of course. I'd like to "add" the avatar feature
> (form field) to it somehow. - This is part 1 of the problem
>
> The 2nd part is in the form handling: the request object is going to
> contain form field values from 2 different applications, none of which
> should be responsible for processing the other's forms.
>
> Obviously the 'avatars' application is dependent on the 'users'
> application but the 'users' application should be oblivious of the
> avatars...
>
> How would I go about doing that?
>
> Andrin
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Application decoupling - project architecture question

[Andrin Riiet]

Hi, I'd like to shed some light on the "the right way" to make
applications in django by an example and a few questions.

Let's say that I have a 'users' application (acting as "user profiles"
on the built-in user authentication system) and I want to add an
avatar image feature to it.
I'd like to have the avatars in a separate application in case my next
project doesn't require them (this is the right way to do things i
guess?)

Now I want to have the user to be able to upload an avatar image in
the "edit profile" form. The default edit-profile form is defined in
my 'users' application of course. I'd like to "add" the avatar feature
(form field) to it somehow. - This is part 1 of the problem

The 2nd part is in the form handling: the request object is going to
contain form field values from 2 different applications, none of which
should be responsible for processing the other's forms.

Obviously the 'avatars' application is dependent on the 'users'
application but the 'users' application should be oblivious of the
avatars...

How would I go about doing that?

Andrin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---