Hi, I prefer immediate validation as it makes it much easier for users to develop their code as they see quickly where it went wrong. And we do such checks already in many places, e.g. all the limits of number of rows/col/... and other sanity checks that are spread throughout the code. The downsides for checks when writing are quite severe in my opinion.
I think for the "X" formats we already provide non-validating access methods via the getCT...() low-level API, so I would not bother to much adding anything else unless there is a good use-case for a non-validating method. Dominik. On Tue, May 10, 2016 at 9:27 AM, Andreas Beeker <[email protected]> wrote: > Hi Javen, > > this is just a quick response, so you don't think this topic is going > under ... > > I would prefer not to validate the whole file on save - especially as > there are still a few > areas where we can say for sure, if a modification corrupt the file - at > least for HSLF. > > Although I can imagine something similar can happen with HSLF too (e.g. > removal > of used styles), I would further prefer not to generalize it, i.e. first > do a breaking > modification and then hope, that the saving part will find it. > > So I would go with option 3 in this case - if a user chooses to use > non-validating modifications, > he would also need to test, that the written file is ok ... i.e. keep it > simple stupid ... > > Andi. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
