--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Shawn: thanks
Just started watching the video and I'm noticing my complaints are not
unique.
Actually, a big part of the problem is reusing my own apps. Mostly
> Wow! I guess your definition of an app and expectation of re-usuability
> from an app written by someone else
> is fairly high!
since all of them provide models, and every use case either needs
changes to those.
That's interesting.
>
> We have built serveral news sites based on Django, and a lot of code gets
> rewritten everytime, because customer requirements are very different. We
> reuse 90% of code in every project, but 10% gets rewritten or gets writtenf
> fresh.
>
Do you adapt models across your apps?
Do you deal with (some kind of advanced) authorization that differs
over projects?
I'd like to know how.
Yeah I looked at Pinax too (because it is presented as a "reusable
> I know there's a number of apps out there including ones written by people
> like me, which are grossly unusable. I guess that's primarily because its
> written by developers for a specific work, and when they threw it back into
> the wild, they did not pay enought attention tomake it really re-usuable.
> However there are quite a few exceptions,
>
> I completely agree with your views that with the way you write code with {%
> url in templates, and decorators, reusing the code is a pain. I had to scrap
> a project based on Pinax for the same reason, and then rewrite a mini scoial
> framework, because pinax is not customizable beyond a point.
app") but I was a bit disappointed. (not so much in the app, as in how
it is an example of reusability).
Problem is "{% url %}" is presented as a Good Thing (DRY) while it
makes reuse in some ways harder
What's your alternative, i.e. how do you provide links that are
project independent?
> However my personal experience is that it's true for most platforms. There
> are always trade-offs and trade-ins when you use a platform.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
I'm no sure I'd go so far as to say your 'wrong' -- you've certainly
got some valid points in here -- but you're drawing a different set of
conclusions than I do.
You're looking at the world of Django apps that has evolved over 5
years, and is still evolving, and has an evolving world of best
practice, and appear to have concluded that reusable apps can't/don't
work.
I look a the same landscape and see that reusability demonstrably
*does* work -- but it could work a whole lot better. More importantly,
I've seen reusability get steadily better over time as the community
gets more experience building larger projects, and needing to reuse
more code.
Reusability has always been *possible* -- providing you build your
apps in the "right way". The catch is that not every app is built the
"right way"... and the understanding of the what constitutes the
"right way" changes with time. Even Django's contrib apps have been
victim of this. contrib.comments was built using the best
understanding of it's time, and landed in Django 1.0. By Django 1.1,
we had significantly improved our understanding of the importance of
having multiple instances of an application, and provided tools to
allow URLs to be namespaced and handled at a class level.
Does this mean that contrib.comments isn't reusable? Well, yes an no.
It *can* be reused. It has many desirable reusable features. It can
and has been used in many projects. But it isn't 'state of the art'.
And there is a of aspects of reusability that could be improved in
that app.
The secret is that someone needs to pitch in and make those
improvements. You think contrib.comments isn't reusable enough?
Propose a change! Make your case, write a patch, shepherd it through
the release process.
The same goes for any other reusable app in the community. If you find
an app that isn't as reusable as it should be, contribute a patch back
to the authors that adds flexibility in the direction you think it
needs it.
And if there's something that needs to be acknowledged at the core
level to improve support for reusability, we're all ears. Namespaced
URLs was a big step. Class based views will be another -- they've been
on the roadmap since 1.0, and based on progress so far, there is a
good possibility we might actually get them for 1.3.
At the end of the day, I can only see four possible reasons why an app
can't be made reusable:
a) fundamentally can't
b) can't justify the engineering cost to do it
c) can't work out how to do it, or
d) can't be bothered
I'm yet to see a genuine case of (a) -- every time I've seen (a), it's
really masked version of (b), (c) or (d).
(b) is a legitimate engineering management problem that can't be
ignored, so anything Django as a project can do to lower the cost
barrier is certainly a welcome suggestion.
(c) is an education problem; Admittedly, we haven't been as good at
this as we have in other areas. There are various unofficial resources
and books that discuss reusability, but there's nothing in Django's
formal documentation corpus on this significant problem. Pinax started
as an attempt to identify and codify some of the conventions that
would lead to better reusability in apps. However, that hasn't really
resulted in a concrete set of guidelines, more a set of best practices
best observed by inspection. I completely agree that this is something
we need to address; volunteers are welcome.
(d) is a motivation problem. Maybe it's driven by (b) and (c), but
ultimately, we can lead a horse to water, but we can't make it drink.
Yours,
Russ Magee %-)
I'm intrigued to know what these changes might be that they couldn't
be integrated in a reusable fashion.
I doubt even James Bennett would claim django-registration is perfect.
Every application can be improved, or made more flexible. I'm sure
there are points of customization that he either hasn't considered, or
hasn't got around to implementing. This is where you, as a third
party, can contribute back -- to engage with the builders of existing
django apps to make them more reusable.
There will also be occasions where django-registration simply isn't
the right solution. That doesn't mean reusable apps are a failure. It
just means that django-registration isn't the right reusable app for
your problem. The promise of reusability isn't that every part can
perform every task. Reusable apps only promise that if you built an
app carefully, you'll be able to reuse it in similar circumstances in
the future.
Lastly, I can't deny that reusability has it's price. Engineering an
application to be reusable takes more effort and planning than
building an application as a once-off. The aim is that if you take the
effort once to make your application reusable, the engineering payoff
will happen quickly -- hopefully on your second build. However, if you
have no intention of using a component a second time, then there isn't
a whole lot of reason to spend the effort making it reusable.
Yours,
Russ Magee %-)
Yours,
Russ Magee %-)
If a model isn't abstract but needs to be, then that speaks to
applications not being built to be as extensible as possible. Django
hasn't always had abstract models -- they were added just before 1.0
landed (IIRC).
Unfortunately, it's very difficult to migrate from a concrete model
back to an abstract model, so it's not easy to introduce an abstract
model into an existing app without breaking backwards compatibility.
There are also complications around handling foreign keys to abstract
models. This is an area where there is room for improvement; there
have been some very recent discussions on this very topic. Alex Gaynor
discussed some of the issues and approaches in his recent DjangoCon
presentation [1].
[1] http://djangocon.blip.tv/file/4108781/
> 2. How to tie in the models into the views? Long view parameter lists
> that are used from urls are ugly and repetitive. Moreover: it may not
> be possible to solve the entire problem this way (think admins, think
> forms).
I'm afraid I have no idea what you're talking about here. HTTP is a
stateless protocol. The only reliable way you have to pass around
state is the arguments in a URL (technically, the request, so you can
use cookies too). This is one of the core *features* of the HTTP
protocol. Django provides a way (technically, several ways) of mapping
URLs to specific callables, and provides a way to hierarchically
organize those callables based on argument structure.
I fail to see either the 'ugly', or the set of problems that can't be
solved. And it's somewhat spurious to say that "admin and forms" are
two things that Django can't do when Django ships with a forms
library, and Django's automated admin is one of the major initial
selling points of the framework.
I think you'll find you are. Why is what you are describing not
possible right now? Django is, at the end of the day, a machine for
turning a HTTP request into a function call, and turning the response
for that function call into a HTTP response. If you want to use a
particular class structure to compose that logic, go right ahead.
There's nothing in Django stopping you.
This may mean that you discover some magnificent class structure for
composing full websites from parts. What will convince me isn't a
dozen lines in an email -- it's a fully fledged project, with the
complexity of something like a CMS.
And it isn't me you need to convince anyway -- it's the wider
community. Trust me -- if you find the magic formula for perfect
reusability, my opinion won't matter. You'll be beating away
contributors with a stick. :-)
> The main stumbling block is that an app is somehow special to Django,
> specifically in that it is a directory, containing a file 'models.py'.
> The name of the app directory is included in INSTALLED_APPS in your
> settings.py. I guess other stuff might break as well (do urlpatterns
> and reverse views work for any method, rather than functions in the
> top level of a module?).
*This* is the stumbling block? Honestly? Can you please describe an
occasion where the fact that you need to predeclare the application
modules (and it is the *module*, not the directory) that you intend to
use has been an impediment to reusability? I fail to see how this is
any different to complaining that Python requires you to put "import
os.path" before you can do directory path manipulations.
> Django's idea of apps is great, because it gives us such an easy way
> to start. However, I think it breaks down in the above example. Would
> it be possible to rewrite Django so that the INSTALLED_APPS way of
> working would remain available, but would be a shortcut/facade to a
> manual registration of the various parts that entail an app? I think
> so.
You seem to be implying that your example is fundamentally constrained
by the existence of INSTALLED_APPS. Either I'm missing something, or
you haven't explained some subtle detail, because I simply don't see
the limitation.
> Hope to hear from you all, I will play a bit with some code in the
> meantime.
>
> p.s.
> Thinking about it some more: it's not weird at all that apps are hard
> to extend, since apps are limited to being modules. Modules are not a
> unit for extension.
Why not?
If you want to write a custom Email class, you don't put the code in
the Python standard library. You write a "my.custom.email" module, and
put an extension class in it. Why can't a module be used to organize
extensions?
Yours,
Russ Magee %-)
Well, Unix certainly came a long way with this philosophy
> The aim is that if you take the effort once to make your application
> reusable, the engineering payoff will happen quickly -- hopefully on
> your second build. However, if you have no intention of using a
> component a second time, then there isn't a whole lot of reason to
> spend the effort making it reusable.
True to a certain extend, but it takes a certain amount of experience to
recognize a true YAGNI.
regards
Steve
--
DjangoCon US 2010 September 7-9 http://djangocon.us/
Sure. Abstract models form the first part of this; the 'reference to
the concrete instance' is a known problem -- the most obvious example
of this surfacing is defining a custom User class to use in
contrib.auth. Alex provides one possible solution (join models) in his
talk; another (LazyForeignKey) was raised by Eric Florenzano in his
keynote [1]. However, this is still very much an open area of debate.
Any suggestions are welcome.
[1] http://djangocon.blip.tv/file/4112452/
Sure. There's at least two approaches. The first -- a method based
approach -- is used by contrib.auth (amongst others):
def my_view(request, arg1, arg2, klass=Page):
objects = klass.objects.filter(arg1=arg1, arg2=arg2)
...
The second is the class based approach, used by contrib.admin (and
others), which is to define a class-based view, and provide methods
like get_objects() that you can subclass to perform whatever behaviour
you need.
> Views.py methods generally have two types of parameters:
> 1. Those that are passed in via urls.py from the request path. Love
> 'em, couldn't live without 'em. This is what you're talking about.
> 2. Those we add (with usefull defaults) to make our app "reusable".
> What I was saying, is that I consider these in particular as unusable
> in the general sense. If I subclass the idea of address in an address
> book app (to add some field), would it make sense to refer to the
> subclassed address class in every call to every single view function?
> I'd say no. I'd rather say "give me my views where each view
> understands that it should use the improved address class).
Sure. And that's why you use class-based views. That's why Django's
admin is a class.
That's also why Django is in the process of getting a class-based view
framework - again, from DjangoCon, see Ben Firshman's talk [2]
[2] http://blip.tv/file/4109272
Yours,
Russ Magee %-)
Sure. However, Djangocon 2010 finished a week ago, so you're going to
have to wait until next year before we have the next serious
opportunity to do this.
It also helps to have a concrete proposal on the table, rather than
just a bunch of abstract "hey this sucks" bullet points.
Yours,
Russ Magee %-)
http://djangocon.eu/ is going to be in the spring of 2011. Let's see
how many of the "best of the bunch" are going to make it to
Amsterdam :-)