Thorsten Scherler wrote:
Hi all,
I will have some time in the next week to enhance the performance of the
dispatcher. The performance always have been the Achilles’ heel of the
dispatcher.
Actually, the achilles' heel is the lack of clarity in the documentation.
This mail is an amazing coincidence. One of our team hear asked me this
morning how to do something with the dispatcher. I've done it before and
have sites running dispatcher, but I can't remember how I did it and I
can't point to any documentation about it.
In many cases this will mean that the dispatcher is not used and a
potential contributor is lost.
Performance is irrelevant if there are no users.
Another week point was/is the readability of the code.
Indeed, this is part of the documentation.
Another thing that I always wanted to integrate are java based
contracts. I want to allow within the next version of the dispatcher
that one can use a class instead of a xsl.
How about we finish one feature before adding another?
Since future version of cocoon are based on Spring and I am really
appreciate Spring as an excellent IoC container the dispatcher will be
as well based it.
+1
My plan is that this work will be compatible with the current version of
the dispatcher. It will provide simple shell scripts to update the
current version of structurer/contracts to the new form. I do not like
the specific extension we have for structurer (.fv)/contracts (.ft)
anymore since they are historic and do not reflect anymore the reality.
To remember ft stands for forrestTemplate and fv for forrestView which
is the first names of contracts and structurer.
Instead I suggest *.contracts.xml and *.structurer.xml.
Fine.
My initial plan is to reuse the code from whiteboard/dispatcher, conduct
the needed changes to work with java contracts and add spring support.
Any thoughts.
Documentation. Documentation and, er, documentation.
Other than that go for it!
Ross
