Tabular ODS import

> While the class structure of Tabular is designed to support multiple
> formats in theory, in practice the existing implementation is quite XLSX
> specific.
>
> I think that trying to extend the core Tabular classes to be a superset
> of all the functionality from the various formats (XLSX, ODS, etc.) will
> not be practical - I don't have a good enough understanding of all the
> formats to implement it in the first place, and certainly not to resolve
> conflicting attributes in any sensible way.
>
> The approach I've taken is to make the existing classes, which were
> intended to be format independent, abstract and create format specific
> subclasses, i.e. the existing TabularCell and TabularStyle become:
>
>      TabularCell
>          TabularXLSXCell
>          TabularODSCell
>      TabularStyle
>          TabularXLSXStyle
>          TabularODSStyle
>
> The modified code runs the existing test suite successfully without any
> modifications.

> Le 19/4/16 16:41, Alistair Grant a écrit :
> > Hi All,
> >
> > I've been working on the ODS importer for the Tabular package
> > (http://ss3.gemtalksystems.com/ss/Tabular.html) and wanted to offer the
> > opportunity for feedback before updating the code as it is likely to
> > affect existing users.
>
> cool
> > While the class structure of Tabular is designed to support multiple
> > formats in theory, in practice the existing implementation is quite XLSX
> > specific.
> >
> > I think that trying to extend the core Tabular classes to be a superset
> > of all the functionality from the various formats (XLSX, ODS, etc.) will
> > not be practical - I don't have a good enough understanding of all the
> > formats to implement it in the first place, and certainly not to resolve
> > conflicting attributes in any sensible way.
> >
> > The approach I've taken is to make the existing classes, which were
> > intended to be format independent, abstract and create format specific
> > subclasses, i.e. the existing TabularCell and TabularStyle become:
> >
> >      TabularCell
> >          TabularXLSXCell
> >          TabularODSCell
> >      TabularStyle
> >          TabularXLSXStyle
> >          TabularODSStyle
> >
> > The modified code runs the existing test suite successfully without any
> > modifications.
>
> Sounds correct and if you add a factory or specific importer then you get it
> :)

> >
> > I welcome any comments, suggestions, etc.
> >
> >
> > Also, Tabular currently loads PharoExtras/XMLWriter and
> > PharoExtras/XMLParser as dependencies.
> This is good because these are the clean versions.
>
>
> > I've been using XMLSupport,
> > which I thought I remembered reading was a replacement for XMLWriter and
> > XMLParser, but now I can't find the reference.  Is one generally
> > preferred over the other?
>
> XMLSupport is a union of too many things. Modularity is not stupid Union.

> Hi Stepharo,
>
> Thanks very much for your feedback.
> ...
>
> So, time to learn more about Monticello...  Reading the Updated PbE is
> helpful, however I did notice one thing which doesn't match my
> experience.  On page 150 it is discussing how you can't lose code...
>
> "This is because all of the code that you executed is saved in the
> .changes file. All of it!  This includes one liners that you evaluate in
> a workspace, as well as code that you add to a class while programming."
>
> Should "workspace" be changed to "playground"?
>
> My experience has been that code evaluated in the playground is *not*
> saved to the changes file (Pharo 4.0 and 5.0).  Is there a way to tell
> Pharo to save evaluated code to the changes file?  (I admit to being
> lazy and not trying to figure this one out myself yet).

> Le 20/04/2016 22:47, Alistair Grant a écrit :
> > So, time to learn more about Monticello...  Reading the Updated PbE is
> > helpful, however I did notice one thing which doesn't match my
> > experience.  On page 150 it is discussing how you can't lose code...
> >
> > "This is because all of the code that you executed is saved in the
> > .changes file. All of it!  This includes one liners that you evaluate in
> > a workspace, as well as code that you add to a class while programming."
> >
> > Should "workspace" be changed to "playground"?
>
> Yes, can you open an issue please? :)
>
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues

