Hi Rob,

Sorry to hear you returning to PHP for a bit, but I understand the  
need to do what your work requires.

On Aug 8, 2006, at 10:15 AM, Robin Haswell wrote:

> CherryPy
> ========
>
> * It's slow and doesn't allow me the fine-grained control I need  
> for my
> web projects.
> * No obvious easy way to do URL rewriting. And no controller.default()
> doesn't count.

Bob addressed these. First class will definitely have these  
specifically addressed in some fashion.

> * I think the sluggishness is mostly because it's written in Python.
> Also I can't find a good way to let it handle multiple requests at a
> time. I wrote an AJAX in-house tool recently. It aggregates data  
> from a
> website using BeautifulSoup. There's an option to aggregate lots of  
> data
> at the same time, which it achieves by doing lots of XMLHTTP requests.
> CherryPy doesn't seem happy with doing more than 2 processes at a  
> time,
> even with thread_pool increased. There could also be a locking issue.
> I'm pretty sure this isn't related to FF's "max connections/server"
> features - I'm aware of those. I know a similar PHP tool works fine.

I don't think Python is the issue.

> SQLObject
> =========
>
> * I really like SO. Its inteface is great, I wish I could do joins in
> such an easy manner with PHP. However it is just so slow and flaky I
> can't handle it any more. Selecting a list of IDs then selecting each
> row by ID in turn is just unacceptable. REALLY unacceptable. Even my
> project manager has noticed a website is slow because of this.
> * I can't stand how SO will bomb out on UnicodeErrors causing a DOS on
> that page.
> * I also can't stand how if you remove a row from the database that  
> has
> a reference somewhere, SO will raise SQLObjectNotFound whenever it  
> goes
> near that data. My PHP apps don't suffer from this because I write the
> complete three-table inner join in SQL, which will ignore missing
> references (and is a boatload faster). It makes the DB a little messy
> sometimes, but that's nothing compared to DOSing the page with a 500
> error. Updating my CRUD methods every time I associate a new object is
> *not* fun web development.
>
> I know the last point can be solved with using a DB that supports
> foreign key constrains. We use MySQL, there are no PG servers, that's
> just the way of it. I could convert my tables to InnoDB - I probably
> will in future.

SQLAlchemy is the answer here.

> Kid
> ===
>
> * The "NoneType is not callable" bug gets old real fast

I'm actually very impressed with what I've seen of Markup so far. I'm  
hoping to see some kind of combination of Kid and Markup's  
technologies that would put this to rest once and for all.

> Documentation
> =============
>
> Mostly my fault for using 0.9a*, but 0.9a* contains the only features
> which attract me. Nevertheless, no docs is no good, and I need to get
> stuff done *now*

This is definitely being addressed. Improving our state of online  
docs now and ongoing is my current top priority for the project.  
Beyond that, half of "Rapid Web Applications with TurboGears" should  
be available online soon, and all of it is slated to be available at  
the end of October.

> =========================================================
>
> However I will miss some things about TG. Identity is great, top  
> draw on
> that one. I'll have to port it to PHP very soon. I also like widgets,
> very much, although without accurate documentation right now it's
> difficult for me to save time by using them on anything but the most
> basic of forms. I'm sure with time this problem will go away as I
> remember more of the API.
>
> I'm pretty sure I'll come back, probaly when First Class is ready.  
> As I
> understand it, FC will be WSGI (which I think means I can run it under
> Apache without too much flakiness). Also SA support should be properly
> finished, tested and documented by then, which means I can ditch SO. I
> will never use SO until it fixes the way in which it selects data from
> the database. Sometimes slow is just too slow.
>
> Actually I'll probably use TG before then. There are certain  
> classes of
> sites I think TG would be perfect for, but I'll have to think very  
> hard
> about the specific requirements of the site before firing up TG again.
>
> Thanks guys, you're doing a great job.

Thanks for the feedback, Rob. Good luck with your projects, and stay  
tuned here!

Kevin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---

Reply via email to