Paulo Gaspar wrote:
> > > something gets written all the time, even if the
> > > $emptyVar is really "empty".
> >
> > Can you define empty? You mean not in the context?
>
> Usually it is an expression like:
> $someObject.property
>
> And in most cases, the object is a ResultSet wrapper with has
> a method looking like:
> public Objec get(String i_name)
>
> The problem is when this method returns null.
Ok. That's better.
>
> > > Also, sometimes code in macros seems to become
> > > "persistent" (I change the template but the bit of
> > > formatting from inside the macro remains the same.
> >
> > Yes - by default, the first macro defined is permanent. There are
> > plenty of options to change the behavior to suit your need. In this
> > case...
>
> I did not find that to be clear in the documentation. But
> maybe I did not read with enough attention.
>
> The documentation talks about macros that can be registred
> for global use and so, but I always thought that macros
> declared in one template would be used only by that template.
>
> Do you mean that Velocity only has GLOBAL macros???
> Can that be changed?
No, it doesn't only have *global* macros. By default, macros are global
- the idea is that they can be shared across a webapp (or app). But by
default, they are set so that the first registered one becomes the VM
for that name, and other attempts to change are prevented. This keeps
designers from changing VMs set by the global library, and still offers
you the change to add them as you need them.
So to make VMs local-only to your template :
velocimacro.permissions.allow.inline.local.scope = true [default is
false]
will do that - VMs are usable only by the template that defined them.
Again, to let any template change a VM in the global namespace :
velocimacro.permissions.allow.inline.to.replace.global = true [default
is false]
and to turn of in-template VM definition and use only the global
library(ies) :
velocimacro.permissions.allow.inline = false [default is true]
> > velocimacro.permissions.allow.inline.to.replace.global = true
> >
> > will fix it.
>
> Does that replace the global macro GLOBALLY or just for the
> current template?
globally
> > > Does anyone have any pointers on this stuff?
> > > Any clues?
> > > Any advise on where I should start trying to fix this?
> >
> > Well, reading the manual in the case of the macro persistance might have
> > given you a clue. I have been wanting to write something more
> > substantial about the VMs, so I guess this motivates me to do it.
>
> Didn't.
>
> Maybe I did not pay enough attention, but I had the idea that macros
> declared in a template would be for the private use of that template and
> when I found the reference to global macros in the docs I just understood
> that those had to be registered somehow - which was not interesting for
> my case.
>
> This is the most intuitive working model. Other engines work that way.
> The only problem I see with the documentation (which is DAMN GOOD and is
> clearly improving all the time) is that it does not make this less usual
> working model clear upfront.
That's good feedback. I will do that.
> I still think that this is the most intuitive way to have macro
> functionality. Why is it not that way?
> (Just want to understand if there is a reason.)
The model it has is because of the way it evolved - we always tried to
remain backwards compatible when we relized the problems in the model.
> I would also like to know if we could have global macros being
> explicitly declared (and changed with each page change) or globally
> available trough some registration/magic-file-or-directory mechanism.
You can :
1) Have global ones set at startup, and no one else can add.
2) Have global ones set at startup, others can add only new ones
3) Have global ones set at startup, and modified by others during
runtime.
4) Have global ones set at startup, no new global ones at runtime, but
template-local ones at runtime.
I can't think of a way to have runtime-modified globals while
template-local in effect w/o changing the template syntax so you can
indicate namespace, something I believe isn't the right thing to do in
VTL.
The other solution is to add some sort of API, but again - I can't see
this as a big problem.
> This sounds more intuitive. I will contribute to it... unless there
> is a reason against.
>
>
> Thank you very much and have fun,
> Paulo Gaspar
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
