On 7/30/07, Snirp <[EMAIL PROTECTED]> wrote: > > > > 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. > 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. 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... > 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. 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 > 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-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
