Aaron, I see you've been trying to solicit some feedback on WHIFF, so ... let me briefly give what's intended as constructive criticism. I began reading the docs on WHIFF and was immediately taken aback. In general, it's really unclear to me what kinds of problems WHIFF is trying to solve and how the framework you've developed makes web application development easier.
Now, just concerning the proposed problem: > The primary tools which reduce complexity are > an infrastructure for managing web application > name spaces, a configuration template language > for wiring named components into an application, > and an applications programmer interface for > accessing named components from Python and > javascript modules. > When you say "an infrastructure for managing web application name spaces," I think of three major namespaces one would need to manage in the context of web applications: application level namespace, template locations and REST namespaces. The first is already solved by Python - Python gives you namespaces, done! The second is solved by most popular templating engines - genshi, mako, jinjia, django templates - done! The third is solved easy with routes libraries such as werkzeug's (http://werkzeug.pocoo.org/documentation/routing) and other approaches like twisted web's resource trees (http://twistedmatrix.com/projects/web/documentation/howto/using-twistedweb.html#auto4) - done! So I'm not really understanding why you need something else to manage namespaces or how your new solution is better than already existing approaches. Now, on the subject of "Whiff is cool because: How do you make a page like this using another package?" (http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool) I'm really failing to grasp what's so awesome about that page. It's easy for me to write a web application using werkzeug, twisted.web, pylons etc without using an SQL database - I can't think of many web application frameworks that demand I do. Why are you claiming WHIFF is special in this regard? whiff.is.cool> "In production deployment the documentation components use files in directories to record CAPTCHA data and page comments. " Most applications in production environments are deployed on multiple nodes behind a load-balancing front-end (nginx, apache, etc), so your filesystem-only database model will break down pretty quickly. Not only to mention reads are going to screech to a halt as you start storing more and more files. That's one reason to use a databases - to avoid those IO bottlenecks. whiff.is.cool> None of the features used on this page are defined on this page -- they are all "imported" using other middleware scaffolds and fragments. This is equivalent to saying: "Nothing inside this module is defined in this modules - it's all imported from other modules." Nothing ground-breaking there. And again, you're describing features (includes, macros, etc.) already well supported in other templating libraries. Why aren't other templating libraries working for you in this regard? Have you even surveyed the available options? whiff.is.cool> This page also included syntax-highlighted code fragments created by the Pygments syntax highlighter. In the browser the fragment looks something like this Is the document about why whiff is cool or why the page is cool? There's nothing special about being able to use pygments. I can use pygments easily in any python web framework. You haven't convinced me that WHIFF makes this easier somehow. Next on the cutting block: Resources! (http://aaron.oirt.rutgers.edu/myapp/docs/W1000_1000.resources) resources > WHIFF configuration templates must access resources via the resource configuration provided for the application. This prevents configuration templates from accessing or modifying data not accessible through the interface. Are try to implement your own security layer? Have you studied security much? It's not something to take light-heartedly. Most web frameworks don't attempt to solve these problems natively but defer to external security mechanisms: SSL, LDAP authentication etc. resources > {{use-url "whiff_middleware/getResource"}} ["datafile", "secretpassword"] {{/use-url}} Dude, that's not security ... http://en.wikipedia.org/wiki/Dictionary_attack. It seems what you're trying to accomplish in the example is a server-side forward, where the solution to the problem is much simpler than what you're attempting. Finally, a general note on the approach you're taking in WHIFF's configuration templating framework referenced here (http://aaron.oirt.rutgers.edu/myapp/docs/W1200_1200.config_template). It seems you're defining some higher level semantic markup that generates HTML - I think. If I'm interpreting this right, you should be very careful about doing this - it's not an easy task to undertake and you'll run into serious issues if you work in an environment where HTML designers need to work with templates, or provide mock pages you build templates from. Also, the presence of (many) state diagrams to show how a response is pieced together doesn't really abide by the "reduced complexity" you're claiming in the introduction. Anyhow, I'll stop. I could go on, but it's exhausting. I wanted to respond because I'm so afraid that someone you work with will have to use WHIFF and they'll end up having a nervous breakdown. You really don't want to make anyone use WHIFF. Please take a closer look at the other available options: wekzeug, django, pylons, turbogears, grok, twisted.web .... the list goes on. Most of the existing Python web frameworks and libraries already solve all the problems you've described and much more. Regards, Drew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pocoo-libs" 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/pocoo-libs?hl=en -~----------~----~----~----~------~----~------~--~---
