On Dec 21, 2:50 am, Bruno Desthuilliers <bruno. 42.desthuilli...@websiteburo.invalid> wrote: > mdipierro a écrit : ... > > This means you do not need to import > > basic web2py symbols. They are already defined in the environment that > > executes the models and controllers > > Ok. As far as I'm concerned : show stops here.
Sorry- I don't _think_ I'm following: If you want to write an app all yourself, and use components to put it together, that's fine - more control, and more responsibility (e.g. watch for security, etc.). But most web applications simply do not require or justify this much effort spent on this level of "responsibility"; but maybe I'm missing something less obvious that you mean, that makes "the show stop here" for you. If so, maybe you can be a bit more explicit about it. .... > > > - You have a web based IDE with editor, > > Why should I care ? I have a way better development environment on my > own box. > For example, on a running system, simple things are possible simply: change the cutoff date on something; change a class size. Yeah, sure - my app could write a controller for all those _little_ unanticipated tweaks that inevitably come, but why bother? You can just do it with existing environment: Want 100 coupons for that vendor? No problem (lets say that's in a controller). Want to make it a special thingy for that special vendor - put his image on his coupons? his words and instructions? Ok - I suppose i might have written a wiki interface so someone can do this one thing, this one time - but (again) why bother? I'll do it thru the dev. interface on a running system. If I'm convinced it was an un-captured requirement (e.g. no one thought of it until the system was running, or it was "assumed" but somehow missed by everyone) then I'll write the associated code, and add it to the running system. In fact, this is quite an agile way to do it. Both the dev. environ, and the command line shell help in this (I can write a small loop in the shell to effect what might be a controller for a customer, and output to a file instead of a view, and ask the customer "Is this what you're looking for?" - tweak, confirm happy client, and then put the code I just used into a controller - if it's short enough, right in the interface on the running system, and have the client try it while we're still on the phone/IM/whatever. The things I didn't think would be that useful - proved to have useful application. ...... > > Now FWIW, when my schema do change, the create/alter table code is > usually the most trivial part - there are quite a few other things to > do, that no framework will ever be abale to guess. IOW, you *do* have to > write a migration script anyway. In practice, this is /should be much less than you would think... ADDING columns to tables is simple. REMOVING columns... perhaps unnecessary on running systems... ALTERING columns... can probably be handled instead by adding. I think for most useful (and certain development time) cases, the framework can do reasonable things, usefully. But I do not deny that there are cases where there is not way around doing things smarter than that. I think it is just that there are times where that is not as necessary as at first appears. ..... > > Once again, while doing a quick dummy test app can give you a first > general "feel" of the tool, it means nothing wrt/ complex real-world > applications. Actually, I agree - and I would go a bit further: NO FRAMEWORK / tool has anything much to do wrt/ complex real-world apps. In fact, at the framework / coding level, things should be as simple as possible (that is where the cost is, anyway). Good analysis of the problem domain will suggest the shape of the solution needed. Prototyping will then help with things like "can it be a web app?" and "what technologies / implementation languages are appropriate?" Once you're at that stage, _any tool_ (and most likely, combination of tools / set of tools) come into play: what do they do to help at this level, how do they enable the process you want to follow, how do they get out of the way. Are they too rigid (too many defaults / too few options for a given solution decision)? But this is so far down the path of designing a solution that "complex real-world" doesn't fitthis discussion, without getting more specific, e.g. _a_ specific real-world app. For PyCon, web2py registration was done, reviewed, and put into place with little more than a month's worth of discussion / prep. Yeah, it didn't "look" like the main PyCon site the first year (and didn't take much at all to change that when I decided to). Yeah, there are still details about integrating w/ the django part of the site that could be taken care of from the web2py end (I don't know, but was lead to believe it would be easier from the web2py end than the django end, e.g. multiple database connections). As with many projects, if it is volunteer programming, and if it's _really_ important, it will happen, or if someone _really_ wants to do it - otherwise it's not evidence of anything more than something that's not really all that important. A few years ago, there was a challenge app (build a survey building app) that web2py finished, and donated in < 24 hrs; no one else either completed, knew of, or whatever - point is, if you _really_ want to make claims like this, then setup an essential ingredient that you are convinced is really beneficial - define it such that everyone agrees that it's a good definition: it will either be a key deciding point (and helpful to the community - "a does this; b does not"), or it will be a challenge point that can be tested (e.g. two solution approaches can be devised by "those who know the tools", and inspected and reviewed by the community - also helpful). Anything else is just opinion and talk - and to be sure, there is room for opinion, talk, and preferences (no one really _needs_ to convince a Ford owner to drive a Chevy - until some level of bankruptcy happens, it really doesn't matter). But even there, it is a benefit to the community in general to separate the talk from the real deciding factors. Thankfully, preference will always play a part. Kind regards, - Yarko -- http://mail.python.org/mailman/listinfo/python-list