> > My experience has been that code evaluated in the playground is *not*
> > saved to the changes file (Pharo 4.0 and 5.0).  Is there a way to tell
> > Pharo to save evaluated code to the changes file?  (I admit to being
> > lazy and not trying to figure this one out myself yet).
> >
>
> All the *compiled* code is save. The playgroud is for playing, so it is
> not save in the change file.  But the playground should save the code
> and you have a little menu to select your last scripts.
>
> http://puu.sh/opMd9/a823c07bf9.png
>
> If you use several times the same code you can also give a name to the
> tab (2 click on "Page") and after you can save the playground code. Via
> the spotter you can use the name of the tab to get a playground with the
> code.

> > Finally, in Section 8.2 on versions of a method, my impression from
> > reading the section was that it would always display all versions of a
> > method, i.e. I have 24 versions of a package in my package cache, so
> > expected to see each modification to each method in the package.
> > However because I had switched to a new image and loaded the newest
> > package, only the latest version was shown.
> >
>
> In the setting you can change the package-cache location to use always
> the same location even when you change of image. If the book is not
> clear can you copy/paste your mail into a github issue please? To not
> lose this feedback :)

> On Apr 20, 2016, at 23:55, Alistair Grant <[hidden email]> wrote:
>
>> On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote:
>> Le 20/04/2016 22:47, Alistair Grant a écrit :
>>> So, time to learn more about Monticello...  Reading the Updated PbE is
>>> helpful, however I did notice one thing which doesn't match my
>>> experience.  On page 150 it is discussing how you can't lose code...
>>>
>>> "This is because all of the code that you executed is saved in the
>>> .changes file. All of it!  This includes one liners that you evaluate in
>>> a workspace, as well as code that you add to a class while programming."
>>>
>>> Should "workspace" be changed to "playground"?
>>
>> Yes, can you open an issue please? :)
>>
>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
>
> Issue 164:
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/164
>
>
>
>>> My experience has been that code evaluated in the playground is *not*
>>> saved to the changes file (Pharo 4.0 and 5.0).  Is there a way to tell
>>> Pharo to save evaluated code to the changes file?  (I admit to being
>>> lazy and not trying to figure this one out myself yet).
>>
>> All the *compiled* code is save. The playgroud is for playing, so it is
>> not save in the change file.  But the playground should save the code
>> and you have a little menu to select your last scripts.
>>
>> http://puu.sh/opMd9/a823c07bf9.png
>>
>> If you use several times the same code you can also give a name to the
>> tab (2 click on "Page") and after you can save the playground code. Via
>> the spotter you can use the name of the tab to get a playground with the
>> code.
>
> This sounds great, but I can't reproduce it.  Would you mind clarifying
> what you mean by "2 click on Page"?  I tried clicking on the various
> buttons, and clicking action-clicking, and middle buttong click on the
> tab name ("Page"), without success (Pharo 5.0 50702).

>
>
>>> Finally, in Section 8.2 on versions of a method, my impression from
>>> reading the section was that it would always display all versions of a
>>> method, i.e. I have 24 versions of a package in my package cache, so
>>> expected to see each modification to each method in the package.
>>> However because I had switched to a new image and loaded the newest
>>> package, only the latest version was shown.
>>
>> In the setting you can change the package-cache location to use always
>> the same location even when you change of image. If the book is not
>> clear can you copy/paste your mail into a github issue please? To not
>> lose this feedback :)
>
> Issue 165:
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/165
>
>
> If I get time I'll also make the suggested changes and issue a pull
> request.
>
> Thanks!
> Alistair
>
>

>
> > On Apr 20, 2016, at 23:55, Alistair Grant <[hidden email]> wrote:
> >
> >> On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote:
> >> Le 20/04/2016 22:47, Alistair Grant a écrit :
> >> If you use several times the same code you can also give a name to the
> >> tab (2 click on "Page") and after you can save the playground code. Via
> >> the spotter you can use the name of the tab to get a playground with the
> >> code.
> >
> > This sounds great, but I can't reproduce it.  Would you mind clarifying
> > what you mean by "2 click on Page"?  I tried clicking on the various
> > buttons, and clicking action-clicking, and middle buttong click on the
> > tab name ("Page"), without success (Pharo 5.0 50702).
>
> I think you want to double click on "Page". At least it works on Mac OSX and Pharo 5.