3 Jun
2010
3 Jun
'10
12:19 p.m.
Le 03/06/10 11:19, Vincent Massol a écrit :
On Jun 3, 2010, at 10:37 AM, Ludovic Dubost wrote:
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.
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.
Le 03/06/10 10:31, Vincent Massol a écrit :
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.
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.
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.
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs