Hello,
The following is quite long but reflects a non developper point of view.
I'll expose briefly that business analysis already splits logic and why
I think you should follow previous recommandations. I'll finish "out of
subject" commenting your documentation request.
> Split business logic
When you have to describe business logic to a dev, seperating business
responsabilities is a good start. I think it's a thought orientation
shared by "business analysts" (I'm not sure this is the right term in
english) and developpers. The process often shows that a same object can
be approached from different perspectives (for exemple, sales,
comptability, logictic both work with orders but with different
perspectives). You'd better keep this object as generic as possible and
let each perspective set its own attributes at its very level. This
mailing list shows multiple practical examples with the User notion.
In the process, you have to be consistent and a direct extra benefit is
polishing each application interface. From a non developper point of
view, I find far most easier to write applications when the semantic and
the interfaces are clean. It helps your application's usability and it's
documentation too.
As most developpers complain, business logic tends to change and it's
implementation has to follow. Both at business and application levels,
these changes should be kept at their perpective level (for example, a
change in accounting should not compromise other fields and not be a
revolution in actual business if possible).
My point is that it is a normal business analysis process to split
responsabilities as far as possible and Django allows you to write
multiple apps to implement that. Implementation problems are about the
same that those brought while debatting applications reusability. If
your project may have multiple dependencies, your app should keep them
minimal at their level: this process is already part of business
analysis when modeling "packages".
In business, a task can be reassigned: if you want something done, you
must ask somewhere else. Putting that in Django, if you want to reach a
ressource, you use an url and the url mapper will call the ressource for
you. Django allows you to name your urls and you can implement
get_absolute_url easily. I see the way Django handles urls as a great
strength. I take the opportunity to state that url are part of a web
application interface (browsers are only a part of available clients).
To rephrase all of that, splitting your project in multiple parts is
already a business analysis requierement before reaching the
developpement process.
> Documentation and guidelines
When speaking about Django's pro, the admin and the documentation come
often. They reflect both a practical approach. Django's documentation
show it's developpers philosophy and puts emphasis on good practices.
Django's original design history and the framework's multiple actual
fields of application tend to proove that team's member are not totally
subject to delusion ;).
I found that adding guidelines on a subject to applications'
documentation helps greatly: it summarise the concepts, reinforce
consistency and puts the recent knowledge on another perspective, acting
as a seal. It draws practical schemas and are good entry points to the
"practical cases to concepts" learners and can bring "step by step"
learners to a more self-implying approach. It reinforce pattern
recognition during the analysis. They are often used for feedback.
Writing them is time consumming, that's the bad part.
Ensuring that applications are designed to properly integrate into the
framework helps to reinforce the framework. Extensions / plugins /
adapters are considered when chosing a solution and for Django, they are
the apps. Django is a practical solution by its extension ability. A pro
often advanced in favor of frameworks usage is the standardisation of
the developpement process.
Explicitly tell the direction is the most simple way to garanty that, as
far I can tell.
While speaking of designing applications, I think that testing should be
shown since the tutorial, at least in a minimal form. (by the way,
testing advocates again a rationnal spread of responsabilities into the
project).
> Thanks
Sorry, I lied in the begining. I was quite long so if you reach this
point, you'll don't mind if I thank both Django's team to brought me
into the enjoyment of developpement and the community for its
participation and its enthousiasm.
Regards,
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
