[04:51:41] ** thinkeryzu has left IRC (Remote closed the connection) [05:22:39] ** thinkeryzu has joined us [05:27:47] [connected at Sun Dec 16 05:27:47 2007] [05:27:47] <> *** Looking up your hostname... [05:27:47] <> *** Checking ident [05:27:47] <> *** No identd (auth) response [05:27:47] <> *** Found your hostname [05:27:47] <> *** Your host is clarke.freenode.net[clarke.freenode.net/6667], running version hyperion-1.0.2b [05:27:49] [I have joined #peak] [12:38:21] ** blackthorne_ has joined us [12:38:32] hi [12:39:04] anyone? [12:41:47] i wanted to understand PEAK a little more in depth from what i got from the website [12:45:51] i am looking for a web kit that to develop webpages in a lower lever but simpler way than common frameworks like Django and TG [12:47:09] before i try to develop something like this i really want to find out if PEAK already doesn't perform that behavior or close [13:12:47] ** FunG07 has left IRC (Remote closed the connection) [13:57:19] blackthorne_: did you take a look at all the wsgi things out there ? [13:59:58] http://werkzeug.pocoo.org/ for example [14:02:42] thats my favorite :) [14:03:17] hmm - is there any working version of trellis.db ? [14:12:03] well, seems interesting but i think that doesn't give me all that i need [14:12:53] which is ... [14:13:13] in detail, SESSION vars, Apache support, AJAX frameworks integration for free (Mootools and scriptaculous) and SQL Alchemy integration [14:13:53] though i could use that to build something bigger that gave that [14:14:04] You said low-level, so either you need to revise something or you are wrong about "low-level" [14:15:23] werkzeug has apache support and sessions, and sa is easy to integrate ( 10 loc) [14:15:39] no AJAX integration though [14:15:47] thats very much not a simple feature [14:16:09] lately, i've been working with Django, TG and Zope [14:16:22] that's why i call it low level [14:16:54] And I'm saying you don't want a low-level framework from what you just said [14:18:45] blackthorne_: all the stuff you want make it really high level [14:19:15] you just said werkzeug has support for most of them [14:19:43] only AJAX is missing [14:19:46] it has support for Apache, but then all WSGI compliant system do (most of them) [14:20:06] the only feature you mention it supports really is sessioning [14:20:19] DB access is orthogonal to the HTTP layer [14:20:31] which is again orthogonal from HTML output [14:21:55] the way i see it, having AJAX support is a "must" for this kind of things [14:22:03] why ? [14:22:26] werkzeug can form the controller section of a DIY framework, you are welcome to use SA for models or anything else you so desire [14:22:41] because, that's what makes web so powerful today. More than anything else. [14:22:53] most of my apps are mainly web services with rest - any stupid ajax helper would be useless [14:23:02] AJAX stuff requires longitudinal coordination between all layers of the framework, something you don't get in a DIY system [14:23:34] i believe you, so are mine. But not most of latest successful web apps you probably use today [14:24:06] blackthorne_: ajaxhelpers usualy get in the way for anything powerfull anyway [14:24:09] at least me and most of people: Flickr, Gmail, ... [14:24:11] blackthorne_: Move over to #trac and ask us what we think of AJAX ;-) [14:25:34] i respect you and your opinion. That won't change the importance and the impact of AJAX [14:26:11] Nor will it change your assured failure when people realize gimmicks can't make a bad website more useful [14:26:32] G*, Flicr, etc are first good tools and second AJAX enabled [14:27:00] I would worry about getting the good site first, then hit it with the AJAX stick [14:27:45] AJAX goes a little beyond than eye-candy gimmicks. You know that [14:28:28] Not if you use good design up front, there is nothing that can be done with AJAX that can't be done without except make the site a little faster due to having less page loads [14:28:50] little... [14:29:26] its much faster [14:29:41] not just "little" faster but also updated [14:29:42] still - the standard stupid ajax helpers are usualy not usefull at all [14:29:44] and like I said, speed will not make quality [14:30:20] all of the sucessfull big sites are nit based on those :) [14:30:37] it's not speed only. It's a synchrony client-server in both ways and not based in page requests only [14:31:13] That is incorrect [14:31:22] that's powerful. I agree with you up to the rest: not that important [14:31:27] There is nothing that can be done with AJAX that can't be done without it other than speed [14:33:53] be more precise, are you talking about having a META tag in HTML with HTTP-EQUIV set to refresh and Content="2" to check if every 2 seconds there as been an update? [14:34:36] If you need continuous refreshes, sure thats an option [14:34:56] you may be messing with the logic of your application [14:35:21] if you update the whole page instead of the single part [14:35:28] that you need to see updated [14:36:01] Sure, it requires good design from the start [14:36:41] What i just said is a very lousy and hopeless work-around that doesn't work for all situations because as i told, they are different concepts. [14:37:45] huh? [14:37:53] Anyway, just for the record, i never felt need to use AJAX [14:40:20] coderanger: one thing doesn't replace the other, that's what i am saying [14:40:55] That is wrong, everything done with AJAX can be replaced with non-JS techniques [14:41:10] and should be to start with [14:41:44] coderanger: maybe with Java Applets and Flash. [14:41:49] Nope [14:41:59] HTML+HTTP [14:43:06] so for you, that META tag may replace in all situations the AJAX advantage for updating single parts of a page without having to build a new page request? [14:43:26] If you need to do that without submitting a form or clicking on a link, yes [14:43:57] however thats generally the minority of the cases, general UI paradigms dictate that the page should only change in response to a user action [14:44:16] in the case of HTTP that means a GET or POST, the server can change the page sent back in response [14:45:19] having the page update without user intervention generally only makes sense for visualization screens, which are a whole 'nother difficult issue [14:46:31] if i want to have a webmail that i want to be updated and to include an hit counter provided by an external source that generates statistics for me [14:47:11] i don't want to bring examples because they can fail [14:47:29] a webmail inbox is a visualization screen for your email, so yes, auto-refresh would be appropriate [14:47:32] anyway this example seems good enough [14:47:46] auto-refresh would mess with the hit counter............... [14:48:21] it certainly would, good thing my hit counter of choice understands how to group hit vs. visits [14:48:25] and most do [14:48:40] hit counter is a different concept from visit counter [14:49:26] they provide different types of information [14:50:05] if i want to know how many times i need to hit my page by visit to test my Webmail UI [14:50:25] that scheme would make my test useless [14:50:47] So yes, if you have a stupid hit/visit counter I agree, that would be a problem [14:51:00] guess which problem I would fix? :) [14:53:41] An useless example, maybe... i remind you, that was just an example to prove you that you can't do everything you do in AJAX with just HTTP+HTML. [14:54:12] And I showed how you can [14:57:55] Your hit counter of choice doesn't distinguish what updates have been by you or by your browser [14:58:08] ajax is just a ui improvement - everything can be done with http+html [14:58:51] *updates/hits [14:58:58] blackthorne_: Sure it can, put an argument on the auto-referesh URL [14:59:10] if the tag is there, you know it was an autorefresh [14:59:38] also ajax ui stuff isu ALLWAYS more complex than the ajax helpers can manage, so you have to roll it yourself, thuss you dont want to clutter your framework with it [14:59:59] we are talking about different things [15:00:14] i am not arguing on the advantages of AJAX for the UI [15:00:16] yeah - probably [15:00:28] I agree that in most cases AJAX is useless [15:00:53] imho your examples are bad ;P [15:01:02] i just gave one [15:01:12] and it hadn't to do with UI [15:01:46] yeah - but its good solvable with html, too [15:02:08] i don't think so [15:02:26] Then you think incorrectly [15:02:43] also all ajax counters wont work on my boxes [15:02:45] you update the whole page you mess with the logic of your application in a different way of updating a single part of it [15:03:11] blackthorne_: a get will never break important data, else the app is really broken [15:03:19] It isn't "messing" if you design it to work that way [15:05:12] if you only need to update a part of the page, you don't want to have to worry about how is an full page update going to mess with other parts [15:05:39] So you are saying you are a lazy designer [15:06:46] blackthorne_: a full reload should NEVER break anything [15:07:51] else the app is a failure [15:07:58] judge the way you want. I think any designer wants ALLWAYS to decrease unnecessary post conditions [15:08:04] and the first user with relaod button will show [15:08:35] A GET shouldn't change persistent data [15:09:18] this isn't strictly academic once you start talking about preventing CSRF [15:09:38] by post conditions i am talking about POST to opposition to pre-conditions, not GET & POST methods [15:10:14] blackthorne_: So you are saying that you want to make things easier by not accounting for all possible access scenarios [15:10:29] Which is fine, but also stupid and doomed to failure on the wide world of the internet [15:11:01] no amount of framework will help that [15:11:41] coderanger: no. I am saying that API's that cause undesirable post conditions are bad [15:12:12] such as? [15:13:24] coderanger: updating a single part of the page. Besides, speed messes with quality. With a slower technology you may find limitations on the features you want to implement [15:13:46] blackthorne_: You give me hope that I will always have a job :) [15:16:40] i think you are not getting me the right way. If you did, you understood that unless you change your mind you may have more trouble to find a job as time goes on [15:17:27] blackthorne_: what you say sounds like its ok to have random breakages with odd conditions [15:18:41] while we say breakage is absolutely undesired and should not happen under all conditions [15:19:40] blackthorne_: so - waht do you really want to say ? [15:22:04] blackthorne_: btw - you got a java background by any chance ? [15:22:49] i already said what i wanted. you stated that a "full reload should never break anything." That's a concern you only have when you can't make updates to a single part of the page [15:22:52] ronny: i do [15:23:26] blackthorne_: users can allways manually trigger a full reload [15:24:28] Yeah, that F5 key is tricky [15:24:46] sometimes it moves to the numpad when you aren't looking :) [15:25:03] ronny: yes, so... that really doesn't have to do with what we are talking [15:26:04] blackthorne_: it does - helped us figure there is no frameworks to stop you from reeking of fail [15:26:17] updates by the user have a behavior you can handle with or without AJAX. [15:29:10] ronny: i know what you mean, really. That's not what i am talking about [15:33:50] speed can also cause real limitations on what you want to do [15:34:17] good luck with that [15:34:35] blackthorne_: you still sound like - FAIL [15:34:44] specially on heavy pages that need a single part to be updated very often. You may need to do a big work-around for that [15:34:54] blackthorne_: partial updates and not breaking on full updates is not exclusive [15:35:12] blackthorne_: Yes, if you build your system incorrectly [15:35:28] If you have compute-heavy elements, cache them [15:35:44] all correct systems dont fail [15:38:25] coderanger: btw - how usefull is trellis atm for gui/io/db - didnt track for some time [15:39:00] ronny: you are being rude. And you are also calling failed to an option taken by enterprises like Google and YaHoo [15:39:29] ronny: Haven't played with it much, I mostly use setuptools (trac) [15:39:30] the advantage i was trying to explain is widely recognized and written. [15:39:45] blackthorne_: they didnt take that one - they work failsave on full updates [15:40:07] ronny: Google almost invented it. [15:40:23] google doesnt fail [15:40:57] cause they take the states into account you dont want to [15:41:14] And I'm sure their internal frameworks make it easy to do this [15:41:59] google employs a very large number of very smart people to make this possible of course [15:42:34] coderanger: so it's wise not to call their option - FAIL, don't you agree? [15:42:55] blackthorne_: they take all possibilities into account - unlike you [15:43:04] or do you have to work in Google for AJAX become a wise option? [15:43:04] blackthorne_: thats why you fail, they dont [15:43:11] They are much better at this than you, google services as a rule fall-back fully without JS [15:43:21] ronny: what do you know about my failures? [15:43:27] AJAX is great for enhancing an already good application [15:43:44] coderanger: not fully [15:43:47] blackthorne_: ignoring state coverage - good sign of fail [15:43:49] and it can make for some very nice UIs and user experiences, but it _can't_ make a bad application better [15:44:07] coderanger: you lose some of its advantages [15:44:29] nope [15:44:32] you just need to be good [15:44:40] luckily, many of us are [15:46:18] igoogle is the only service I know of that doesn't fallback [15:46:30] and I know for a fact you can do it [15:48:15] ronny: you missed me. I didn't ignored state coverage. You just didn't understand me so you are offending yourself in the latest understanding. I will repeat the sentence you are missing: if you only need to update a part of the page, you don't want to have to worry about how is an full page update going to mess with other parts [15:48:16] i use gmail from textbrowsers on regular basis [15:48:28] i said want, i didn't said need, do you know the difference? [15:48:53] if you only need to update a part of the page, you don't want to have to worry about how is an full page update going to mess with other parts (this is a repeated sentence, read it slowly) [15:49:26] blackthorne_: Yes, you are being lazy and purposefully ignoring those possibilities [15:49:36] And AJAX allows you to get away with it, congrats [15:50:11] lol. I am not. All i am doing is: [15:50:19] a nice modular design should make this irrelevant of course [15:50:42] -if i want a single part of the page to be updated i do it. [15:50:54] -if i want the full page to be updated, i do it. [15:51:13] Do the internet a favor, leave this to the grownups [15:53:20] lol... you are stuck in the second option and if you find anyone that can do the first you call "get a way with that option". It's an option just like the second one. It has advantages, the ones you don't see but fortunately the grownups you mention like Google, Yahoo, many others do [15:53:21] blackthorne_: you obliviously dont want to take into account, what a user can do [15:53:52] ronny: the user can do updates, so what? [15:54:30] If the refresh button can alter your user experience, you have lost at the game that is web programming [15:55:30] lol, a refresh button is supposed to change your user experience. Normally you don't hit the refresh button just because you want to [15:56:18] if you hit refresh button, page gets fully updated as supposed [15:56:45] if you update a single part of the page with AJAX, page doesn't get fully updated as supposed [15:58:29] if you want update a single part of the page without AJAX, page gets fully updated though it's not intended [15:58:56] which means the AJAX wasn't needed to being with, QED [16:00:00] ew [16:00:49] anyway back to coding [16:00:58] coderanger: i think there is something wrong with your screen [16:01:02] never mind [16:04:53] TurboGears, Django, Ruby on Rails, Zope, Symfony, Code Igniter, all frameworks that support AJAX. All failures ;) . Good thing web development is not stuck into your traumas [16:05:27] Good thing all those support fallback [16:05:27] anyway, good evening people [16:06:13] coderanger: RoR and Zope support falls back.... [16:06:40] still the best failures out there :) [16:06:52] Good luck with that one [16:07:34] do you make part of werkzeug dev team? [16:10:51] no [16:11:08] its just one of the best things for wsgi out there [16:11:58] ronny: i believe you. [16:12:44] I believe, all the frameworks i mentioned have something to learn when it comes to AJAX with you two [16:13:08] wth ? [16:13:33] blackthorne_: i start to belive you really suck at expressing what you really mean [16:13:55] they all adopt AJAX support.. they did it because the probably don't share your opinion about AJAX [16:14:11] the/they [16:14:27] it's not that complicated, if you think about it [16:14:53] Good evening [16:15:22] ** blackthorne_ has left us [16:21:52] ** ronny set the topic to does anyone remember the real topic ? [16:22:44] i was wrong - hes just stupid [16:23:11] that'l happen [16:23:48] he never figured we aktually like ajax for goo stuff [16:23:53] +good [16:24:06] I just like good underlying design even better :) [16:24:23] yeah [16:24:28] good design rocks [16:24:47] makes me wonder if python will ever get a good rest lib [16:25:26] currently we are trying to hack a good rest dispatcher for the server side of werkzeug [16:25:41] but there isnt a client yet [16:26:09] something like ActiveRessource would be nice [16:26:15] heh, I've avoided the web services hooplah so far other than a bit of JSONfu [22:03:35] ** thinkeryzu has left IRC (clarke.freenode.net irc.freenode.net) [22:13:14] ** thinkeryzu has joined us [22:32:21] ** thinkeryzu has left IRC (clarke.freenode.net irc.freenode.net) [22:33:45] ** thinkeryzu has joined us