Having doubts about AppEngine
javaDinosaur
applications for GAE. My concerns are not technical although I have a
some anxieties about transaction data propagation performance.
My concerns center around Google’s commitment to the App Engine
project. Compared to Amazon’s Web Service forums this place feels like
a technical backwater. Developers hosting on Amazon AWS post
interesting questions and get deep-dive replies promptly from Amazon
staff. Amazon is releasing new Cloud development services monthly yet
all we get is minor patches.
Here on the GAE forum elementary questions about how GAE ticks go
unanswered for months. Basic roadmap type info such as will we get SSL
or scheduled tasks is missing.
I just feel that the GAE Team is not building up any development
stream in what should be the last 4 month run up to the year-end
release. Communication with the developer community here is abysmal
compared to the investment in developer relations made by companies
such as Microsoft, Redhat or Amazon.
What’s happened to the early buzz Google? Has the top bass pinched
half the team to firefight problems on another project?
Bill
App Engine as a significant Google offering. AWS has a much larger
community and with the addition of persistent storage and sorting of
Query results, Amazon is rapidly shoring up their deficiencies. That
said, the two services target different audiences since you still have
to do a lot of infrastructure management to get something like App
Engine on top of AWS. (Or you can pay RightScale or others to do it.)
Also, App Engine is significantly younger than AWS. Forum traffic and
articles on Amazon EC2 was light at the beginning as well. IMHO, I
think a lot of programmers are waiting for pay-as-you-go and possibly
https. Beta AWS services start with pricing and charging at launch.
EC2/SimpleDB programmers will be more self-selected than Google App
Engine developers because you have to know the full stack (from OS on
AMI on up). I can also see a lot of small development shops going the
App Engine route because (1) free resources up to a certain point and
(2) little infrastructure issues.
I've been impressed with the Google App Engine team but also wonder
how much support they can draw from Google. Jeff Bezos attends AWS
events and provides a clear signal that they view AWS as a core
offering. I think Yahoo management will do the same if Yahoo launches
their version of App Engine. Having stars like GvR on the App Engine
team sends a signal as well, but it's different than having top
executives talk up the service.
cb
on the SSL issue. Right now this has been a hobbyist endeavor for me
because of the lack of a clear cut roadmap. GAE is fun....but fun
does not pay the bills!
>
> - Show quoted text -
Edoardo Marcora
very serious issue!!!
Filip
sorting, and the Block Store before that, Amazon is really improving
their offering fast. S3-Europe shows they are sensitive to legitimate
concerns of users, and we can hope other offerings will be Europe-
based in the near future too. SSL has always been there. This kind of
momentum seems to be lacking with Google App Engine.
But most worrying to me is the Google Quota system. When Google does
metrics on the uptime of their service, they should not count the
uptime of their service, but the availability of their service to me,
that is what matters to me. In particular, it is totally unacceptable
that a GAE-based site becomes unreachable for minutes, let alone for
hours or better parts of the day. Clearly, attacks should be avoided
by denying traffic when it ramps up suspiciously fast, but bringing
down the customer's site all together is out of the question. This
Google practice has got me more sceptable about the usability of GAE
for Web 2.0 applications (as opposed to competing services).
Also, Microsoft SSDS suffered a major breakdown this week but the
communication on the topic was very good. There is room for
improvement obviously, but very professional already. It is to be
expected that they announce their GAE competitor on October 27 or 28,
as well as notable improvements to their SSDS service.
I'm sure Google will shore up their deficiencies over time as Amazon
is doing. But an acknowledgement of the issue, and a timeline on when
it might be resolved is important to win and retain the hearts and
minds of the developers. Even if that timeline indication is simply
"after 2009". At least then we know we need to engineer around it.
Having said that, I do believe there is substantial merit to the way
Google is approaching this, with potential automatic scale-up not yet
available with the other services. But as said by the other guys on
this thread, the communication is really insufficient at this point.
Filip
Wooble
On Aug 28, 12:27 pm, Filip <filip.verhae...@gmail.com> wrote:
> But most worrying to me is the Google Quota system. When Google does
> metrics on the uptime of their service, they should not count the
> uptime of their service, but the availability of their service to me,
> that is what matters to me. In particular, it is totally unacceptable
> that a GAE-based site becomes unreachable for minutes, let alone for
> hours or better parts of the day. Clearly, attacks should be avoided
> by denying traffic when it ramps up suspiciously fast, but bringing
> down the customer's site all together is out of the question.
start paying them, and when you start paying them the quotas won't
bring down your site because you'll be paying them for the usage over
the quota. Instead of comparing their free preview service to S3, try
comparing it to any other free hosting service out there.
Dennis Peterson
Bill
> Instead of comparing their free preview service to S3, try
> comparing it to any other free hosting service out there.
us using App Engine with grander aspirations. We want to build easily
scaled web applications (real businesses) on top of App Engine. I
wouldn't have spent much time with App Engine if it were going to
remain just a free hosting service with quotas. If you look at the
front page of App Engine, it's clear that Google wants to handle real
businesses as well.
So for developers looking to build scalable apps that could
potentially grow "to millions of users," the best comparison right now
is to Amazon's cloud computing effort and the App Engine-like
businesses that are being built on it (RightScale, Heroku, AppJet,
etc).
As a preview user, it's useful to voice your concerns and issues in a
reasonable manner. Part of it is through the issue tracker, but this
board is a valuable sounding board for developers. I *want* Google to
succeed since I'm putting my time and ventures into it. The more
effectively they address these concerns, the better they'll look
compared to AWS, and that fosters a strong developer community.
Michael Schreifels
Google did offer better communication. However, I just wanted to point
out:
Jaiko is a company acquired by Google quite a while back. A TechCrunch
post today ( http://www.techcrunch.com/2008/08/28/jaiku-uncaps-invites-migrates-to-google-infrastructure/
) links to a previous blog entry, which indicates their intention to
convert the app entirely to App Engine:
http://www.jaiku.com/blog/2008/04/08/wroom-were-moving-to-google-app-engine/
This seems to be a promising sign of investment in AE on Google's part
(although the move was almost certainly made solely for that purpose).
Andrew Badera
Google technology stack is the distributed filesystem, is the search API, the mail API, MapReduce and everything else Google offers from it's vast datacenters.
AppEngine is a drop in the bucket, a small window into that stack.
Google Analytics is really a cannibalized and repackaged Urchin. Expect something similar out of the Jaiku "revolution." A lot of heavier-duty Urchin users felt left in the dust when Google picked apart the offering and halted new development. Again, expect something similar out of Jaiku -- because Google has become a place companies go to die. (GrandCentral anyone?)
Thanks-
- Andy Badera
- and...@badera.us
- (518) 641-1280
- http://higherefficiency.net
- http://changeroundup.com/
- http://flipbitsnotburgers.blogspot.com/
- http://andrew.badera.us/
- Google me: http://www.google.com/search?q=andrew+badera
Filip
in a free hosting company. I need a professional platform provider
that I can base business applications on. If you are someone
interested in making an application for your friends and family, then
we are perhaps not talking about the same thing.
On this forum, the "you are not paying" argument has been used over
and over. But I am NOT paying Microsoft to notify me of downtimes of
their SSDS service. Not paying them to inform me of their roadmap. The
Microsoft Chief Technology Officer himself will be announcing the next
step on their cloud offering in October. There is good communication
over there, which certainly can be improved but even when they can't
say something, they tell us why and on what date they will release the
information, providing the needed clarity. Google has been notorious
for poor communication on many of their consumer-oriented
applications, but when it comes to business applications, that is just
not good enough. And since I am building a business application, that
is the standard I judge them on.
The reason why Amazon is praised, I believe, is not because they have
the perfect answer, but because they had the guts to call their
product 1.0 and go with it.
But let's look at your argument. Let's compare with other services out
there (free or otherwise). Can you name any who has a policy as poor
as Google's when it comes to quota? I can't think of any big name. A
hosting company that says you can host here, but when you get a sudden
spike in requests, they'll shut down your site for the rest of the
day, even if you are not over quota on any metric. Who else does that?
How could that ever be web 2.0-ish.
And Google is not in competing with the free or obscure services, they
are competing for the business market with Amazon, Microsoft and soon
Yahoo! and likely others as well. It does not matter if they have a
different business model. Who they compete with is evident from their
announced pricing schemes.
Google is in competition with those services TODAY, not tomorrow or
next year, and waiving the beta flag is no excuse. Every day, people
are deciding which platform to develop for. Talking about what is
coming at what time, helps people to decide whether they are willing
to walk with you on that trip to release to market. The "technology
preview" argument was good back in March, but today, it no longer is.
Google has real experience since then, and there is nothing preventing
it from communicating. Secrecy doesn't help them defend against
competitors, the better communication with competitors is exactly why
they are losing developers.
Going live at the end of the year seems unlikely given the amount of
serious problems that remain unaddressed. But the cloud is not waiting
around for Google to be ready. This is not a market dominated by
Google, and in fact Google does not even have the best cards. They do
not have the best track record in the industry for attracting
developers. What is worse, public and private companies abroad are
notoriously scared of keeping data on Google's (US-based!) machines
precisely because the company is all about information processing, and
because of US legislature. Moreover, Google is unknown as platform to
the CIO's and IT managers. So they are effectively the underdog, who
need to be substantially better than the competition to even have a
chance at cracking the business market. What they do have is a smart
scaling method, an early integrated hosting environment and an early
jump to market, which gives them some leverage. I fear they are
loosing their early jump as others are moving faster, and I'm pretty
sure competitors are working on smarter scaling and better integration
methods too.
And I am one of those in the business arena who actually is a strong
pro supporter of Google.
Filip.
Dennis Peterson
Jonathan Feinberg
> are competing for the business market with Amazon, Microsoft and soon
> Yahoo! and likely others as well.
to develop their commercial applications on App Engine. Do you have
any pointers to such public statements?
> Google is in competition with those services TODAY
services (GAE vs EC2/S3/SQS/etc.) are not comparable. Amazon's
offerings are much lower-level, and require a great deal of tech savvy
to exploit. I use (and adore) the Amazon stack where appropriate, but
would never even think of using it for a web app like my wordle.net.
It would be like building a whole factory, from scratch, to sell
lemonade from my driveway.
I don't know enough about the Microsoft and Yahoo offerings to compare
them.
The App Engine platform is a way to build massively scalable CRUD-
style web apps by sticking to a few simple constraints. It's perfect
for situational apps, one-offs, hobby projects, all of which can now
survive slashdotting without arcane architectural hacks. What's not to
love about that? Why criticize it for not being something it isn't
designed to be?
If I've missed any claims to the contrary from Google, again, please
point me to them.
Michael Schreifels
> style web apps by sticking to a few simple constraints. It's perfect
> for situational apps, one-offs, hobby projects, all of which can now
> survive slashdotting without arcane architectural hacks. What's not to
> love about that? Why criticize it for not being something it isn't
> designed to be?
> to develop their commercial applications on App Engine. Do you have
> any pointers to such public statements?
without the time, interest, or money to build a scalable
infrastructure around them.
From http://blogs.zdnet.com/SAAS/?p=489 -- the AE project manager:
“We’re much more suitable for the consumer marketplace during the
preview release.”
Now let's think about this. Google creates an infrastructure to create
web applications with a seemingly infinite amount of no-hassle scaling
(for a price, of course). Are they really targeting Joe Brown who is
creating a website to share pictures of his new kid with his family?
Of course not. The quota is theoretically capable of serving 5 million
users for free. If we are just talking about mere hobbyists with a few
hits a day, how would users ever exceed the quota and allow Google to
charge them money?!
But if Google is shooting for businesses, why did the product manager
say it's best suited for the consumer marketplace ("DURING THE PREVIEW
RELEASE")?
"...citing as examples the lack of an SLA and the ceilings on usage
that result in a denial of service when exceeding the limits..."
Sounds like two problems that are most certainly going to be fixed
after the preview.
> I don't see how App Engine is "in competition" with Amazon. The
> services (GAE vs EC2/S3/SQS/etc.) are not comparable. Amazon's
> offerings are much lower-level, and require a great deal of tech savvy
> to exploit. I use (and adore) the Amazon stack where appropriate, but
> would never even think of using it for a web app like my wordle.net.
> It would be like building a whole factory, from scratch, to sell
> lemonade from my driveway.
apps. GAE doesn't offer anything close to the control that Amazon
does, but I bet there are a lot of Amazon customers that would trade
their control for the worry-free scaling of AE. They both are
attacking the same problem, but very differently.
Marcel Overdijk
People are asking for this in a oot of discussions, but there is no
info from Google yet. To bad I think.
See also:
http://groups.google.com/group/google-appengine/browse_thread/thread/aab96f8adcb99725/00b76bbfc5a43a65?lnk=gst&q=overdijk#00b76bbfc5a43a65
On 30 aug, 04:02, Michael Schreifels <tech...@gmail.com> wrote:
> > The App Engine platform is a way to build massively scalable CRUD-
> > style web apps by sticking to a few simple constraints. It's perfect
> > for situational apps, one-offs, hobby projects, all of which can now
> > survive slashdotting without arcane architectural hacks. What's not to
> > love about that? Why criticize it for not being something it isn't
> > designed to be?
> > I missed where anyone from Google claimed to be looking for businesses
> > to develop their commercial applications on App Engine. Do you have
> > any pointers to such public statements?
>
> I think App Engine *is* targeting startups and other small businesses
> without the time, interest, or money to build a scalable
> infrastructure around them.
>
Michael Schreifels
I really don't see the Django template language being a valid concern
at all. It is just a library that Google provides, no one is forcing
you to use it.
And further, personally I think that if you find Django templates too
limiting, you probably don't fully understand it. I switched to Django
after coding with Ruby on Rails and PHP, both of which allow you to
embed code right in your templates. It was a difficult transition at
first, but the restrictions placed by the Django template language
make sense, and they encourage good programming practices of the
separation between programming logic and presentation code.
And if you're concerned about reusing blocks of code, the concerns
about {% with %} are only relevant to Django < 1.0, and the devs have
been telling users to use SVN (which is very stable) and not 0.96 for
MONTHS now. (Yeah, AE only supports 0.96 out-of-the-box, but that
makes sense. Why would Google want to track SVN? I just have my own
checkout of Django I use. And besides, Django 1.0 is due for release
next week. I guarantee Google will support it.) And besides, I have
never had to use {% with %}. Most code repetition I come across is
more logically solved with block inheritance.
I strongly recommend you upgrade to the latest Django beta and read
the template docs. And if it really doesn't work for you, there are
plenty of other options.
This post is really about the problems that Google has with
communications about where App Engine is going (and WHEN).
On Aug 30, 4:56 am, Davide Rognoni <davide.rogn...@gmail.com> wrote:
> Doubts about Django Templatehttp://groups.google.com/group/google-appengine/browse_thread/thread/...
Noah Gift
>
> Davide,
>
> I really don't see the Django template language being a valid concern
> at all. It is just a library that Google provides, no one is forcing
> you to use it.
I think for new comers to Python, it IS presented as the only choice
as many people would have difficulty "monkey-patching" another
template engine, as there have been issues in getting, to my knowledge
at least, Mako and Genshi to fully work on appengine. It seems like
this new cookbook area would be a good spot to for developers of those
other templates to put their integration recipes:
http://appengine-cookbook.appspot.com/
>
> And further, personally I think that if you find Django templates too
> limiting, you probably don't fully understand it.
It is still very controversial in the Python community to not include
the ability to run Python in the template. I think it is very
appropriate for newcomers to question how and why something works the
way it does. It is far from a foregone conclusion that Django
templates are the superior way to accomplish templating in Python.
I have personally observed two PHP developers turned off from wanting
to use Python ever again, because they were forced to use Django
templates in a project.
Of course we Python programmers could say, wow your "stupid" because
you don't do it my way, it is the best. On the other hand maybe they
have a point. Sometimes, in my opinion too, some Python in the
template is the easiest way to solve a problem.
They were a bit offended that this design decision was not delegated
to them, instead of forced upon them. I think it is ok, to question
this decision if you are from another language.
Here are links to blog entries by Shannon Behrens, a guy who wrote a
Python web framework in 2001, in which he also questions the wisdom of
Django templates:
http://jjinux.blogspot.com/search?q=django+template
I don't consider him to not understand Django templates, yet he also
doesn't use them. This is really a personal decision though, as many
people are happy with Django templates. To each their own. One thing
I do disagree though is that if you don't like some portion of Django
like templates, or the URL dispatch, you don't know how it works. I
think many people know how Django works, but only like certain parts
of it. I happen to really like the admin interface and the URL
dispatching, and not the template or ORM.
In addition, I have personally done some very large Django projects,
and have some issues with doing things with the Django templates. I
don't particularly care for them, and would prefer Genshi or Mako,
although they aren't horrible either.
One gripe I have with Google is that they need to correct their
documentation here:
http://code.google.com/appengine/docs/gettingstarted/usingwebapp.html
It states that app engine supports: Django, CherryPy, Pylons, and
web.py This is actually incorrect, as many of the components, like
templates, in Pylons are not fully tested and working. Hopefully this
gets addressed soon.
--
Noah Gift
http://noahgift.com
Roberto Saccon
commitment to Django templates. There are plenty of other frameworks
and template languages, choose the one which fits your needs or if
none fits your needs build one yourself (aren't you doing that
already, the JS thingy ??), I am happy that Google has chosen the most
popular one in Python land.
regards
Roberto
On Aug 30, 4:34 pm, Davide Rognoni <davide.rogn...@gmail.com> wrote:
> No no, this post is for all: "Having doubts about AppEngine"
>
> 1) """My concerns center around Google’s commitment to the App Engine
> project"""
>
> My concerns center around Google’s commitment to Django template.
>
> 2) """Here on the GAE forum elementary questions about how GAE ticks
> go unanswered for months"""
>
> Also about the template system.
>
> 3) """Communication with the developer community here is abysmal
>
> Django is free, no investment.
Mike Orr
<davide....@gmail.com> wrote:
>
> Not Google but:
>
> "Guido just pronounced: Django is the [Python] web framework
> http://www.cmlenz.net/archives/2006/08/the-python-web-framework
Note that that was written in 2006. Since then the frameworks and
template engines have remained pretty much in their same relative
positions. An exception is Mako, which I think was first released
around that time and has now become one of the frontrunners for
non-XML-style templates. Jinja also appeared, which I think has a
Django template-like syntax.
In order for Django and TurboGears to merge, one of them would have to
give up its founding philosophy.
--
Mike Orr <slugg...@gmail.com>
Michael Schreifels
On Aug 30, 2:34 pm, Davide Rognoni <davide.rogn...@gmail.com> wrote:
> 2) """Here on the GAE forum elementary questions about how GAE ticks
> go unanswered for months"""
>
> Also about the template system.
a part of the Django project? The Django project has a HUGE developer
community. Try #django on irc.freenode.net or the django users mailing
list. As long as the question sticks to Django-related issues that
aren't affected by AE (such as the templates), I guarantee they would
be happier to help, and much more responsible than this mailing list.
> 3) """Communication with the developer community here is abysmal
>
> Django is free, no investment.
1. Yes, Django is free (open-source).
2. No, there *is* an investment in terms of time (and thus money)
3. I think you mean App Engine, not Django...
Again, Django != App Engine
Noah Gift
Additionally, the appengine is a whole new ballgame, so perhaps some
ambitious person, young or old, will read this tutorial:
http://pythonpaste.org/webob/do-it-yourself.html
And write their own appengine specific web framework that becomes the
defacto standard for appengine. Who knows, maybe writing
webframeworks will become like the Olympics, and every four years a
new champion has a chance to win the Gold medal. Of course it would
be nice if whoever did this did so in a way in which existing
libraries and work from other frameworks could be reused and or
integrated....
>
> --
> Mike Orr <slugg...@gmail.com>
Michael Schreifels
> Not Google but:
>
> “Guido just pronounced: Django is the [Python] web frameworkhttp://www.cmlenz.net/archives/2006/08/the-python-web-framework
FYI if you listened to Guido's talk on building Django apps on AE at
Google I/O this year, he said that "Django is just one of many
frameworks you can use." The talk is available online.
On Aug 30, 4:40 pm, Davide Rognoni <davide.rogn...@gmail.com> wrote:
> fromhttp://www.cmlenz.net/archives/2007/06/logic-in-templates
>
> """How could a custom, sparingly documented, somewhat inconsistent,
> and mostly unproven (compared to Python) mini expression language be
> any better for template authors?"""
I wasn't using Django over a year ago when that was published (just
think: that was when oldforms was still in, eeek), but I will say one
thing: out of all of the frameworks and libraries I have used, Django
is THE best documented web framework I have ever come across. Also,
that quote is comparing how proven an entire language is to a mere
collection of template tags and constructs...
> """In my humble opinion, this kind of “dumbed-down” templating results
> in only one thing: more lines of code in the application modules,
> lines of code that are really only about presentation, and should be
> in the templates. And frustration every single time you need to add
> those lines."""
So Django templates aren't for everyone. Django was designed to be
loosely coupled so you can stick in your own preferences where
desired.
On Aug 30, 4:05 pm, "Noah Gift" <noah.g...@gmail.com> wrote:
> I think for new comers to Python, it IS presented as the only choice
> as many people would have difficulty "monkey-patching" another
> template engine, as there have been issues in getting, to my knowledge
> at least, Mako and Genshi to fully work on appengine. It seems like
> this new cookbook area would be a good spot to for developers of those
> other templates to put their integration recipes:
my designers to access PHP, I could certainly choose to use a template
language. But of course, it is going to involve overcoming a barrier
to implementation. Django templates works great for most people. For
those who it doesn't work for, they should be prepared to have to do
some extra work. Besides, for beginner's needs, what exactly is it
that Django templates doesn't work for?
Django templates is incredibly newbie-friendly. As mentioned, the
documentation is (IMO) second-to-none, and there are other great
resources, like the free talks available online covering Django, and
djangobook, which is mostly up-to-date.
But still, I don't think this conversation is the appropriate place
for this discussion.
Noah Gift
>
> On Aug 30, 4:25 pm, Davide Rognoni <davide.rogn...@gmail.com> wrote:
>> Not Google but:
>>
>> "Guido just pronounced: Django is the [Python] web frameworkhttp://www.cmlenz.net/archives/2006/08/the-python-web-framework
>
> So what? Guido likes Django... http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/
>
> FYI if you listened to Guido's talk on building Django apps on AE at
> Google I/O this year, he said that "Django is just one of many
> frameworks you can use." The talk is available online.
I was at Google I/O and attended that talk. Yes, I think that is a
great goal for the Google App Engine team, but it is currently not a
reality. I hope this can be addressed soon, as personally I feel it
is one of the biggest issues facing the project. There are many
incredible tools from other frameworks and applications like say,
MoinMoin, that could benefit from a more complete version of Python.
At the very least the documentation should be updated to state that it
is the goal to support other frameworks than webapp.
>
> On Aug 30, 4:40 pm, Davide Rognoni <davide.rogn...@gmail.com> wrote:
>> fromhttp://www.cmlenz.net/archives/2007/06/logic-in-templates
>>
>> """How could a custom, sparingly documented, somewhat inconsistent,
>> and mostly unproven (compared to Python) mini expression language be
>> any better for template authors?"""
>
> I wasn't using Django over a year ago when that was published (just
> think: that was when oldforms was still in, eeek), but I will say one
> thing: out of all of the frameworks and libraries I have used, Django
> is THE best documented web framework I have ever come across. Also,
> that quote is comparing how proven an entire language is to a mere
> collection of template tags and constructs...
Let me preface that I use Django for many projects and I like it for
certain things. Please don't take offense anyone at my view about
flaws in Django:
This is an excellent argument actually. Why reinvent Python and keep
making special cases like threaded comments each time a new flaw in
the template design is found? This actually violates the "Zen of
Python", http://www.python.org/dev/peps/pep-0020/. Of course we can
take this discussion offline.
This is a very valid point against Django templates. Reinventing constructs
>
>> """In my humble opinion, this kind of "dumbed-down" templating results
>> in only one thing: more lines of code in the application modules,
>> lines of code that are really only about presentation, and should be
>> in the templates. And frustration every single time you need to add
>> those lines."""
>
> So Django templates aren't for everyone. Django was designed to be
> loosely coupled so you can stick in your own preferences where
> desired.
This phrase, "Django was designed to be loosely coupled", is another
complaint I have against Django, and something I frequently hear.
What does this mean? In my opinion Pylons is loosely coupled:
http://pylonsbook.com/. Django does not do things that I feel are
loosely coupled, like documenting in a published book or official
documentation how to use third party components such as SQLAlchemy,
Jinja, or setuptools. Almost every alternate popular framework
supports directly, with copious official documentation, setuptools:
http://peak.telecommunity.com/DevCenter/setuptools, and SQLAlchemy:
http://www.sqlalchemy.org/. Here are a list of alternate frameworks
in Python that people might reference:
Zope 3: http://www.zope.org/Products/Zope3
Grok: http://grok.zope.org/
Pylons: http://pylonshq.com/
Turbogears2: http://turbogears.org/2.0/
Werkzeug: http://werkzeug.pocoo.org/documentation/tutorial/
All of these support in their documentation setuptools and SQLAlchemy
and are in my opinion loosely coupled. Loosely coupled means
different things to different people and it is marketing terminology
that Django should probably drop, as it is false.
>
> On Aug 30, 4:05 pm, "Noah Gift" <noah.g...@gmail.com> wrote:
>> I think for new comers to Python, it IS presented as the only choice
>> as many people would have difficulty "monkey-patching" another
>> template engine, as there have been issues in getting, to my knowledge
>> at least, Mako and Genshi to fully work on appengine. It seems like
>> this new cookbook area would be a good spot to for developers of those
>> other templates to put their integration recipes:
>
> If I wanted to work with PHP and didn't like the fact that it allowed
> my designers to access PHP, I could certainly choose to use a template
> language. But of course, it is going to involve overcoming a barrier
> to implementation. Django templates works great for most people. For
> those who it doesn't work for, they should be prepared to have to do
> some extra work. Besides, for beginner's needs, what exactly is it
> that Django templates doesn't work for?
Again please reference this URL for many examples:
http://jjinux.blogspot.com/search?q=django+templates
My own example is nested hierarchical relationships from the model.
>
> Django templates is incredibly newbie-friendly. As mentioned, the
> documentation is (IMO) second-to-none, and there are other great
> resources, like the free talks available online covering Django, and
> djangobook, which is mostly up-to-date.
>
> But still, I don't think this conversation is the appropriate place
> for this discussion.
I just wanted to make sure, that your statement "You don't understand
how Django templates work" was properly addressed and Google
searchable, as it was not a valid argument against why Django
templates don't support Python logic. I would protest against this
common meme I hear about Django templates that if you don't like them
then you don't understand how they work. In many cases they have
severe design flaws, which are impossible to address without adding
Python back into the template, or adding one off hacks and weird
special cases which the official django template documentation if full
of. Again, this is my opinion. Feel free to contact me offline for a
more detailed answer anyone.
Sylvain
googleappengine/issues/list) with a "real" status (accepted, refused,
duplicated,...)
Currently, most are in "Defect" status even real major bug.
There are about 700 issues. They have to be updated.
This is part of the roadmap.
On 28 août, 02:58, Dado <edoardo.marc...@gmail.com> wrote:
> I also agree completely!!! Lack of roadmap and GAE team feedback is a
> very serious issue!!!
> On Aug 27, 3:09 pm, javaDinosaur <jonathan...@hotmail.co.uk> wrote:
>
> > I am starting to have doubts about continuing to develop my
> > applications for GAE. My concerns are not technical although I have a
> > some anxieties about transaction data propagation performance.
>
> > My concerns center around Google’s commitment to the App Engine
> > project. Compared to Amazon’s Web Service forums this place feels like
> > a technical backwater. Developers hosting on Amazon AWS post
> > interesting questions and get deep-dive replies promptly from Amazon
> > staff. Amazon is releasing new Cloud development services monthly yet
> > all we get is minor patches.
>
> > or scheduled tasks is missing.
>
> > I just feel that the GAE Team is not building up any development
> > stream in what should be the last 4 month run up to the year-end
LH
at all.
The most of the posters here should take a look at the no. 1 php
template engine: Smarty
http://www.smarty.net/
Take the documentation of the template syntax, you will see that
Smarty and Django Template are very similar, so similar that I wrote
my first (not so simple) django template without even look at the docs
of django.
I'm not sure which system comes first [but I heared that it was smarty
one time], django templates or smarty, but who ever was second knows
the other one while planning its own solution.
So a lot of php and python developers have a nearly identical handling
of templates in there projects.
Michael Schreifels
to show that if you do something different from the "default", no
matter what language and platform you are developing for, there is
always going to be extra work involved.
And for the record, Smarty has been around several years longer than
Django.
On Sep 1, 3:23 am, LH <shockflashm...@googlemail.com> wrote:
> I'm a little bit confused about the discussion php vs django template
> at all.
>
> The most of the posters here should take a look at the no. 1 php
Noah Gift
>
> The point wasn't to compare Smarty and Django Templates, it was just
> to show that if you do something different from the "default", no
> matter what language and platform you are developing for, there is
> always going to be extra work involved.
Unfortunately, for Google, they chose a default Template, Django, that
is fairly controversial to many people, and then they incorrectly
documented that other web frameworks, such as Pylons work, yet didn't
test this statement. Unfortunately, as a result, this has the
potential to become a flash point of criticism. Forget getting other
language support, how about just getting most of Python to work!
If I was a member of the marketing staff, I would have pursued a
strategy that ensured that defaults for appengine didn't lock you into
an ultra orthodox view of web development like Django Templates take.
By ultra orthodox I mean handcuffing the templates so you cannot
insert Python code in them. Instead I would at the least have
included two templates, or actually done my homework and tested that
another web framework really worked before claiming it did. This is
unfortunate, as now there is already some dissent among established
Python programmers:
http://spyced.blogspot.com/2008/08/app-engine-conclusions.html
I am optimistic Google will eventually address this and work to
support the incorrect language they currently have in their
documentation:
http://code.google.com/appengine/docs/gettingstarted/usingwebapp.html
>
> And for the record, Smarty has been around several years longer than
> Django.
>
>
> On Sep 1, 3:23 am, LH <shockflashm...@googlemail.com> wrote:
>> I'm a little bit confused about the discussion php vs django template
>> at all.
>>
>> The most of the posters here should take a look at the no. 1 php
>> template engine: Smartyhttp://www.smarty.net/
>>
>> Take the documentation of the template syntax, you will see that
>> Smarty and Django Template are very similar, so similar that I wrote
>> my first (not so simple) django template without even look at the docs
>> of django.
>>
>> I'm not sure which system comes first [but I heared that it was smarty
>> one time], django templates or smarty, but who ever was second knows
>> the other one while planning its own solution.
>> So a lot of php and python developers have a nearly identical handling
>> of templates in there projects.
>>
>> On Aug 31, 12:36 am, Michael Schreifels <tech...@gmail.com> wrote:
>>
>> > If I wanted to work with PHP and didn't like the fact that it allowed
>> > my designers to access PHP, I could certainly choose to use a template
>> > language. But of course, it is going to involve overcoming a barrier
>> > to implementation. Django templates works great for most people. For
>> > those who it doesn't work for, they should be prepared to have to do
>> > some extra work. Besides, for beginner's needs, what exactly is it
>> > that Django templates doesn't work for?
> >
>
--
Noah Gift
http://noahgift.com
Bill
> strategy that ensured that defaults for appengine didn't lock you into
> an ultra orthodox view of web development like Django Templates take.
> By ultra orthodox I mean handcuffing the templates so you cannot
> insert Python code in them.
frameworks, I'd rather the core AppEngine team implement features the
rest of the community would have great difficulty implementing. I
don't consider templates a difficult piece of the pie. I'm a relative
python newbie and if I had a little more time and motivation, I'd
create a version of Haml (template system out of Ruby world that uses
pythonic indentation for clarity) that allows embedded python. As far
as I can tell, there's nothing preventing any of us from creating such
a framework because evals aren't sandboxed.
I haven't created that template system (yet) because I find Django's
templates sufficient. Yes, I run into the python embedding issue
sometimes, but there are ways to work around it and Django does
provide a nice number of filters and a tailorable template system.
There's a difference between things the community can build on the
existing framework and things Google probably has to do themselves,
like https support, cross-app datastore access, and relaxing the
sandbox or securing important packages like full PIL support. Stuff
we can't do as a community should take priority.
Noah Gift
> frameworks, I'd rather the core AppEngine team implement features the
> rest of the community would have great difficulty implementing. I
> don't consider templates a difficult piece of the pie. I'm a relative
> python newbie and if I had a little more time and motivation, I'd
> create a version of Haml (template system out of Ruby world that uses
> pythonic indentation for clarity) that allows embedded python.
Hmm, the docs look interesting. I would give it a try if you ported
it to Python. It looks pretty cool, plus it is used as the default by
Merb, which seems to be stealing a bit of the Rails thunder I hear.
Bill
> > ... if I had a little more time and motivation, I'd
> > pythonic indentation for clarity) that allows embedded python.
>
> Hmm, the docs look interesting. I would give it a try if you ported
> it to Python. It looks pretty cool, plus it is used as the default by
> Merb, which seems to be stealing a bit of the Rails thunder I hear.
(http://lucumr.pocoo.org/cogitations/2008/05/31/the-new-ghrml-haml-for-
genshi/) you can try out on App Engine. It requires Genshi. If
Django bothers me enough, I might try it out. Still, it feels like
it's a port and not fully exploiting the natural fit with the python
language.
Jorge Vargas
I am starting to have doubts about continuing to develop my
applications for GAE. My concerns are not technical although I have a
some anxieties about transaction data propagation performance.
My concerns center around Google's commitment to the App Engine
project. Compared to Amazon's Web Service forums this place feels like
a technical backwater. Developers hosting on Amazon AWS post
interesting questions and get deep-dive replies promptly from Amazon
staff. Amazon is releasing new Cloud development services monthly yet
all we get is minor patches.
Here on the GAE forum elementary questions about how GAE ticks go
unanswered for months. Basic roadmap type info such as will we get SSL
or scheduled tasks is missing.
I just feel that the GAE Team is not building up any development
stream in what should be the last 4 month run up to the year-end
release. Communication with the developer community here is abysmal
compared to the investment in developer relations made by companies
such as Microsoft, Redhat or Amazon.
What's happened to the early buzz Google? Has the top bass pinched
half the team to firefight problems on another project?
I have to agree with the original poster, I assumed that by now we should have had the paid service and the much waited ssl. We need a real commitment from gae team so things here can jump from hobby to business, and by business I don't mean we are going to move all our companies infrastructure to GAE, but that small projects that have a good future could think of it as what it proposed in the first place http://sites.google.com/site/io/building-scalable-web-applications-with-google-app-engine
Jorge Vargas
Doubts about Django Template
http://groups.google.com/group/google-appengine/browse_thread/thread/3503204aed78e934#
Django templates are one of the ways of doing templates, some of us don't like them because of the restrictions they impose, others have build their own. All in all the limitations imposed to other templating engines by the GAE infrastructure have some people look away from it.
Therefore (and for the record) keep in mind we DO understand django-templates, we just think they have a (couple) of bad design decisions on them, which is why we prefer other templating engines which aren't supported yet.