I don't think you understood what I meant. I am not arguing to remove the
entering and configuration of the rotation angle, or crippling the
functionality to remove the "Extra" feature.
The GUI functionality is exactly the same as your current proposal.
The difference is only a question about what resides in the external
material definition file, and what resides in the code.
I'm basically saying that instead of having
template graphics
...
Transformer rotate
...
Product <real stuff>$$RotateMagic1<more real stuff>
...
end_template
template xfig
...
Transformer rotate
...
Product $$RotateMagic2<real stuff>$$RotateMagic3
...
end_template
which is what you propose, you can instead just have
template graphics
...
Transformer rotate1
...
Product <real stuff>
...
end_template
template xfig
...
Transformer rotate2
...
Product <real stuff>
...
end_template
In other words, the task of adding support for a transformation to a
template is to add one extra line.
The task of making the magic to make sure that the LaTeX product makes
sense, including the coordination and bracing and collapsing with other
transformers, is pushed to the hard-coded part in C++.
So, the transformer basically has a policy for how to attach itself to a
given product.
The first rotate1 transformer knows that it has to attach itself before
the {} braces.
The second rotate2 transformer knows that it has to wrap the real-stuff
with magic.
These transformers also know how to talk together with the other
transformers, to make sure that it is sane.
Advantages:
- The users do not have to know about all of this magic.
- When adding new transformation types, you only have to change the C++
side - the external material templates do not have to change to
accomodate the interaction with the remaining transformers.
- You do not hide the real product of a template in a lot of magic to
make the transformers work. They just work if they are compatible with
the product.
- The entire concept of exporters is not relevant to the user
Disadvantages:
- The user can not define the exact syntax himself. However, they do not
need this functionality.
- Instead of having one Rotation transformer, you have several depending
on how they interact with the product from the template
Regarding the implementation: Internally, you can implement this using the
syntax you have made up, but the point is that the user should not have to
worry about this.
Keep the API to the user as simple as possible. You have not convinced
me that we need the complex syntax yet.
Best regards,
Asger
