So anyway, the new system (as it stands) does put the responsibility on the parser of deciding what type an entry is, including whether or not it's a dtable. That seems correct. During import, we create the entry and then check with the parser as to whether it's a dtable. If so, we invoke the dtable parser on it. That's what takes care of creating a matching DTableBean.

This is where the model breaks slightly: there's only one dtable parser. There should really be one for every type of markup which can support dtables. As it happens, no other markups can support them so that's OK, but there's nothing in the way dtable parser is written to remind you that it only knows about RML31. Perhaps I'd feel happier if we did group it under the parsers rather than in its own package. That might help a lot - the rml specific stuff would then be back where it belongs.

Let's say we do that; how do we stop the EntryBean from storing and retrieving the dtable data? What about the import parser getting the now-rml-specific dtable parser to handle the data as usual, then using it to strip the dtable data from the entry text? EntryBean gets updated with stipped text, job's a good 'un. On retrieval, entries can check what type they are and get the appropriate parser to reconstitute themselves.

I think I'm happier with that. Will think it through again over the weekend.

T


- posted by Tim Bruce @ 5:00 PM