<[EMAIL PROTECTED]> writes: > Interesting point about one model file - suppose a lot boils down to expected > usage of SQLObject objects.
This is an interesting point. Another one is praticality. Where in SQLObject's docs there are instructions about setting up multiple files and integrating them? > I'm really trying not to sound too preachy here (it's hard :-) ) but keeping > lot's of classes inside a single file is just ... bad practice. It depends on how they interact. If you use ForeignKeys, MultipleJoins, RelatedJoins, etc. then it is a hell lot more practical to *see* all classes in the same file. Even with tabs or buffers or windows or ... it is easier to see their relation if they are grouped together. Specially when making changes that will interfere with this relationship. > I think the bottom line is that if quickstart had been written to create model > and controller directories in the first place this wouldn't be an issue and > you probably wouldn't be putting all your SQLObjects into a single source > file. Nobody is complaining about the static directory. Where are the docs? The only place where I saw it mentioned is http://sqlobject.org/sqlobject-admin.html and in a warning that if you have it in a different namespace then you'll have problems with the automation the tool is doing. If we are going to change that, there is a lot of documentation to be written on that and it has to be very clear so that the user gets what he expects, all classes and their relationship can be maintained and we don't have to ignore all of SQLObject's docs. So, more docs, tests and whatever for this, making sure compatibility with SQLObject still goes on, to avoid surprising long date users of SQLObject and projects already released. > Ah, for example. In my web project I have several dozen SQLObject derived > classes modelling my data with varying degrees of functionality in methods. > Having that all in one file would be a very bad idea for a number of very well > know anti-pattern reasons. Having fewer SQLObjects in one file seems ok but > is just bad practice with the consequences waiting to happen. Could you enumerate those well known anti-pattern reasons? And could you also enumerate some of the bad consequences? When people are reasoning about something it is much better to make things explicit than imply that all are thinking the same way you are or have the same background you do. Today is my Zen of Python (python -m this) citing day: "Explicit is better than implicit." -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
