On 3/27/02 12:12 PM, "Christoph Reck" <[EMAIL PROTECTED]> wrote:
> 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. It may be useful, and it needs more work :) > > 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?! That�s a valid issue - I think that if $foo isn't a valid reference before the call, then it shouldn't be after. > > 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. Yes - that it should be. We need to decide if it masks existing globals completely - you can't read the values of those already existing. I guess it should, however .... Dunno. I can see that one either way. > > 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. Because the real user context is wrapped, anything that didn't exist before shouldn't be added - the outer context is removed, leaving the inner. You can't add 'null' anyway to the context, so this shouldn't be a problem. If it is (i.e. If the internals aren't forcing the 'no null' semantics) then it's easy to check and not add it. > * 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 actually is very problematic, as $foo.bar can imply $foo.setBar(value), which has every chance of modifying state of the reference. This isn't good - there is no way to really protect that. Copying a reference to the outer protecting context obviously won't work, and doing a clone of it is just too scary for my tastes. We could just restrict the use of #local() to simple references rather than the identifier/property idiom... > This latter one sounds a bit like magic, but it is orthogonal to simple > references so it should be OK. So maybe we restrict to that... > 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. People believe all sorts of things :) That is a valid point though. >> >>> 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). Don't forget that #macros() are designed for designers - "...they are just bits of VTL so designers can take advantage of the concept of reuse...." But yes, it is useful. > 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. Yep >> >> I personally have a use for this, but I don't think many people do. > > Dito. > >> >> Geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
