Hi Andy, One important issue here is whether all the applications you are going to build with web2py need to share authentication with non-web2py applications or not. If yes you need federated authentication (for example CAS) and things can get complex. If no, then you can simply your life a lot if
1) make a single controller for each complaint 2) make a single model for all complains 3) extend your application with one controller and one model file for each main function of the company This design will allow to easily share the built-in authentication (auth and db.py) and layout.html It is modular enough that if you later choose to break it into separate apps and implement some other distriuted authentication mechanism you can do so. Massimo On Apr 8, 3:42 am, AndyBuchan <mr_buc...@hotmail.com> wrote: > Hello all, > > I've never worked with a web framework before, other than going > through the examples in the web2py manual, and have been tasked with > creating an application which handles internal 'complaints' for the > furniture manufacturing company I work for, and am looking for some > advice on how to structure it all... > > Requirements: > - Complaints can be one of 3 types: 'Transport Complaint', 'Client > Complaint', 'Corrective Action'. > - These all have some fields in common, but also have their own > fields, and all behave differently (i.e. have different actions). > - Any type of complaint can require that a 'replacement' be sent to > the client. > - A replacement has its own set of fields and actions (requires > authorisation etc...) > - The user should access a main screen from which he can select which > type of complaint to generate, which will bring him to a form. If they > check the box 'Requires replacement', then additional fields are shown/ > enabled on the form. > > Design ideas: > For the relational model I made a table called 'ComplaintBase' which > stores the fields common to all types of complaint, and identifies the > type of complaint. Then there is a table for each of the 3 types of > complaint, where each row references a row in 'ComplaintBase', and > finally a table for 'Replacement' which also references > 'ComplaintBase'. > > So far so good, but now I'm wondering: > - Should I make a controller for each type of complaint? > - Should I make classes in a separate file to represent each type of > complaint (and wrap a ComplaintBase object inside each of them, which > will also handle the 'Replacement' as that works the same for all > complaints). If I'm doing this, then the controllers are just a > gateway between the interface and the 'business objects', is this how > it should go? > - Should I skip the idea of separate classes for business objects > altogether, and just treat the controller as the business object > (going functional instead of oop)? If so, how could I make the > controller classes behave in the same way for certain actions > (inheritance/composition)? > > - On a more general note: am I going the right way about organising > this as a full application? I intend to create many similar small > applications for various functions in the company, but would like > certain elements to be shared across these applications (look and > feel, user authentication etc...), tell me I shouldn't be creating on > application for the whole business, and use controllers for each > individual 'application'. (May be bleeding obvious to some, but > thought I'd double check...) > > I look forward to hearing your thoughts/advice, and hope it will be > useful to more than just my situation... > > regards, Andy. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
