Discussion:
Considering Django for web-application. Your thoughts please.
(too old to reply)
Snirp
2007-07-30 15:35:20 UTC
Permalink
I am considering Django to develop a business-to-business service. It
should handle invoices (accounts payable) for my customers. It more or
less comes down to:

1. enter invoices [we | various XML formats go into the
database]
2. complete invoices [automated | interface with customers
accounting system]
3. validate invoices [customer ]
4. make booking [automated | interface with customers
accounting system]

The actual story is much more complex, as it deals with invoices on a
line-item level. These must be able to be distributed / discussed /
divided among users who act as budget-keepers of distinct
departments.

I have had a little playtime with django, and I found it pleasing to
work with. It seems to be up to the task. I also compared it to Seam
(RedHat Java-framework). Some questions came up:

- The Java application stack boasts excellent scalability, will this
ever be a problem for python / django (database-transactions etc.)?

- Integration with Jbpm (workflow engine) is a strong-point with Seam;
designing pageflow directly from process management. Is there anything
like it for Django?

- The default django user-interface uses permissions and users. Is
this easily expanded with roles? Or is there a reason why there is no
definition of roles?

- On what level should I seperate different customers? Different
websites / different databases / same database? Is there a smart
choice, or a really stupid one here?


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Brad Siegfreid
2007-07-30 15:52:05 UTC
Permalink
There's some big questions in there. Maybe you should stick to one for now
and then get follow up on the details if you decide on Django: Python and
Django vs Java and some enterprise framework.
I use Java for my main project and also looked at Seam and JBPM. My day
project is limited to Java for a variety of reasons but I've been using
Django for smaller projects for myself and friends. If I could move work
over to Python and Django I'd do it in a heartbeat. I feel like each new
Java framework attempts to hide complexity but ends up hiding capability and
introducing new compatibility issues. I've taken a new approach at work by
striping away as many frameworks as I can and slowly adding only what is
needed.


With Python and Django I feel closer to the code and have as much capability
as I need. There is also a lot less code to deal with.

Also, don't forget Java's compile and deploy cycle compared to Django much
faster turnaround. This become especially noticeable if you start using Ajax
techniques. I could probably rewrite my project in Django in the spare time
I have waiting for
Post by Snirp
I am considering Django to develop a business-to-business service. It
should handle invoices (accounts payable) for my customers. It more or
1. enter invoices [we | various XML formats go into the
database]
2. complete invoices [automated | interface with customers
accounting system]
3. validate invoices [customer ]
4. make booking [automated | interface with customers
accounting system]
The actual story is much more complex, as it deals with invoices on a
line-item level. These must be able to be distributed / discussed /
divided among users who act as budget-keepers of distinct
departments.
I have had a little playtime with django, and I found it pleasing to
work with. It seems to be up to the task. I also compared it to Seam
- The Java application stack boasts excellent scalability, will this
ever be a problem for python / django (database-transactions etc.)?
- Integration with Jbpm (workflow engine) is a strong-point with Seam;
designing pageflow directly from process management. Is there anything
like it for Django?
- The default django user-interface uses permissions and users. Is
this easily expanded with roles? Or is there a reason why there is no
definition of roles?
- On what level should I seperate different customers? Different
websites / different databases / same database? Is there a smart
choice, or a really stupid one here?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Snirp
2007-07-30 16:25:14 UTC
Permalink
Post by Brad Siegfreid
Maybe you should stick to one for now
and then get follow up on the details if you decide on Django: Python and
Django vs Java and some enterprise framework.
Yeah, i agree i got it a bit clogged up. What matters most now is to
make the right choice. Scalability and business logic handling are the
two concerns that matter most.
Post by Brad Siegfreid
I use Java for my main project and also looked at Seam and JBPM. My day
project is limited to Java for a variety of reasons but I've been using
Django for smaller projects for myself and friends. If I could move work
over to Python and Django I'd do it in a heartbeat.
Was BPM not a issue in these smaller projects, or did you have a way
of dealing with this? I am much less experienced a developer and want
to avoid using the wrong tool and hammering a screw in. On the other
hand, however much I was impressed with JBPM, I am not 100 % certain
that I need it for workflow.
Post by Brad Siegfreid
I feel like each new
Java framework attempts to hide complexity but ends up hiding capability and
introducing new compatibility issues. I've taken a new approach at work by
striping away as many frameworks as I can and slowly adding only what is
needed.
Glad you say so, since I was overwhelmed by the application stack,
level of abstraction and sheer size of Seam.
Post by Brad Siegfreid
Also, don't forget Java's compile and deploy cycle compared to Django much
faster turnaround. This become especially noticeable if you start using Ajax
techniques.
How do you mean this? I will rely on Ajax techniques, but i tend to
see them as somewhat loosly coupled to the framework. As far as I can
judge, Django agrees and does not provide Ajax integration. You can
choose for this approach in any other framework (right?), and go for
the specific ajax framework / techniques you like best.

