Migrating to class-based views?

Issue #7 resolved
created an issue

This app actively uses function-based views. They have been deprecated and will be removed completely in 1.5.

So I suggest to start migration from function-based generics to class-based ones.

Anyway I'm going to refactor that part of this app on the near days because of my personal needs so if you really need that views, I can make a pull request when work will be done.

Comments (3)

  1. semente repo owner

    Please, send me a pull request! :-)

    I didn't have time to work in Diário properly in the last months but I'm planning to back working on it and I will give a look in all your needs and improvements. I'm not sure if I will support all your features but I want refactor some things to let Diário more flexible.

    If you want discuss my ideas for Diáro and work together on it please send me a message so we can start a thread. :-)

  2. H3n0xek reporter

    OK. So I have some ideas about flexibility of Diário.

    1. Abstract models #2 is a very great idea.
    2. Entry.author field directly relies on auth.User. As an alternative, it's possible to set something like AUTHOR_MODEL in the diario settings file and overwrite it, if neccessary, in project's settings. It is important because some developers inherit their own user models from User instead of using profiles.
    3. MARKUP_CHOICES might be retrieved from settings file.
    4. There could be more flexible showing control mechanism, instead of just is_draft field. For example, based on privileges level, subscribing on tags/categories or something another stuff. Of course this functionality won't be interesting for most diario users so that there should be a mechanism to conditional removing this field without app forking.
    5. update_draft_date signal handler should be optional, but turned on by default. This is because some bloggers prefer not to bump their posts after doing some UPDs.
  3. Log in to comment