Hi, Thanks the for the reply. > The reason you must place your templates out from your app code is > because if you don't do that, anyone could access to the code via > browser. Just writing the path of your files, and they have the code. > It could be a security issue.
Umm, if it doesn't match a url.py re, I don't see how. Is this an issue when running under Apache? I'm currently just using the dev server while learning. > Finally, not sure about unit testing... My past experience says test each layer. But, I suppose I could probably just test the urls.py, view.py and templates with unit tests using. the Client object. This would indirectly test the business objects and model objects get tested. > Greets, > > On 20 mayo, 03:39, ristretto <[EMAIL PROTECTED]> wrote: >> Hello, I'm going down the same adoption path. Coming over from Java >> skipping and happy. >> >> I'm fighting (and loosing) the urge to create a manager.py that will >> basically hold business logic and interface with the models. >> Additionally, I have read the unit testing documentation, and I want >> to make sure I'm following a good practice to get complete test >> coverage. >> Finally, I don't see any reason why I shouldn't put the templates in >> the app directory. But, I also don't see that recommendations to do >> so. >> So, I'm a bit unsure. >> >> I'm considering this setup. Would anyone care to correct me, if I >> have something not quite right? >> >> myproject/ >> __init__ >> urls.py >> settings.py >> manage.py >> myapp/ >> models.py >> model_tests.py - test directly, simulating code that would go in >> managers.py >> managers.py - in here are classes methods that the view defs >> call >> managers_test.py - test directly, simulating code that would go in >> views.py. >> views.py >> view_test.py - tests in here use Client and therefore test urls.py >> and templates too. Considering having 1 default tests per def in >> views.py that would be a sanity/integration test. Then, any other >> specific tests that doesn't test functionallity already tested in >> managers_test.py >> templates/ >> >> I like this because the managers.py code organizes the business logic >> away from the web controller layer, let's me doing specific testing on >> it, and also decoupling it easily for hook up with GTK or QT or >> something. But, it doesn't add another layer of complexity that might >> not really be necessary. >> >> I'm truly sorry if I have asked stupid questions. I will not be >> offended if you ignore me. I'm going to keep reading, and I have >> lot's of books on order. I'll sort it all out at some point. >> >> cheers!!! >> >> On Apr 5, 1:51 am, Doug Van Horn <[EMAIL PROTECTED]> wrote: >> >> > I haven't found any 'bestpractices' for Python other than PEP-8 or >> > the olderhttp://www.python.org/doc/essays/styleguide.html. >> >> > Django kind of pre-defines a generalbestpractice of project layout, >> > but anything outside of models, tests & fixtures, templatetags, et. >> > al. is up to you (views and settings are not 'required' to be where >> > they are). >> >> > Anyway, it's kind of discomforting at first, coming from J2EE-land >> > where everything is laid out for you in the core J2EE Patterns book. >> > "Here are you DAOs, there are your Business Delegates, and over >> > there's where you keep your transformers and your DTOs"... >> >> > In Python/Django, you have to think a little bit more about how you >> > want to lay things out and where they belong /in your project/. So >> > there's not that uniform inter-corporate architecture consistency you >> > find (or at least I found) when bouncing around in contract gigs for >> > larger corps. >> >> > If it helps, my progression went first from breaking everything up >> > into small chunks in lots of files and apps (a la one class per file >> > Java), to now having much bigger modules holding lots of related >> > concerns (classes and functions). I think that it's more common in >> > Python to do this, and it's a lot easier to remember where stuff is. >> >> > for what that's worth... >> >> > On Apr 3, 11:52 am, bcurtu <[EMAIL PROTECTED]> wrote: >> >> > > Thanks Doug, >> >> > > Well, yes, I think it's pretty easy to switch to this philosophy, even >> > > it's hard to come back to java again! >> >> > > I will follow my model 1, because it's generic code and it could be >> > > reusable. >> >> > > What about a goodpracticesreference guide... Any suggestion? >> >> > > On Apr 3, 4:54 pm, Doug Van Horn <[EMAIL PROTECTED]> wrote: >> >> > > > On Apr 3, 9:19 am, bcurtu <[EMAIL PROTECTED]> wrote: >> >> > > > > Hi again, >> >> > > > > I come form j2ee world, this is my first project in Django and >> > > > > usually >> > > > > I feel a bit lost about general concepts. >> >> > > > > My project has bit too much business code, it's a kind of datamining >> > > > > tool. I have created a set of functions but I'm not sure where the >> > > > > "bestpractices" say I should place them... >> >> > > > > 1.- In the same folder as my app (package) is, in a different file: >> > > > > app1/ >> > > > > __init__.py >> > > > > models.py >> > > > > views.py >> > > > > datamining.py >> >> > > > > 2.- In the same models.py or views.py file?: >> > > > > app1/ >> > > > > __init__.py >> > > > > models.py >> > > > > views.py >> >> > > > > 3.- In a new app (app)? >> > > > > app2/ >> > > > > __init__.py >> > > > > datamining.py >> >> > > > > Thanks for your advice... and, do you know any goodpractices >> > > > > reference for django? >> >> > > > I came from the same world (J2EE, many years), FWIW. >> >> > > > I'd choose 1 or 2. In an e-commerce app I've been working on, I have >> > > > lots of Google, PayPal, and Authorize.net code that have their own >> > > > modules (google_checkout.py, etc.) that reside in the app1/ folder. >> > > > These functions are used by the views to check a user out. >> >> > > > I also have lots of 'business logic' code around Cart -> Order -> >> > > > Invoice transitions, but that code is in my models.py file, woven into >> > > > Managers and Models. Again, used by the views. >> >> > > > My rule of thumb is that if it's data related, it belongs in the >> > > > models.py file, if it's workflow/control related, it belongs in the >> > > > views.py file. Anything utilitiy-like (which kind of implies >> > > > potential reuse), it belongs in it's own module. >> >> > > > When you use the term datamining, it kind of tastes like Manager code >> > > > (cross record stuff). If you're doing more cross-model-cross-record >> > > > stuff, it's probably it's own module. >> >> > > > As a former J2EE guy, it took me a while to get past the need to >> > > > package everything in it's own space (1 class per file and all). I'm >> > > > much more comfortable with the module approach now. >> >> > > > doug. > > > -- Picante Solutions Limited e: [EMAIL PROTECTED] w: 06 757 9488 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
