Joerg Heinicke wrote:
xml<map:match pattern="form"> <!-- pass the control to flowscript --> <map:call function="form"/> </map:match>
Here is the binding framework missing, I think. Is your solution without using the binding framework? How is the binding form vars <=> inputdoc done?
It's just shortened to the necessary :) Yes, the standard function needs some parameters.
No problem. Just want to clarify it! ;-)
This is not as easy. Because my transformer has configuration files and so on.
What does "configuration files" mean? The component I think about is just the same like the transformer, but only misses the implementation of the transformer interface. So I see no problem to extract the "connect to backend" logic from your transformer. Both the generator and the transformer use this component then.
My backend classes have a global configuration file. The file is passed in sitemap:
<map:transformer name="mytrans" src="myTransformer">
<configdir>work</configdir>
<configfile>myconfig.cfg</configfile>
</map:transformer>The configuration is passed by transformer to backend classes, because my backend classes don't have any clue where to get configuration from. So I have to pass this via transformer.
Pass some of this configuration to my backend processes. (it's not just one class)
From what I see you only need to separate the "connect to backend" logic from the cocoon specific interfaces generator and transformer. It allows higher reuse as you can access it directly from flow, no need to go through a superflouos pipeline.
Will have to think about it ;-)
What about a SQLTransformer? ;-)
I don't like it for exactly that reason. And would not use it.
I don't like it, too. See discussion about where to hold business logic.
Regards,
Christian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
