As a front-end developer I don't like the special code either. I found that the problem comes because once a module is in the wild, within reason we need to support it.
One example the NET module has bugs in it. The original OSIS is not well-formed xml. However, it is out there and the authors have not fixed the bug. So JSword has special code for it. -- DM On Jul 23, 2012, at 3:22 AM, Nic Carter wrote: > > Replying with my Front-End developer hat on: > > On 23/07/2012, at 4:57 PM, Peter von Kaehne <ref...@gmx.net> wrote: > >> So, my proposal - cut osis2mod into half. Let one part handle reordering >> but then spit the result out as a new osis file. Which can be tested, >> which can be worked upon. >> >> And let the other part do the defined format to module transform, >> without any further transformations. And whine if something is not to >> exact liking. > > As someone who has recently (in the grand scheme of things?) implemented a > front-end to try to display these OSIS modules correctly, I would love to see > something like this occur. I remember looking at some MacSword 1 code a > while ago and saw that there were per-module hacks to get them to work. > (Hopefully they were relevant to the specific version of the module, too, but > I can't remember.) I decided there was no way I was going to do that for PS > and haven't (so far!). Looking at MacSword 2 code I was much more > comfortable with the approach of assuming that the filters would do "the > right thing" and so we just took what was given and displayed it properly. > However, there have since been hacks in the MS2 & PS code that don't assume > the right thing is happening but try to work around things in general. I am > thinking specifically of headings, and remember the pain of switching > headings on/off in different modules produced different results (including > some modules spitting out the headings twice if you tried to do things > according to spec -- we have a hack to get around that now!). > > So, all that to say, yes please, if someone has time I think this would be > the preferred way of moving forward with osis2mod. osisCleanup? and then > osis2mod? and specific and fatal errors on the 2nd osis2mod. And then > hopefully we can try to program the front-ends to spec and have the right > things happen? Then again, perhaps we'd then start looking more closely at > the filters if they are to blame for weirdness? But I can be hacking those > myself if required, whereas there's nothing much I can do about things once > it's a weirdly produced module... > > Oh, we'd then need to go back and re-create all our OSIS modules, and that > might be fun! ;) > > > Just my random thoughts! ybic, > nic... :) > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
