I have been using an app called django-easy-friends in my application.
Now problem i want to make some changes in the app installed. I want to make entries in a different table each time a new friend is added.
Now my question is, is it wise to change the code in installed apps? If not how else to customise the apps to be installed?
I don't like to modify code in third party libraries. If you find a bug, you rather fork the library, fix it, make a pull request and update it into your INSTALLED_APPS.
If you want to do some modifications to get different behavior, I think is wiser to subclass the class you want to modify, encapsulate it, monkey patch it, or whatever object oriented methodology you find suitable for the modification you want to make.
The problems with modifying code in third party libraries come to light when you want to update the third party library. You'll get all sort of errors when you do it. Because your changes would've pass unknown to the library makers and if for some reason you forget what the changes were, your app will become a real mess.
IMHO, you should not modify a third party library. Instead, proceed as recommended above, report a bug, subclass their classes, etc, but don't modify it!
Hope this helps!
I think you should be fine, as long as you stay away from editing your models, all you are going to do is change 'the way your app works'. If you do edit your models you may have to remove the database and re-sync it.
Related
Unfortunately for me, the "pinax" application for Django does not seem to have stayed up with the times – in one specific way: the shorttimesince template-tag still refers to the tzinfo object which has been deprecated.
The message is this:
django.template.library.InvalidTemplateLibrary: Invalid template library specified. ImportError raised when trying to load 'pinax.templatetags.templatetags.shorttimesince_tag': No module named 'django.utils.tzinfo'
In my project, I have a overrides/pinax/templatetags directory which contains both __init__.py and shorttimesince_tag.py which contains the updated code. But it does not seem to be referenced. (And I think that, after studying this problem, I see why not.)
I need to be able to override a templatetag that is defined in a third-party application. Does Django actually know where a templatetag is defined? Please guide me to a swift and appropriate solution.
Pardon me, community ... I am very befuddled by all of this, and writing this while "still befuddled."
Sorry to have left this question sitting around unanswered for so long ... here is what I finally (and, successfully) decided to do.
I realized that the "pinax" library application appears to no longer be maintained, even though there is really (so far ...) only this one slight problem with it. So, I moved the package into my own project and removed it from the library (and from requirements.txt ...). After first branching and git-committing the change which moved it, I then made the very-trivial change to fix the problem with shorttimesince_tag.py and committed that, then merged my branch into the mainline. From now on, "pinax" has officially become "part of my project."
"It's really too bad" when really-great packages like "pinax" come to be abandoned, but every now and again it happens, I suppose . . . we are all volunteers.
I'm developing an OpenCart shop using OC 2.1 and I'm struggling to understand what is the best solution for creating custom changes on controller level.
Here's a simplified example to show you what I'm wondering about:
I'd like to modify my header. The graphic design I'm implementing uses different writing for My account link depending on if the user is already logged in or not. This is of course a very simple thing to change, so here are my ideas:
I could just edit my new template's header.tpl file to use:
<?php echo $logged ? $text_account_signed : $text_account; ?>
That requires a change in a language file and that file is outside of the template folder. I'll leave the language issue out for this example to make it less complicated.
But to create a solution that is more MVC I should make that change in the catalog/controller/header.php file, shouldn't I? Unfortunately that file is outside of the template folder so in case of an update, the change will be lost or would require fixing by hand.
I could however create an extension with an extension.ocmod.xml file that would make a change in the controller header.php file and it would be safer (not sure if 100% sage though) for future updates. But the amount of extensions and/or the complexity of creating them would greatly impact my project time, I suppose. And that makes me tempted to just edit the source code of OpenCart and make my future self worry about it later. But I care about this guy and I'm sure he'd hate me for that at some point.
So, my real question is: Is there a way of creating OpenCart modifications on controller level that would not break future updates?
Regarding modifying existing Controller, Models, Languages yes you either need to use vQmod or OCMOD and for template yes you can create your own template according to need. there is no other option.
If you are using vQmod or OCMOD then you don't have to worry about updates because there is less chances of issue (issue may occur only in major updates).
For vQmod there are other easy tools like vQgen and vQmanager available
For Opencart Overall general info
From the documentation: "Django’s comment framework has been deprecated and is no longer supported. Most users will be better served with a custom solution, or a hosted product like Disqus. The code formerly known as django.contrib.comments is still available in an external repository."
Is the move to django-contrib-comments only a fallback for existing projects that use django.contrib.comments? Should I use django-contrib-comments in new projects and why (not)?
I have been developing comments for our site using django.contrib.comments and found it to be quite a simple module and nothing else. If you are building a "just" commenting app to engage people, disqus might be a nice option. For instance, if you are building something like what stackoverflow is doing, you need to do by yourself.
For that, you can pretty well use django.contrib.comments and built your rest of the code on the top of it. I have been doing this and the following are points I would like to note
Very good chance that you are going to write all Views again for Ajax support or any other custom support
The app does not authenticate users. So, you might need to tweak this too
Add some special fields in comments, remove some provided
You might want to provide users to delete comments.. The built-in delete is just a flag where its marked "deleted" but not deleted exactly..
Regarding administration of commments, there might be lot you are going to improve.
It goes on, when you start doing it, you continue to tweak almost everything and make fit for your site. Probably if your tweaks seems to look too huge, I guess, start from scratch or take only parts of that django.contrib.comments where ever needed..
The Google Groups Django developers has the proposal:
"... if you don't really care much about how comments work but just want something easy, then Disqus (and its competitors) are easier to use and have much better features (spam prevents, moderation, etc.). If you want something complex and specific, on the other hand, you're better off writing something from scratch."
And the django-contrib-comments (the new home) is intended as a boneyard.
I would like to install a djangopypi server for our local development and deployment. However, I'm slightly confused about its installation docs. Apparently, it's assumed that djangopypi is installed inside a bigger project as an app, which is at least debatable from my point of view. I would like my local PyPI instance to run independently of anything else, as a "normal" web service.
And this is where I'm lost. It seems I need some kind of a minimal Django project to wrap djangopypi, which seems a bit overkill for me. Is there a more elegant way to install it in standalone mode?
That's exactly what you need. djangopypi is just an app. Like any Django app, it needs to know stuff like how to connect to your database, etc. That information comes from the project. It doesn't provide this for you because there's no way it could possible know what the best settings are for your particular environment; that's your responsibility.
So, no, it's not "overkill". It's the bare minimum required for functionality, and it's just the way things are. Create a simple project, change all the relevant items in settings.py, nclude djangopypi's urls.py in yours, and you're done. Is is really that hard?
I am new to Joomla, started learning it just a day ago and didn't manage to find an answer to my question in the docs (which suck real bad compared to Drupal).
So what I want to do is override the whole module in a template. The documentation only suggests I can override the markup of a module by placing corresponding files in the html folder, but I have to make some corrections to the actual logic. Is copying the module, changing and then installing it as a separate entity the only way to go? I mean it makes sense that "template" folder is for "views" but with the kind of application I have to develop it is gonna be annoying...
Yeah, you can only override views.
If you want to override logic, you have 2 options:
Change the actual logic in-place, which leads to problems on updating etc
Duplicate the module and change the logic, as you suggested
One other way to consider is to replicate or fix the logic in the template. While this is not a very slick way of doing it, it is faster, especially than duplicating a whole component.
Note that you can also add your own libraries to the Joomla libraries folder to centralize your own code.
Further, if you manage your code with (for example) svn, you should not have any problems on upgrades with creating new views that may include their own logic.