Thanks Geir. It will sure be useful; but for the moment I'm stuck with debugging/enhancing/extending a swing application - no chance now to setup and test the new #local directive.
Looking over the code I saw that it takes the current values of a given list of references and restores them later. It does not handle the case where listed local references are not available globally - null's are then restored?! So it acts a bit different than the #foreach loop variable. The way its implemented in Local.java might be ok - more to this below. I thought that the contract of the #local directive should be allowing to create context variables without affecting the callers (of macros and parsed documents). It sould also enable one to have some local declared variables dissapear after the #end. If the #set( $foo = null ) handling is implemented as proposed in another thread (to remove the reference from the context) then the current Local.java will probably work: * references without dots will be saved and restoring them will remove local ones that did not exists before. * references with dots will restore values within references (it might call the setter with a null value when no proper get was available - but whoever does #local($foo.bar $woogie.bang)...#end should know what he is doing). This latter one sounds a bit like magic, but it is orthogonal to simple references so it should be OK. some more inline... "Geir Magnusson Jr." wrote: > > On 3/27/02 8:42 AM, "Christoph Reck" <[EMAIL PROTECTED]> wrote: > > > Claude Brisson wrote: > >> > >> Thank you for your responses, Christopher & Geir. > >> [snip] > >> Chirstopher's #local directive proposal looks quite right to me, and I > >> volunteers to write it. > >> But (supposing my code is ok), will it be incorporated as a new > >> functionnality ? A patch has a quite short lifetime... > >> Time for what, now, votes, or validation, or something ? > >> > >> Thanx, > >> > >> CloD > > > > If you looked the ForeachDirective source and understood how parameters > > are passed to directives, then you can go ahead and implement it. > > > > Geir, would a LocalDirective make it into the core or into the contribution > > sections? > > > > I did one yesterday in a boring session here at J1, and just put it into > whiteboard/geir > > Give it a look. > > I really don't think we should jump ahead and make this core - we can > support it in a contrib section, and if people really, really find it > useful, we should talk about adding it, but I don't think it's really a core > function... Just my 0.02 I believe this is a candidate for core since it greatly enhances the usability/reliability of a (well written) generic macro library. > > > I you do not get flamed on cons about implementing a local directive, and > > Geir states he can put it into CVS, then you can read it as a "go ahead". > > With pluggable directives, anyone can implement anything. If there are good > contribs, we keep them. But we don't have to add them to the core if they > are not obvious or in widespread use. OK > Having 'local variables' is something > that makes a lot of sense to us programmers, but I would bet means very > little to designers. The 'local variables' feature is addressing programmers of #macro libraries and reusable template fragments (#parsed). Others don't have use them or even know about it. In a previous project with another template language I used included/parsed templates to create complex form fields to handle data structures (e.g. geographical coverage, time ranges, etc.) Also note that a #macro with a #local inside makes recursions a straightforward thing to follow. No magic on how to ensure the recursion will work. > > I personally have a use for this, but I don't think many people do. Dito. > > Geir -- :) Christoph Reck -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
