Le 03/06/10 11:19, Vincent Massol a écrit :
You are forgetting the HTML in the presentation part. It's important to have templates to decide the HTML. It always at some point backfires to not be able to customize the HTML.On Jun 3, 2010, at 10:37 AM, Ludovic Dubost wrote:Le 03/06/10 10:31, Vincent Massol a écrit :Hi devs, We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. Some ideas: - java macros are much easier to test - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) - java macros can obey styling rule, such as checkstyle passing - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR Proposal ======= - If the macro is a generic macro then it should be written as a Java macro - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro WDYT?I believe there is some other cases where it should be a wiki macro, it's when the macro is highly presentational and when there is a good chance the advanced user would like to be able to change the macro to add parameters or modify it's presentation. In this case it's very important to make the macro easily modifiable and that's what Wiki macros allow.Indeed anything related to presentation/style (colors, fonts, texts, etc) should be modifiable by the user so that part needs to be externalized from the java macro somehow. One idea is to have these macros provide a cssLocation/jsLocation parameter pointing to place where to put custom css/js. When not specified the macro would use default css/js.
It's really important that the dev team thinks about customization when providing modules to be used. I can tell you that the people working on XWiki implementations always have to customize, and if we hit using a Java module that lacks a parameter or does not allow to easily customize the HTML it outputs, we are stuck and cannot respond to the end user's need.
We have used velocity macros to do all presentational stuff in the past. If we move and invest in transforming these into XWiki Macros, we should not loose the customization capabilities that velocity macros gave us.
I'd like to point out I'm talking about presentational macros for which the output is nothing more than assembling HTML from parameters. This includes macros that assemble HTML from an Internet Web Service.
Ideally we would have a full-fledged IDE in the wiki and we would write everything as wiki macros but this is not the case and we're a few years away from this so I'm not sure it's a good idea to do so right now. BTW this is a bit similar to the discussion as to whether the Blog application should have a Java module that implements its code logic and only keep the presentation part in wiki page vs what we have right now, i.e. the whole application in wiki pages.For testing, I believe we should make a simple testing framework that allows to test a simple wiki macro (which does not use jsx or other stuff).Making a wiki macro testing framework that works without a running XE is probably quite a lot of work. Need to think more about it. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
<<attachment: ludovic.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
