Wow, Mike, that was a super helpful reply with a lot of great info, thanks a lot!! I wrote you a reply on my notebook from the livingroom (trying to make xmas compromises ;) ) which was coredumped by opera on the last <P>. Argh. I'll be a little more brief with this one.
> Your source may be talking more about Django's origin than what it's > intended for now. I dabbled for a few hours with it yesterday, and that totally confirms your statement. I even had basic authentication and sessions support up within 2 hours, which made me quite optimistic. Also, important to say: My statement about the project prbly made it seem bigger than it is. The client will be the sole seminar speaker, there will only be one type of seminars to book, even though there will probably be about 50 per year with a total of about 200 registrants. As he is client and speaker and knows the timeframe is short, he would probably be able to work with Djangos integrated admin tool for the seminar maintenance. > For authentication, the quickest choice would be a homegrown database > of (A) username, (B) password, (C) list of seminars they're "admin" > for. Then if their credentials match a database entry, set a login > flag in the session. I was pretty surprised about managing to get some user accounts and authentication/session functions up in such a short time in Django yesterday. I think (and was confirmed by ppl on the IRC) that I could prbly just attach my own user info to the Django user table and leverage the built-in functions like that. I was also happy to find an integrated extended stacktrace / semi- debugger in Django, something that I liked a lot about Pylons. > that means TG 1 if it works for you. I think the app will be small initially, but probably grow over time and might live for 3 or 4 years total. I would hate to have to redesign it to work with TG2 eventually or maintain a very out-of-date TG1 environment. That sounds like a pretty big point against TG. I dislike the intellectual investment in old tek, too. Thank you for confirming the in-flux state, I thought I was just not getting things, but your explanation seems to fit a lot better! > authorization. if you want a calendar look, that'll be another hurdle > to find or make a suitable widget. Point taken; I'll keep all the eye candy out for the initial release, which I think the client will accept. > (Webhelpers + Formencode) > they have a small learning curve and are less likely to fail at the > last moment. Hmm. I experimented with only-CherryPy for one afternoon and was totally lost in the end. Maybe I picked the wrong cherry off the frameworks? It made me afraid of using standalone helper libs, though. WIth an integrated framework, things of course get more complicated, but it seems documentation can over-compensate that. My impression is Django leads in that respect. Do you agree? > curve, so you may want to avoid it for this app. I don't know about > TG's and Django's authorization schemes. (see above re Django) > That's a lie. :( TG 2 is being built on top of Pylons, but Pylons > itself is not changing. In any case, Pylons 0.9.6.1 is stable. I'm Thanks for the correction! No idea where I had the false info from. > Three weeks is really tight to build such an ambitious application in > a new environment. That gives just one week to get up to speed with > the framework and decide your basic design, one week to implement it, > and one week to beta test and debug. True. Thanks a lot for that meta-structure, that cleared up the picture a lot for me. I will probably throw some extra coffee, shorter nights and no-sparetime phases into the mix; or at least be prepared for it. > to be perfect in terms of authentication and calendar features, so > they'll do just exactly what you need, right now, with little learning > and no errors. I'm not sure if any of the frameworks are up to that > yet. The calendar stuff might be simple enough to handle it with pythons built-in datetime delta. My dive into Django made me optimistic about the auth functions. I hope I will not regret that optimism ;). > has its own everything else. That's a potential minus in terms of > interoperability, which is why I don't use Django. But for just > getting a self-contained app out the door quickly, it may be OK. That's exactly why I chose to dive into it first. I'll have to advance my "show stopper" assessment to put it to the test regarding that. Maybe then, I'll have a go with it. Probably with the assumption "it is so widespread, I assume it can do everything I absolutely need, I'll need less time for choosing components (b/c there are not many to choose from) and if I should have any time left, I can try to get the nice looks that TG / Tosca would give me ootb hand-crafted." > A showcase demo in 6-7 days is certainly feasable, given that "limited > functionality" can mean anything. I though "limited" like that: Probably without users self-registering, using a built-in admin frontend and with no visual design. Just a list of dates to register for, checking if it's less than X days before the start to unregister and checking seminars don't get more participants than they have room. > first: try to get as much of the registration flow into the demo, then > worry about authorization, a pretty look, and email verification. The client hasn't even realized (and calculated paying for) he will need email verification. Due to the semi-internal nature of the seminars he might even be right, but my guess is he'll realize he needs it after the initial live tests have passed. > I'd check into Durus for a database. Unless you're well versed in > SQLAlchemy and relations, it'll be time consuming to set up your > tables and debug your database code I'll check out Durus - never heard of it, but it seems like thats a big error on my part! I have, however, worked 400+ hours with SQL using VBA for MS Access before (and 50+ with pysqlite), so I'm not that scared of SQLA. Do you think I should be? > dicts/lists/objects. You'll need Durus's server mode because multiple > requests will be modifying the database, and don't share database > connections between threads. A seminar app sounds like a small amount > of data that can all fit in memory, and Durus would just take care of > persisting it and versioning it. So it has a "concurrent modification" mode? That would be the main reason for using some SQL-based server indeed, which that might eliminate. I'll look at it today, I might use it in some other projects of mine at least. Thanks again, Mike, for getting me many steps further in my decision process and also for letting me know how "ambitious" the timeframe is! Nico --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
