[sc-dev] Application modules become dependent from module oox?
Hello, with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Remember all the rants from users and developers about the monolithic office we currently have. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote: with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. It wasn't actually discussed at all, and no thought went into it; it was the easiest thing to do. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Understood. So, what's the solution to this? In particular, a reasonably fast solution as I'd like to get this merged for OpenOffice.org 3.1. :-) I see the following solutions: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. 2. Split out oox's XmlFilterBase dependent types into a helper library (or perhaps use comphelper?), and depend on this helper library from both sc oox. 3. Implement BIFF/OOXML export within oox. (1) is obviously the easiest, requiring no immediate work, and the work to remove it for 3.2+ could be (2) or (3). I'm not sure how feasible (2) actually is -- it looks doable, but I'm not sure what hidden issues will show up, nor what library it would be appropriate to move FilterBase, XmlFilterBase, ZipStorage, etc. into. Cursory discussions suggest that comphelper may be a good destination, as sc already indirectly depends upon comphelper, so it's not really adding anything that wasn't there before. (3) isn't really viable, not short term, though I understand that the long term plan is to obsolete sc/source/filter/excel in favor of using oox for saving .xls files. I'm open to alternative solutions, but these are all I could think of. Thanks, - Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
Jonathan Pryor schrieb: On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote: with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. It wasn't actually discussed at all, and no thought went into it; it was the easiest thing to do. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Understood. So, what's the solution to this? In particular, a reasonably fast solution as I'd like to get this merged for OpenOffice.org 3.1. :-) I see the following solutions: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. 2. Split out oox's XmlFilterBase dependent types into a helper library (or perhaps use comphelper?), and depend on this helper library from both sc oox. 3. Implement BIFF/OOXML export within oox. (1) is obviously the easiest, requiring no immediate work, and the work to remove it for 3.2+ could be (2) or (3). I'm not sure how feasible (2) actually is -- it looks doable, but I'm not sure what hidden issues will show up, nor what library it would be appropriate to move FilterBase, XmlFilterBase, ZipStorage, etc. into. Cursory discussions suggest that comphelper may be a good destination, as sc already indirectly depends upon comphelper, so it's not really adding anything that wasn't there before. I don't like (2). I think best thing is to do (1), and think about (3) for 3.x as you suggested. (3) isn't really viable, not short term, though I understand that the long term plan is to obsolete sc/source/filter/excel in favor of using oox for saving .xls files. Ok. So, as it is now means there is less potential for source code conflicts while working on import (me) and export (you) :-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
Daniel Rentz schrieb: Jonathan Pryor schrieb: On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote: with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. It wasn't actually discussed at all, and no thought went into it; it was the easiest thing to do. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Understood. So, what's the solution to this? In particular, a reasonably fast solution as I'd like to get this merged for OpenOffice.org 3.1. :-) I see the following solutions: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. 2. Split out oox's XmlFilterBase dependent types into a helper library (or perhaps use comphelper?), and depend on this helper library from both sc oox. 3. Implement BIFF/OOXML export within oox. (1) is obviously the easiest, requiring no immediate work, and the work to remove it for 3.2+ could be (2) or (3). I'm not sure how feasible (2) actually is -- it looks doable, but I'm not sure what hidden issues will show up, nor what library it would be appropriate to move FilterBase, XmlFilterBase, ZipStorage, etc. into. Cursory discussions suggest that comphelper may be a good destination, as sc already indirectly depends upon comphelper, so it's not really adding anything that wasn't there before. I don't like (2). I think best thing is to do (1), and think about (3) for 3.x as you suggested. ... reading this ... should have written a reason for disliking (2) :-) As you said, separating the base code from filter code may raise hidden issues and would make everything more complicated (working/building in 2 or more modules etc)... And I think this filter stuff is a little bit too special for comphelper. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
Hi Daniel, On Fri, 2008-11-21 at 17:15 +0100, Daniel Rentz wrote: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. .. I don't like (2). I think best thing is to do (1), and think about (3) for 3.x as you suggested. That sounds great; just to give a quick rational as to why this approach. While clearly a separate UNO component, or things living in oox is the end-goal, I'm a fan of step-wise re-factoring - such that we can prove that nothing broke during the process, and such that there is only one copy of the code to maintain and develop at any time. My hope is that by adding OOX export here, then going on to re-factor the existing combined filter to use the UNO interfaces to build it's model, we can incrementally move to the point that chipping that whole export chunk off into it's own component (or into oox) becomes easy - while still being to prove that nothing broke. That way, hopefully we get where we want to go, while keeping everything working in the meantime; that is the thinking anyway - does it make sense ? Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
On 11/21/08 18:01, Michael Meeks wrote: That sounds great; just to give a quick rational as to why this approach. While clearly a separate UNO component, or things living in oox is the end-goal, I'm a fan of step-wise re-factoring - such that we can prove that nothing broke during the process, and such that there is only one copy of the code to maintain and develop at any time. My hope is that by adding OOX export here, then going on to re-factor the existing combined filter to use the UNO interfaces to build it's model, we can incrementally move to the point that chipping that whole export chunk off into it's own component (or into oox) becomes easy - while still being to prove that nothing broke. That way, hopefully we get where we want to go, while keeping everything working in the meantime; that is the thinking anyway - does it make sense ? The problem is, we have spent a lot of effort already to keep the filter implementation in oox separate from the application (new APIs and all), and this is something that this change would break. Everybody is asking for modularization, and I don't want to discard all this effort and take a step backward now, with the hope of fixing it some time later. Even start-up performance might be affected, if oox is added as a dependency to sc. So, at the risk of seeing more evil Sun isn't accepting our contributions blog entries: No, ooxml02 can't be integrated as-is. Of course, the way to avoid such situations in the future is to discuss these things before starting the implementation. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
