On 4 Okt., 09:32, Christoph Zwerschke <[email protected]> wrote: > Some suggestions: > > * Model and controller show the file names in a quickstarted project. > View should als mention /templates (maybe even indicate master/page > templates). Static ressources belong in a separate box IMHO.
Maybe I could put the static resources outside the blue TurboGears box and draw arrows between them and CherryPy and the web server box. My idea was to express that the view not only consist of the HTML output, but since the application needn't care about how they are delivered, it might not be right to put them into the view box. > * It looks like the return value of the controller is the rendered page > which is not true and can confuse new users. The old picture showed the > work flow up to the final response better, including the JSON shortcut. In my view, JSON isn't really a shortcut. To me, TurboJson is a template engine like all others (and technically it true). It's true that the view template output isn't passed back to CherryPy by the application's controller methods, but it is still post- processed by TurboGears controller layer (i.e controllers._process_output etc.). I don't have these layers in the diagram, because I didn't want to clutter it with too many details. I tried to express this by the fact that the grey arrows pass through the turquoise application and the blue TuboGears background boxes, but obviously that isn't clear enough. Maybe I should make the upward grey arrow turn right to the view boy fist and then add another from the view box to CherryPy. Unfortunately that doesn't seem to be so easy in OpenOffice... > * I would not label SQLAlchemy as "database adapter", but as ORM & SQL > tookit, since it can be confused with the DBAPI2 adapter which should be > visible as small separate layer between SQLAlchemy and the Data Storage. I didn't want to add another box there, the diagram is already almost too full. That SA+SO are using the DBAPI2 to talk to the database is a technical implementation detail that is irrelevant her, IMHO. Other data storage adapters may have other lower layers. I can rename the box though... > * Widgets are not in the picture though they are an important part of > TG. I remember I missed them also in the old picture. And since this is > about TG1, I would also show MochiKit (connected with widgets). I left out widgets and MochiKit, because they are entirely optional. Of course, most TG1 applications use them, but you can build apps without them. Also, to be honest, I think the interaction of Widgets with the request, the request filters, the error handler etc. is too complex (and I'm not sure, if I have fully grasped it!) to put in here. It's called "The Big Picture", because I wanted to show, how things work in general. A long time ago, Mark (or Alberto?) did a diagram that showed the flow of data when using widgets. It's still attached to this wiki page: http://docs.turbogears.org/1.0/DocSprintOrganization. Unfortunately, it's done in OmniGraffle, a non-free OS X-only program, and the SVG export does not render nicely for me. But I think a separate diagram for the Widgets and AJAX topics is a better solution than cluttering up the big picture too much. Thanks for for your comments, if you want to try and improve the diagram, please go ahead. I will change the two things mentioned above, when I have time. Chris --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
