This is fine when you want super simple things. But take a look at
django contrib for a whole list of things that would be absolutely
impossible if "apps" couldn't change the model. (A simple example, a
comments app, which allows you to add comments to various content.)
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
> This is fine when you want super simple things. But take a
> look at django contrib for a whole list of things that would be
> absolutely impossible if "apps" couldn't change the model. (A
> simple example, a comments app, which allows you to add comments
> to various content.)
I actually agree with both of you here. Components must be able to
add tables / model objects to your database. That being said, I
don't think that the only way to do this is to hardcode those model
definitions into the components themselves, for several reasons:
1. Its difficult to figure out what the component is creating
without either digging through the source or the documentation.
This creates a disconnect between how you interact with your
model typically, by simply looking at or editing your model
source.
2. Its difficult to change the data definition or plug in existing
model objects that provide the needed behavior without doing
weird things in some configuration file or monkey patching.
I'm tempted to suggest code generation as a solution for this, but I
think that also provides issues when you want to upgrade a component
for example.
Perhaps there could be a balance here, where if you just want the
default behavior of the component, and don't care about making
any tweaks to its behavior, you don't have to have much of the
component's code injected into your project, but once you start to
override things, you can have the code for that particular aspect of
the component copied into your project tree, where you can override
the behavior directly?
--
Jonathan LaCour
http://cleverdevil.org
> Other than upgrading, are there other issues with injection /
> templating? Is reuse in other projects / apps a concern? Are
> there other issues? From the standpoint of seeing what's going on
> and making changes though, injection is attractive (IMO).
Not really. The big issue is that it adds a lot of code to your
project that you didn't write, and makes it difficult to perform
upgrades to the component itself.
> How would a hybrid approach work? I'm guessing the end developer
> would issue a command to spit the component into the project, but
> what then? Is it totally in the end-developer's hands? From a
> component writer's perspective, it seems like there would be more
> overhead, but maybe you could make tools to help out.
Well, it seems to me that you'd issue a command the very first
time that you wanted to use a component, and you could tell it
whether you wanted the entire component's source spit into your
project, or if you'd prefer to use the defaults. Either way,
I think code should be added to your project, but the default
would be placeholders that import from the component, aliasing the
classes/functions from the component itself into your project's
namespace.
If you wanted to later tweak things, you could issue another
command, which could selectively start replacing those placeholders
(model, templates, API, etc) with the actual generated
code/templates, which you could then edit to your heart's content.
This is what I meant by a "hybrid" approach.
Even if this isn't "automated" it's still worth considering.
Providing insturctions on how to cut/paste is fine.
But if we automate it, we can also keep the "origonal" version of the
plugin (pre-modification) somewhere hidden to facilitate a
three-way-merge when you need to update that particular component.
The success of the Django component system seems to be based on the
fact that people are willing to put up with pain later (difficult
component updates) and some hand-editing up front, if they can get
some thing working quickly. And I don't think we should ignore that.
Sometimes the perfect is the enemy of the good.
If we make the future of 3-way merges possible, we don't nessisarily
need to make it work right now in order to be successful.
--Mark
The django way is pure code generation. There are 2 problems with
code-generation:
1) putting not-well understood code inside your project can create problems
2) updating generated code gets complicated
The Django people handle 1 by having reasonably simple "apps" which
aren't hard to understand, and which are reasonably well documented.
And they don't handle 2 at all.
I think documentation is actually a "good enough" answer to the first
problem. And if provide some sort of update tool that does a 3 way
merge that helps reduce the update pain, we'll be in very good shape.
So, I'm not opposed to code-generation on principe. Particularly if
we can help ameliorate the problems that have traditionally made
code-generation hard to handle.
--Mark Ramm
I am concerned when apps / extensions start touching my database. I am
usually doing advanced things in there, with lots of automation, triggers,
functions / stored procedures and views.
I want to get the most out of it and if I can't optimize the extension, it is
a huge drawback to me.
The major concern is that when using something generic it has to be designed
to the lowest common denominator, i.e., it won't use all the advanced
features of the database I chose for the project (mainly because of those
advanced features).
> How would a hybrid approach work? I'm guessing the end developer would
> issue a command to spit the component into the project, but what
> then? Is it totally in the end-developer's hands? From a component
> writer's perspective, it seems like there would be more overhead, but
> maybe you could make tools to help out.
I prefer that the project checks, at start time, for the presence of specific
classes on the model. The documentation would supply "cut & past'able" code
for those but it is the developer's responsibility to have those implemented
at the model with the semantics he / she wants.
For example, I don't want to have "UnicodeCol(length=255)" in any of my
classes. It makes no sense to the database I use and I consider that bad
practice. On the other hand, I understand that it makes sense for who
chooses using MySQL due to its other deficiencies.
So, if we have a generic API to define classes and locations for those and
have them checked just once at startup time, then it would solve the problem
and would allow me to optimize what I want at the database or controller
level.
--
Jorge Godoy <jgo...@gmail.com>