On Dec 2, 2011, at 9:16 AM, jerem wrote:
Thanks ! :)
For Java I understand, even if I'm not eager to "verbosify" the cool
groovy
classes I use into painful java ... :) (I must say here how much I love
groovy)
Performances are quite good so far, really. At least for now it scales well
with 2300 topics and 5500 mails.
I'm not worried by performance but by maintenance/productivity.
If it's tons of groovy code in wiki pages (it has nothing to do with groovy but the
fact that it's in wiki pages) then it's unmaintainable (as can be testified by the
activity stream macro for example which is completely unmaintainable by anyone except its
creator (and even that isn't true if you check the # of unresolved issues we have with
it ;)), the blog app not being better btw) which will mean 2 things most probably:
1) It'll never make it to the platform as a standard component. That may not be your
goal though ;)
2) You'll be the only one to maintain it
3) Other code/extension written in java cannot reuse your code easily (component model)
Some questions for you:
* How do you autocomplete in wiki pages
* How do you have quick access to all your code scattered in several pages all visible
from within your IDE
* How do you write unit tests
* How do you document and generate javadoc
* How do you handle registration/unregistration of components
…
All these are not easy at all when writing in wiki pages which is why code in wiki pages
should be restricted to presentation code only and not business logic.
Anyway it's your code so you do whatever you want. I'm just stressing this since
it's going to be very hard to move away from it if you start coding too much in wiki
pages.
Thanks
-Vincent