[sword-devel] Titles and other Inter-verse material

[DM Smith]

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 <refdoc at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page