Closed RustyNixieTube closed 3 years ago
and we can do this
impl Style {
fn cell_style() -> CellStyle {
CellStyle::new()
}
}
//and now we can do this
let style = Style::cell_style().name("a style with builder pattern").border(Length::Mm(1.0), Border::Dotted, Rgb::new(0, 0, 0));
Yes, maybe. Personally I'm not a fan of this style. And I'm not sure if copying the 232 bytes of Style a lot of times is really such a good idea.
There is still a lot of things missing, formula support is very rudimentary, default-styles are a complete hack. At read.rs:94 is a list of 14 tags that are simply copied into a xml tag, but that are nowhere exposed by an api (not all of them interesting). At read.rs:192 are a few more. Easier support for text format would be nice. There are special tags for header/footer formatting (page number, page count etc), but no easy way to do this.
And that's just what's on the top of my head.
What are you trying to do with this?
What are you trying to do with this?
I meant what do you want to do with this library?
I meant what do you want to do with this library?
I want to built a libre office equivalent in rust (for fun)
And I'm not sure if copying the 232 bytes of Style a lot of times is really such a good idea.
Yes, sorry. I made a mistake. this version move the Style struct:
struct CellStyle {
style: Style
}
impl CellStyle {
fn new() -> CellStyle {
let mut style = Style::new();
style.set_family(StyleFor::TableCell);
CellStyle {
style
}
}
fn name<S: Into<String>> (mut self, name: S) -> Self {
self.style.set_name(name);
self
}
fn border (mut self, width: Length, border: Border, color: Rgb<u8>) -> Self {
self.style.cell_mut().set_border(width, border, color);
self
}
//etc for all cell style properties
fn build(self) -> Style {
self.style
}
}
//now we can have an immutable style builded with only one line
let style = CellStyle::new().name("a style with builder pattern").border(Length::Mm(1.0), Border::Dotted, Rgb::new(0, 0, 0)).build();
the builder pattern allows you to prevent a bad use of the API as in #1 because it only expose methods that are needed for creating something.
It's true that it's not a priority if the API is not complete. can you give me the link of all the documentation that are useful for this project please?
that's the official documentation.
the rest is some reading between the lines and trying.
thank you
The main issues are solved with the splitting into various style types. And some mistakes are captured via style refs.
Close this for now.
should we add some builder patterns to make the API more user friendly?
something like that:
P.S. add a question label to this issue please