2012-04-03 5 views
0

私は、複数のチームが解析されるコンテンツをアップロードするDjangoアプリケーションを持っています。このアプリは、解析されたコンテンツ内の特定の共通情報を追跡します。ここで問題となるのは、コンテンツが異なる形式(たとえば、XMLコンテンツを持つチーム、テキストを含むチーム、JSONなど)のため、各チームが異なるパーサーによって解析される必要があるコンテンツです。各チームは、解析後に対応するDjangoモデルに配置される必要な情報を取得するパーサー(Pythonモジュール)を提供しています。Django:ユーザーに基づくモデル依存のアプリケーション

私の質問は、各チームが独自のパーサー設定を正しく行うことができるDjangoでこれを構築する最良の方法は何ですか?純粋にバックエンドにすることも、ユーザーフォームなどの必要がないこともあります。

class Parser(models.Model): 
    team = models.ForeignKey('Team') 
    module_path = models.CharField(max_length=..., blank=False) 

module_pathは、そのパスに私のアプリのコード内に存在するだろう「parsers.teamA.XMLparser」ようなものになるだろうことを:私の最初の考えは、私はそうのように各チームにForeignKeyのでParserモデルを作成するというものでしたそのように:何の問題

team = Team.objects.get(id=team_id) 
parser = Parser.objects.get(team=team) 

theParser = __import__(parser.module_path) 
theParser.parse(theStuffToBeParsed) 

parsers/ 
    teamA/ 
     __init__.py 
     XMLparser.py 
    teamB/ 

はその後、私のアプリがアップロードされたコンテンツを解析するために来ているとき、私はこれを持っているでしょう誰もがこれを見る?私が考えることができる唯一の他のオプションは、各パーサー用に別々のDjangoアプリケーションを作成することですが、どのチームがデータベース内のどのアプリケーションを使用するかをどのように参照しますか?

答えて

1

あなたが取っているアプローチは私にとっては有効です。あなたは効果的に任意のPythonコードを実行しているので、パブリックサイトのサイトでこのようなものを使用することは決してなく、パーサーを書くチームを信頼できるようにしてください。

毎回インポートを処理する必要がなくなり、代わりにインポートを処理して解析メソッドを返すモジュールパスを表すカスタムフィールドを記述することで、これを少し上手くすることができます

最も良い例は、djangoのImageFieldやCharFieldのソースを見ることです。モデルにCharFieldを持たせる代わりに、 "ModuleField":parser = ModuleField()があります。データベースに格納された値は本当にモジュールへのパスになります(単純にCharFieldのサブクラスにする)が、to_pythonメソッドをオーバーライドします。あなたの新しいto_pythonメソッドでは、モジュールをインポートして、pythonオブジェクトを返します。

そのpythonオブジェクトはあなたが望むものであればどれでもかまいませんが、あなたの例ではreturn theParser.parseです。これは、あなたがParserインスタンスfooを持っていれば可能です。the_parser_method = foo.parser

+0

@ John、アドバイスありがとうございます。モジュールパスを表現するためにカスタムフィールドが意味するものが不思議です。輸入を処理するにはどうすればよいでしょうか? – Randy

+0

あなたのフォローアップに答えるために私の答えを編集しました – John

関連する問題