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.
