Tim Colson (tcolson) wrote:
Hi Tim,
I don't know personally, but I imagine if you were to create such a thing, it would be better as a Tool than a set of macros:
Here's another perspective...
- it's faster, which if you start rendering lots of simple HTML tags like this could be relevant
Got data on that? I'm not aware of any slow-downs incurred by having lots of macros.
Only empirical: I've run informal tests at times with equivalent functionality from a macro/tool method, and the tool has always won over and becomes significant when the functionality is being used a lot. This is likely to be inconsequential when thinking in terms of one page but if you're rendering simple HTML tags this way, perhaps not.
There is of course one undeniable minor slowdown associated with macros which tools don't have - at startup. This may not (should not) be a big deal for most however.
My preference for using a tool however comes down mostly to the fact that you can't overload macros. Perhaps more appropriate again in this case would be to use Velocity with ECS (or something similar). That's not a road I'll be travelling again though - as far as I'm concerned HTML stays in the template except where it's sufficiently complex to warrant a macro.
- you have a lot more flexibility in pure Java
Hmm... a macro can always -use- tools if they really need java.
And if they don't need it (see below)... then an advantage of Macro's is that the HTML author can easily see and change the specific HTML - without a recompile, and without understanding Java. Separation of roles is a good thing. :-)
Agree wholeheartedly in your last comment and in general, but exactly how much is a #href macro likely to change during a project...? When the macro becomes more complex I'm with you all the way ;)
- simon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
