[IronPython] Python Pages -- web application stack (like django, rails, ...)

[Jonathan Slenders]

2008/6/12 Tim Roberts <timr at probo.com>:

> On Thu, 12 Jun 2008 02:18:58 +0200, "Jonathan Slenders" <
> jonathan at slenders.be> wrote:"
>
>> 2008/6/12 Tim Roberts <timr at probo.com>:
>>
>>> >
>>> > May I ask what motivated you to create this from scratch?  There are a
>>> > number of excellent Python web application frameworks available today,
>>> > several of which have syntax and functionality almost exactly like
>>> yours
>>>
>> If you know that many Python web frameworks, I'd really like to hear about
>> it. (I've seen several, yes, but some were very outdated and and not
>> maintained anymore)
>> Because I don't know much of them it's hard to say what I missed.
>>
>
> "Several" is a very dramatic understatement.
> * Django
> * Pylons
> * TurboGears
> * Zope
> * Karrigell
> * SkunkWeb
> * Webware
> * CherryPy
> * web2py
> * Albatross
> * Aquarium
> * Python Servlet Engine
> * Quixote
> * Snakelets
> * WebStack
>
> And that's still not the complete list.  That's why I asked the question.
>  I almost didn't ask, because I didn't want to sound like I was suppressing
> innovation, but I have to believe it would be better for the community as a
> whole to embrace and enhance one of the existing packages, rather than start
> over from scratch.
>
> --
> Tim Roberts, timr at probo.com
> Providenza & Boekelheide, Inc.



You mentioned some from which I've never heard about.. It's partly true that
one project would be better, but I think that users need a choice. The
reason I started this was because at that time I wasn't satisfied of all the
frameworks that I found (note that I didn't do much research) on the web and
it was not too much work to start my own framework. I know plenty of web
developers who code their website in raw PHP, just because they want to have
their own 'framework' they perfectly fits in their situation, and does only
the things that they want. Most web pages are really simple concerning
functionality. Further, I'm a big fan om modular programming, for me it
feels like some web frameworks try to do just to much. They say "you should
use MVC, you should use our templating language, our database abstraction
layer, our AJAX widget set, etcetera...". It's much better to keep all this
separate. Not only because very few developers need *all* these components,
but even less want exactly this combination.

What I'm trying to do is, just making a small layer right above Python,
enough to run an unmodified static HTML website, or a website with embedded
python code if you like to. It does low level concepts like handling
sessions and generating the output headers. Further I add some features to
simplefy things which are anyway part of any website. (clean URLs, includes,
...) Probably this is more or less the same level as PHP. For users who
don't have enough on that, they will run on top of that layer a content
management system (e.g. cmsmadesimple) or other higher level framwork. (but
they don't have to!) And that kind of users will run on top of that their
website. Users who need a database abstraction layer but no CMS should use a
library for that. A DAL shouln't be exclusively part of a web framework. It
should be a module that can be used in both a desktop application and a web
app. So this kind of users can simply use the database layer which matches
best in their situation. People who need AJAX can use a random AJAX library
(this can even be platform independent if it's javascript-only.).

Some of you who are against this kind of modular programming may argue that
a beginner doesn't now about enough to choose which library he'd need to do
what. But a beginner won't use this kind of functionality anyway. Which user
of phpmadesimple didn't ever code a raw PHP side before? In my opinion, it's
perfectly doable to use a basic low level layer, that's extremely friendly
but just doesn't have too much functionality and those who need build on top
of this with components of their own choice.

The framework I've been working on does not yet much, but when it is more
stable, it certainly becomes a very clean and flexible layer to build any
website or CMS on top.

Jimmy wrote:

> Integration between Silverlight and web frameworks for IronRuby and
> IronPython is definitely an awesome thing. John and I showed this stuff with
> Rails at RailsConf (we're working on getting that announced; let me know if
> you interested in it and I can send stuff your way), and Dino did something
> with Django at the past PyCon.
>

Thank you, I am definitely interested. But I'm still a student and now in
the middle of examinations. I will contact you about this within a month.

By the way, to continue my previous paragraph. This silverlight integration
runs on top of the core framework. The silverlight control is simply a page
that contains code to generate the XAP file based on ironpython code,
delivered by other pages. I still need to look what the best way is to get
most of the silverlight integration. Initially, this wasn't my highest
priority, but for sure, this becomes what I'll work on after the core is
stable, usable and cross platform.



PS: why do people spend years trying to juggle 5 balls or ride a unicycle,
while it's been done million times before. Because it's fun of course! (
Yes, I can juggle, and do off-road unicycling too :) )



Now back to my studies...  I may be away till the end of the month.
And for the IronPython folk, go on with your great work!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080612/5ddc97b4/attachment.html>