Took a quick look at the code; this bit looks wrong:
def delete(ref)
…
@sheets.delete_at( ref + 1 )
I think it should be (ref - 1). Which brings me to my main point, that
1-indexing is tricky and should be bolstered by a lot of tests in case
you inadvertently slip up. Also @sheets.delete_at changes the array
whereas @sheets.reject does not; it should be reject! for consistency.
(Again, tests would have caught this.)
martin
Uh oh, I think I’ve backed myself into a corner…
I assume that I’ll need some sort of “dup” method in order to easily
differentiate between modifying an object in place and returning a copy.
However, in my attempts to interlink all the elements, I think I’ve
created a situation where I’ll end up in a loop.
RubyExcel holds “child” Sheets
Sheet links to “parent” RubyExcel
I know they aren’t really parent and child, but I wasn’t sure of the
best way to link them together.
In order to dup RubyExcel I need to dup each sheet.
In order to dup a Sheet I need to dup RubyExcel.
I’ve ended up with a circular reference and I’m not sure of the best way
to proceed from here.
Also, is it sensible to have the namespaces stacked the way I’ve done
it? Like RubyExcel::Sheet::Element.
On Thu, Mar 14, 2013 at 11:04 AM, Joel P. [email protected]
wrote:
Uh oh, I think I’ve backed myself into a corner…
In order to dup RubyExcel I need to dup each sheet.
In order to dup a Sheet I need to dup RubyExcel.I’ve ended up with a circular reference and I’m not sure of the best way
to proceed from here.
It may be an indication that you got your design wrong. Why did you
think you need the circular references in the first place?
Also, is it sensible to have the namespaces stacked the way I’ve done
it? Like RubyExcel::Sheet::Element.
I’d probably only have one level of namespaces for this, e.g. module
RubyExcel and put all classes in there. You won’t have too many
classes to distribute across a multitude of namespaces.
Kind regards
robert
Robert K. wrote in post #1101581:
I’ve ended up with a circular reference and I’m not sure of the best way
to proceed from here.It may be an indication that you got your design wrong. Why did you
think you need the circular references in the first place?
I need a Sheet to belong to a workbook, but also be able to be copied or
moved from one workbook to another. I need to be able to find the sheet
from the workbook, and find the workbook from the sheet.
Originally I thought that would be some sort of inheritance chain, but I
can’t use inheritance because Sheet is not a type of Workbook.
I’d probably only have one level of namespaces for this, e.g. module
RubyExcel and put all classes in there. You won’t have too many
classes to distribute across a multitude of namespaces.
Perhaps a RubyExcel Module with the first class called Workbook would be
more suitable.
Thanks for that, I hadn’t gotten around to doing much testing with
sheets yet.
The 1-based indexing can be tricky to keep working as a standard, but
one thing I thought this might help with is transitioning between VBA
and Ruby. If the addressing and objects look similar, you don’t need to
change much of the individual project detail.
I have some VBA code which I think would be much simpler in Ruby, and if
I can set this up I might even be able to write something to translate
VBA into Ruby working with this class. That’s more of a vague idea for a
future project though.
I do need to add more checks, particularly validating input. What I want
to do is to try and have most validation pass through the Address
module, so I can make any changes there rather than running around the
entire project looking for duplicate code.
This is still very much under construction, but it’s good practice for
me to use Github; and it’s amazingly useful to have advice from more
experienced programmers while I struggle to build a viable tool. Thanks
again for your time 
Martin DeMello wrote in post #1101514:
Took a quick look at the code; this bit looks wrong:
def delete(ref)
…
@sheets.delete_at( ref + 1 )I think it should be (ref - 1). Which brings me to my main point, that
1-indexing is tricky and should be bolstered by a lot of tests in case
you inadvertently slip up. Also @sheets.delete_at changes the array
whereas @sheets.reject does not; it should be reject! for consistency.
(Again, tests would have caught this.)martin
When I “delete” a sheet, do I just need to stop referring to it as an
object? As I understand it; once it’s removed from “@sheets”, it should
be garbage collected.
Robert K. wrote in post #1101592:
and find the workbook from the sheet.
What functionality for?
It’s quite useful in case I lose track of the object which is the
“parent” of the sheet. Consider this example of the current code:
#Shortcut to avoid having to go through the workbook every time
sheet = RubyExcel.new.load data
#But now I want the workbook:
myRubyExcel = sheet.ruby_excel
I wanted something akin to Excel VBA’s approach
ActiveSheet.parent
=> workbook
On Thu, Mar 14, 2013 at 1:37 PM, Joel P. [email protected]
wrote:
Robert K. wrote in post #1101581:
I’ve ended up with a circular reference and I’m not sure of the best way
to proceed from here.It may be an indication that you got your design wrong. Why did you
think you need the circular references in the first place?I need a Sheet to belong to a workbook, but also be able to be copied or
moved from one workbook to another. I need to be able to find the sheet
from the workbook,
OK, that sounds reasonable.
and find the workbook from the sheet.
What functionality for?
Originally I thought that would be some sort of inheritance chain, but I
can’t use inheritance because Sheet is not a type of Workbook.
This is certainly not a case for inheritance.
Cheers
robert
I think I’ve found a way around this.
I’ve made Sheet’s “workbook” an accessor rather than read-only. When I
dup a workbook, I dup each sheet, and then overwrite the “workbook”
attribute with the new one.
When I “dup” a Sheet, it has the same parent as the original, so I could
overwrite the original if required (like +=).
I’ve now learned how to publish this as a gem. Still lacking proper
documentation at present, but it’ll let me work on it and test it out
from multiple locations.
It’s currently living on RubyGems here:
https://rubygems.org/gems/rubyexcel
Minutes after I uploaded it the downloads went to 4. Not sure if that’s
genuine downloads or some automatic thing.
Anyway, feel free to have a play with it and see if it does anything
unusual or lacks any features which would be handy. I’ll add any
requests onto my to-do list… or to my list of things to learn how to
do
The RubyExcel Module is now bashed into something resembling operational
status. I still have plenty of ideas to implement with it, but it’s
finally something I can use (and have used) to handle data and output it
into a neat excel format.
I think the next thing I need to do is try and add documentation to the
code and upload it (YARD-style, I think) to github as well. Poorly
documented APIs are the bane of the earnest programmer
Hopefully I’ve learned something along the way and not made a complete
mess of it; but if any intrepid code explorers spot any glaring
mistakes, correction would be appreciated.
Thanks,
Joel
Hi all, just an update for anyone who’s interested.
I’ve now managed to get this gem working sufficiently well to use it in
a few of my projects.
I’ve incorporated some WIN32OLE tools for things that I do a lot, also
lending credence to the name RubyExcel.
I think I’ve weeded out most of the bugs, and I’ve written a more
comprehensive guide which is the ReadMe at Github.
I’ve tried to take on board all the suggestions so far, although I’ve
dropped the header columns idea as tricky to implement alongside header
rows; and currently of no use to me. Maybe I’ll be able to add them
later.
I’ve now managed to implement all the basics to the point that I’m just
adding new bits as and when I need them. The core sections all seem to
be working as intended, although of course it’s still possible to cause
problems by feeding it invalid input. I might add more extensive
validation if that becomes enough of an issue.
I’ve even managed to get a wobbly looking bit of recursive code to
import a nested Hash into a table array; which is something I’m having
to do at work with increasing regularity. I spent long hours into the
night trying to build it and I’m still not entirely sure how it works.
It was more of a half-understood trial and error thing.
Actually if anyone can come up with a better way to do this I’d be
fascinated, since I always have trouble visualising recursive methods.
I’ll attach the relevant code to this post.
The gem still lives here: rubyexcel | RubyGems.org | your community gem host
The code still lives here: GitHub - VirtuosoJoel/RubyExcel: Spreadsheet storage class in Ruby with Excel-style API
I still need to work out what (if any) documentation-style comments to
add to the code itself. What do people use the most? The rubygems
documentation link says it’s a “YARD documentation server”, but the
local install only dropped some “.ri” files, and I’ve only just learned
how to use those.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs