Hi Aseem, > Is there some other layout?
Yes. The current version of Django uses the layout mentioned in the tutorial itself: https://docs.djangoproject.com/en/1.6/intro/tutorial01/ > The second part about relative imports. I have never understood how relative imports work. I mean the syntax. I have went through the PEP to understand it and did a lot of google searches but that is something that I never got the hang of. Is there any specific reason that I should be using them? Relative imports would continue to work even if your app or project name changes. They are also unambiguous as mentioned in the docs <https://docs.python.org/2/whatsnew/2.5.html#pep-328>. > Would you like to use an app that won't autocomplete? I think the confusion was caused by your flat-style project layout. There is a distinction between a Django project and an app. I was referring to adding too much functionality into a bookmarking *app*. It is perfectly fine in a project though. Cheers, Arun On Wednesday, 11 June 2014 00:03:30 UTC+5:30, Aseem Bansal wrote: > > I did not understand what you said regarding having a standard layout. I > mean I am already using the layout that was explained in the Django > tutorials. Keeping all my HTML in the template directory and all static > files in the static directory with namespacing with the app name which is > BookMarker. Is there some other layout? > > > I used CharField instead of URLField because there is a problem with > URLField. It is not allowing me to add local files as bookmarks which is > actually valid URL. I mean currently I have bookmarks in my browser like > file:///D:/Study/Docs/Python/python-3.4.0-docs-html/index.html > It is perfectly valid URL but URLField is marking it as invalid. So I used > CharField. > > The second part about relative imports. I have never understood how > relative imports work. I mean the syntax. I have went through the PEP to > understand it and did a lot of google searches but that is something that I > never got the hang of. Is there any specific reason that I should be using > them? > > The app's goal is for me to be able to us this app for storing and using > my bookmarks through the app instead of my webbrowser. The problem is that > I have lot of bookmarks. Both offline and online bookmarks which I am > currently maintaining in a multiple hierarchy of bookmark folders. It is > going messy. I need this app to be an application that I can use to add, > update, delete, view bookmarks by categories. Adding, deleting categories > and searching by categories is also necessary for me to switch to this app. > Otherwise there is no benefit. > > The reason I am using autocomplete is that I want searching for categories > easier. Same goes for already added bookmarks. Would you like to use an > app that won't autocomplete? Nobody will including myself. The reason for > opening a webbrowser is that I need to be able to use my bookmarks through > this app. I can serve the bookmarks as hyperlinks on which a simple click > can do the job of opening the webpage. But browser security does not allow > me to open locally stored bookmarks like the one I gave above to be opened > this way. When I came to know about this thing I had two choices - switch > to a GUI framework or find an acceptable workaround. As my server and > client or on the same machine and the security of browser do not apply to > my Python installation I chose to send the request of opening the bookmark > to server which will be able to open both offline and online bookmarks. > > I understand the need for documentation but I think as there is an > assumption of server and client on same machine for opening the bookmarks > no one will want to use it anyway. Bad jokes aside, I am learning Django, > Javscript/jQuery through this project I don't feel comfortable adding > another topic to learn side-by-side alongwith my job. My goal is to make an > app for personal use. If I add too much things to learn at the same time I > will lose the interest that keeps me going. I will consider making one the > proper way when I am more comfortable with these things and I have an idea > which is reusable. > > If there is anything else please let me know. I will try my best to > explain. > > > On Tuesday, June 10, 2014 6:48:59 PM UTC+5:30, trojactory wrote: >> >> Aseem, >> >> I had a quick look at your Django app and here are some of my >> observations: >> >> >> 1. Most Django apps have a standard layout with the app in a >> directory named after itself. See django-taggit >> >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Falex%2Fdjango-taggit&sa=D&sntz=1&usg=AFQjCNE_8owJgA8itHuBmLu9UwortstXOw> >> >> for instance. >> 2. You have made some unconventional choices which needs to be >> explained like using CharField instead of URLField, not using >> relative paths in imports etc. >> 3. An app must do one thing really well in order to be most reusable. >> I believe autocomplete and opening a web browser don't belong to a >> bookmarking app. >> 4. There needs to be more unit tests and documentation to increase >> confidence of other developers in using the app. >> >> Sorry, if I have misunderstood the objectives of your project, but these >> things stood out to me. >> >> Cheers, >> Arun >> >> >> On Saturday, 7 June 2014 15:37:52 UTC+5:30, Aseem Bansal wrote: >>> >>> I last asked for a review around two weeks back for my project. Is >>> anyone interested to give a second review for this project? >>> >>> https://github.com/anshbansal/Bookmarker >>> >>> The last thread was here >>> https://groups.google.com/forum/#!topic/django-users/ob4fXz3GF9w in >>> case someone wants to see that I actually respond to people's comments >>> instead of just wasting their time. >>> >>> From last time I have done these changes - >>> 1 Bookmark update as per categories is now working >>> 2 Used templates to make some things simpler to understand >>> 3 Refactoring of view.py to get reusable components >>> 4 Refactored jquery to make it cleaner so it is actually possible to >>> read it >>> 5 Added CDN of librarires and added backup in case no internet is present >>> >>> >>> My main concern currently is that this project is turning out to have a >>> lot more jQuery than Python/HTML. Am I designing this incorrectly? I >>> understand that as my requirements are mostly asynchronous so there is a >>> need for javascript but redundancy like hard-coding URLs for autocomplete >>> in javascript is bothering me. Also am I over-engineering the Javascript? >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d4aeee4b-f0ac-4f58-afc0-38b4914bf7be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
