Don O'Hara <don.ohara@...> writes: > > Hi Graham - Welcome to web2py ! I think you'll find that this group > has many people who can share many types of design patterns. >
Thanks for the replies... Just to mention the others: I had looked at Django and Turbogears briefly - Django certainly gets the most mentions - at least sufficiently to feel that they would do what I want and then I came to web2py. I've started more seriously with web2py first simply because it was fresh in my mind, I'll return to the others later; I've sort-of decided on a few small apps, say a few days for each framework, although in order to keep the test apps meaningful they won't be that trivial otherwise it could be a completely unrepresentative exercise - so it may end up at more than a few days. The sort of application that I am planning are not really web apps, but intended for SMEs where there would run on a local network but, of course, by using a web approach it is easy to run the same applications on the Internet, a VPN, the cloud, use tablet/smartphone devices etc. and many of those options are very likely to be used. As for the self-submission: I cannot see much, if any, of the code that would be involved in the preparation and creation of the 'new' form and would be required for the validation and subsequent DB processing. Take as an example an Employee and payroll function: there would need to be a preliminary enquiry to establish whether creation of an Employee is required or whether the employee already exists, this could be a separate transaction or handled via Ajax when the relevant key fields (say name or reference) were entered (fully or use a bit of auto-complete) Then on confirmation that a new record was needed it would be necessary to read a couple, at least, of parameter records to acquire a few default values: some site preferences, some statutory; then the data for the 'create' page could be assembled, bearing in mind that a good number of fields would not be user-editable, and some not normally user-viewable. Then there are a good few one-to-manys in this example: there would possibly be more than one address; probably more than one additional contact (next of kin sort of thing); an employment history; set of skills and more especially related to payroll. While it is not likely that everything would be entered at the very first transaction there would be quite an amount entered at the start. A lot of 'validation' can be done on the client either by using selection boxes (perhaps the options constrained by the site preferences) in javascript but at the end there would need to be some validation by the application and, of course, dealing with the creation of the two or three (or more) subsidiary rows of the manys I cannot see how that sort of interaction can be made to work with self- submission and I cannot see how such a really not very complex data creation procedure could be made any simpler. graham -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