I this way ajax will never be a factor in a comparison of high-level
frameworks, or am i wrong on this?



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Brad Siegfreid
2007-07-30 17:18:06 UTC
Permalink
Post by Snirp
Was BPM not a issue in these smaller projects, or did you have a way
of dealing with this? I am much less experienced a developer and want
to avoid using the wrong tool and hammering a screw in. On the other
hand, however much I was impressed with JBPM, I am not 100 % certain
that I need it for workflow.
At least for our project I found BPM to be overkill. To me it was another
framework that distanced the developers from the code and had to be learned.
Our newest release is focusing on REST which emphasizes stateless
interaction anyway. The few processes that require page to page flow will
either be Ajax or hand built with little effort.
Post by Snirp
I feel like each new
Post by Brad Siegfreid
Java framework attempts to hide complexity but ends up hiding capability
and
Post by Brad Siegfreid
introducing new compatibility issues. I've taken a new approach at work
by
Post by Brad Siegfreid
striping away as many frameworks as I can and slowly adding only what is
needed.
Glad you say so, since I was overwhelmed by the application stack,
level of abstraction and sheer size of Seam.
I really liked Seam for what it did and we probably spent more time
prototyping with it than other solutions. But in the end I didn't like to be
shut out of the basic HTTP process. Seam is a fairly elegant solution for
covering complexity but by removing other frameworks from the stack we were
able to simplify the whole stack and we didn't need it anymore.

Start simple and build from there.

Remember that a web app is built for HTTP. The more you do to change it from
that the more work you make for yourself. But, that's a different group to
follow...
Post by Snirp
Also, don't forget Java's compile and deploy cycle compared to Django much
Post by Brad Siegfreid
faster turnaround. This become especially noticeable if you start using
Ajax
Post by Brad Siegfreid
techniques.
How do you mean this? I will rely on Ajax techniques, but i tend to
see them as somewhat loosly coupled to the framework. As far as I can
judge, Django agrees and does not provide Ajax integration. You can
choose for this approach in any other framework (right?), and go for
the specific ajax framework / techniques you like best.
We deploy our project as an EAR file to JBoss. Web-app, javascript and
everything gets deployed and managed by the container. We're also Java
developers first that are learning Javascript so we try, fail and try again
with our scripts. Unless we hijack the deployment process we have to
redeploy our ear file to test changes to javascript. That's on my todo list
but our dependencies makes changing our build and deploy test cycle rather
difficult to change.

With Django I can tweak both Python and Javascript without having to
redeploy. Apache or Django's test server doesn't care what I'm up to. You
change something and at most wait for Django to quickly recycle. If you are
just changing Javascript you don't even have to do that. Just refresh the
browser page. Much faster development.

I'm talking about about 9 minutes between change and test compared to maybe
a few seconds.

I this way ajax will never be a factor in a comparison of high-level
Post by Snirp
frameworks, or am i wrong on this?
If the Ajax app is external to your EAR file or you are able to directly
edit the deployed files without fear of them being overwritten because of
changes in an ear file then you are OK.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Snirp
2007-07-30 21:13:21 UTC
Permalink
You are being most helpful mr. Siegfreid. I will take your advise to
heart and start out simple.

The following expresses my personal opinions:

I am aware that a comparison against one Java-framework is very
insufficient.

Other frameworks can do the job just as well, i am sure. I see no
compelling reasons to go for something PHP (unreadable code for future
programmers) and Ruby (somewhat obscure, centered around rails). Since
I already got my feet wet with Python / Django and since it is
comparatively simple, i prefer it for further use now. I am sure it
will get me the quickest development and it allows me to start simple.

The concerns are few:

- lack of big corporate backing (like Seam) and guaranteed sound
documentation
- much smaller user-base than RoR
- possible future extension of the project with a procurement system
and resulting demand on resources

The last is not an immediate concern and the scale is not yet clear.
The speed of development is much more of a concern.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Brad Siegfreid
2007-07-30 21:48:24 UTC
Permalink
Post by Snirp
- lack of big corporate backing (like Seam) and guaranteed sound
documentation
Lack of big corporate backing is seen as an advantage to some. They need to
make money somehow and support contracts can be very lucrative. Small teams
can do amazing work. Just look at what the Django people have accomplished.

- much smaller user-base than RoR


I hadn't noticed. Django is certainly smaller than Java EE. Python appears
to have a lot more choices for web frameworks than Ruby. RoR does have
mind-share right now and is probably a viable alternative to Python and
Django but I like the Python language better.

- possible future extension of the project with a procurement system
Post by Snirp
and resulting demand on resources
The immediate thing I would look at is if the procurement system only
provides an EJB interface or some other Big Vendor lock-in. Sometimes that
barrier can be crossed but it could be painful.

The last is not an immediate concern and the scale is not yet clear.
Post by Snirp
The speed of development is much more of a concern.
Speed of development definitely points to a dynamic language.

Good luck on your project. Take time to play with several options before you
settle and see what works for you. This is a Django joint so I'd gently push
you in that direction. Then again, you won't find me hanging out with my
Java brethren if that means anything to you. In the end its your choice.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Continue reading on narkive:
Loading...