Python gets another web framework: Gluon
857 views
Skip to first unread message
Mike Pirnat
Dec 7, 2007, 10:48:27 PM12/7/07
to clepy
If Python developers are naughty, Santa foregoes coal and instead
leaves new web frameworks in their stockings...
leaves new web frameworks in their stockings...
http://mdp.cti.depaul.edu/examples/default/index
--
Mike Pirnat
mpi...@gmail.com
http://www.pirnat.com/
Benjamin Smith
Dec 8, 2007, 9:58:21 PM12/8/07
to cl...@googlegroups.com
I've played with it for about an hour. Initial impression was great as I found it a breeze to install and manage. A few quick, not in depth bullet points follow..
Things I like:
Things I don't like:
That's all I've noticed after about a half an hour of playing with it that make me feel a little icky. Maybe there's some pythonism behind some of the things I don't like so much that I'm missing in my noobness??
Things I like:
- I especially like the Model interface..almost feel dirty when creating a model because of how simple it is.
- WSGI compliance is bomb-digity.
- Love the built in ticket creation.
- Love the idea of byte compiled distribution of your application.
- Upgrading seems to be fairly simple.
- Migration from one box to another, regardless of distribution is super simple.
Things I don't like:
- Printing layout elements from the Controller level feels gross; reminds me of how Perl's CGI.pm did it, which I really dislike. I'll avoid it, unless necessary.
- Some of the naming conventions bother me and don't seem very intuitive.. Just to name a few...
- Controller: T("blah") doesn't scream internationalization to me.
- View: {{pass}} feels funky to specify the end of a conditional, or loop?
- View: What's .flash all about on the response and request methods?
- The admin interface seems like could get quite cluttered as your application grows..
- To use with apache, it requires some proxyness that I don't dig.. I'd roll with the WSGI option.
That's all I've noticed after about a half an hour of playing with it that make me feel a little icky. Maybe there's some pythonism behind some of the things I don't like so much that I'm missing in my noobness??
Matt Wilson
Dec 10, 2007, 3:20:02 PM12/10/07
to clepy
I was sad when I saw the FAQ page didn't answer the question "WHY
DIVERT ATTENTION INTO YET ANOTHER HALF-FINISHED WEB FRAMEWORK?"
Matt
DIVERT ATTENTION INTO YET ANOTHER HALF-FINISHED WEB FRAMEWORK?"
Matt
Christian Wyglendowski
Dec 10, 2007, 3:50:35 PM12/10/07
to cl...@googlegroups.com
On 12/10/07, Matt Wilson <mw4...@gmail.com> wrote:
>
> I was sad when I saw the FAQ page didn't answer the question "WHY
> DIVERT ATTENTION INTO YET ANOTHER HALF-FINISHED WEB FRAMEWORK?"
>
> I was sad when I saw the FAQ page didn't answer the question "WHY
> DIVERT ATTENTION INTO YET ANOTHER HALF-FINISHED WEB FRAMEWORK?"
Aw, I'm sure most of us have a half-finished web framework lying
around somewhere ...
Christian
http://www.dowski.com
Benjamin Smith
Dec 10, 2007, 4:04:58 PM12/10/07
to cl...@googlegroups.com
mdipierro
Dec 16, 2007, 9:44:50 AM12/16/07
to clepy
The all point about Gluon is that it is finished in the sense that it
has a minum set of API there were stable since day one and I will
guarentee backward compatibility for future versions. There will be
bug fixes (assuming bugs are found) and there may be new features (if
users request them) but the basic API will not change. The admin
interface may change because use are encouraged to design a better
one. The present one works fine for me and it is very scalable.
Gluon was developed because both Django and Pylons have API that
change amost weekly and that is not acceptable.
About the use of pass for closing blocks. This is a convention used by
Python programmers who use emacs. In fact pass in Python is a command
that does nothing and therefore it is assumed to indicate the end of a
block. Emacs and Gluon automatically indent the code using similar
algorithms.
The generation of html in controllers is not a good idea but there are
occasions when it is unavoidable. Gluon provides helpers for those
rare situations but encourages users to put html in the models.
has a minum set of API there were stable since day one and I will
guarentee backward compatibility for future versions. There will be
bug fixes (assuming bugs are found) and there may be new features (if
users request them) but the basic API will not change. The admin
interface may change because use are encouraged to design a better
one. The present one works fine for me and it is very scalable.
Gluon was developed because both Django and Pylons have API that
change amost weekly and that is not acceptable.
About the use of pass for closing blocks. This is a convention used by
Python programmers who use emacs. In fact pass in Python is a command
that does nothing and therefore it is assumed to indicate the end of a
block. Emacs and Gluon automatically indent the code using similar
algorithms.
The generation of html in controllers is not a good idea but there are
occasions when it is unavoidable. Gluon provides helpers for those
rare situations but encourages users to put html in the models.
Matt Wilson
Dec 16, 2007, 11:04:47 PM12/16/07
to clepy
On Dec 16, 9:44 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> The all point about Gluon is that it is finished in the sense that it
> has a minum set of API there were stable since day one and I will
> guarentee backward compatibility for future versions. There will be
> bug fixes (assuming bugs are found) and there may be new features (if
> users request them) but the basic API will not change. The admin
> interface may change because use are encouraged to design a better
> one. The present one works fine for me and it is very scalable.
>
> Gluon was developed because both Django and Pylons have API that
> change amost weekly and that is not acceptable.
Thanks for the feedback!
> The all point about Gluon is that it is finished in the sense that it
> has a minum set of API there were stable since day one and I will
> guarentee backward compatibility for future versions. There will be
> bug fixes (assuming bugs are found) and there may be new features (if
> users request them) but the basic API will not change. The admin
> interface may change because use are encouraged to design a better
> one. The present one works fine for me and it is very scalable.
>
> Gluon was developed because both Django and Pylons have API that
> change amost weekly and that is not acceptable.
That's depressing to hear about Django. I haven't heard that
criticism before.
Catherine Devlin
Dec 17, 2007, 4:38:46 AM12/17/07
to cl...@googlegroups.com
Is anybody with experience going to be at CodeMash? Want to seize
some OpenSpace there for a demo?
some OpenSpace there for a demo?
--
- Catherine
http://catherinedevlin.blogspot.com/
mdipierro
Dec 18, 2007, 4:47:38 AM12/18/07
to clepy
Reply all
Reply to author
Forward
0 new messages