Inserting elements in an arbitary position

First of all: Happy new year 😃

I tried inserting a table after a paragraph, which is impossible. We can just append it to the end of the document. Is that correct?

Offtopic Discussion

I already tried to address my architectural concerns here. I see OfficeIMO as a great high-level API around open-xml-sdk. It attempts to abstract some of the complexity concerning office documents by capsulation. At the moment, I see these tasks:

• Packaging (maintaining XML files and un/zipping them)
• Capsulation of open XML Elements
• Aggregation of them

Domain-wise aggregation hast a context, most of the time. In pseudocode, I would expect something like this:

var doc = new Document();
var p =  new Paragraph();
p.do()
p.some()
p.stuff()

doc.append(p)
// or
doc.findFancyElement().InsertAfter(p)

In other words: The paragraph is not related to the document. Paragraphs are only responsible for the consistency within themselves. The possible validation of how to aggregate this should occur in an AggregationStrategy, assuming not every element can be inserted everywhere.

I am not sure, but I think we are doing more of this:

var doc = new Document()
var p = doc.AddParagraph()
p.do()
p.some()
p.stuff()

This way, we are not able to insert the elements arbitrarily.

If this is true, another disadvantage would be partial XML serialization. The implementation of the paragraphs is well crafted. Wouldn’t it be nice to get the XML representation for a single paragraph instance and paste it into the document using a file stream? This way, we could provide the best of the high-level API of OfficeIMO and keep it compatible with others. So to say: “If you think you need to do the aggregation in a special way, here you go.”

I don’t want to be impolite. I see all the work happening here, but those concerns should be separated, in my opinion. However, the refactoring would be tremendous, and I don’t know yet how to do it in small steps.

WDYT @PrzemyslawKlys ? I hope my point of view is just wrong because I have to find a way to insert a table in the middle of a document by the end of the week 😃

[PrzemyslawKlys]

I’m working on it as part of:

• https://github.com/EvotecIT/OfficeIMO/pull/110

Having small issues, but will try to resolve this week

[PrzemyslawKlys]

I accepted my own PR - feel free to expand on master 😉 Evolve it if you will, add more features, tests whatever 😉

I don’t mind leaving this ticket open as it discusses a lot of other ideas.

Regarding the Future Architecture

PowerShell is a scripting language but it’s based on .NET, so you can use .NET all around place. The problem is, some things are very hard to use. What’s in C# 2 lines of code sometimes gets really ugly if not impossible to be written in PowerShell.

It’s much easier to just use C# classes in PowerShell than it it to use interfaces and that’s what I mean. It’s hard to even find resources how one would use c# interface in PowerShell.

Anyways - that’s not really a problem, just something to keep in mind that whatever is exposed in the public, has to be sort of usable in PowerShell without doing tricks and code that want me to pull out my hair. But if it’s somewhere internally used, it’s not a big deal as PowerShell will never be visible.

And while I could use more experience - the problem is - it’s not part of my job 😃 That means I focus on things that I have to do and stuff like OfficeIMO and so on, are just a hobby. As for the meeting I am not sure I would be competent enough to talk about ‘patters or anti-patterns or code-smells’ because I lack any knowledge on it. That means I can’t understand in real time what you would be saying 😃 I need to read it couple of times, try to play with it, see what can be done.

But like I said before - I am open for people ideas and improvements all over the place. I believe the code is working, but it’s far from being optimized. I prefer the product to be working, having lots of features before you get and do it right - but at the same time it’s functional 2 years later.