Hi. Il 12/11/2013 19:56, Fabian Gundlach ha scritto: > an easy way to reduce code duplication would be to write common base classes > for Submission-UserTest, File-UserTestFile, SubmissionResult-UserTestResult, > Executable-UserTestExecutable. I've tried this out here: > https://github.com/fagu/cms/tree/abstractsubmission > It doesn't require any changes to the database and already reduced the code > size by 178 lines :). > > A problem is that some fields with similar meaning have different names, e.g. > submission_id vs. user_test_id, submission vs. user_test, submission_result > vs. user_test_result. This seems to be quiet a nuisance in ES (some functions > are almost identical apart from variable names). Maybe we could just call all > of them submission_...? If we don't want to change the database column names, > we should at least create "aliases" abstractsubmission_... pointing to > submission_... or user_test_..., I think. > > Another thing we might consider is creating a counterpart to Evaluation for > user tests (instead of putting the corresponding columns into UserTestResult). I don't have much time to think about that now, unfortunately, so my contribution is a little vague for now. I think that changing the approach may help us: in particular, I'd evaluate the possibility of using "smart" objects, instead of using them just as C structs (Luca, Stefano and I already had a discussion about this and, if I remember correctly, Luca was not very enthusiastic about this proposal). Making Submissions and related classes "smart" instead of "dumb", as they're now, should help fixing their interaction with other objects and reusing code. For example, ES shouldn't analyze the object to determine its priority in the queue or build its associated Job object. It should just call some opaque method which would do anything the right way directly. This way you don't have to worry about internal differences between Submission and UserTest, as long as they both offer an interface which exposes the relevant calls. Same thing for the Job generation. Did you think about this approach? What do you think about it? Gio. -- Giovanni Mascellani <mascellani@xxxxxxxxxxxxxxxxxxxx> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascellani@xxxxxxxxxx / giovanni@xxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
