> El lun, 16-01-2006 a las 17:05 +0100, Gavin (JIRA) escribió: >> [ >> http://issues.apache.org/jira/browse/FOR-790?page=comments#action_12362854 >> ] >> >> Gavin commented on FOR-790: >> --------------------------- >> >> This can be avoided by using onFocus inline for Form values instead of >> calling the getBlank.js script. >> >> A generic e.g to adapt :- >> >> <div><label for="username">Username</label> >> <input name="username" type="text" id="username" >> value="Username" title="Enter your Username here" >> onfocus="if(this.value == 'Username') this.value = ' ';" >> /> >> </div> >> >> Not sure how many forms we have, not many I know of, so simple to do. >> >> If however, it is prefered to keep the getBlank.js script, then a check >> to see if the getBlank.js has already been inlcuded should do the trick. >> > > That is just a workaround, which sometimes makes sense but here > definitely not because the getBlank it is doing this and your suggestion > would add maintenance costs (duplicate code != copyless). Thanks for the > input which forces me to bring up the real problem behind this > issue. ;-) > > That leads us to a "debate on principles" how the dispatcher should > work. Till now views (first prototype) was focused on html and many > things just make sense in html (but not other formats). > > This issue could be found in the early days as well in views. Then > Diwaker raised this issue and we did control the contracts and only > added the head once, but why did we do this? > > ...because *HTML* just need the head stuff once. > > Now since the dispatcher should be open to other formats it feels wrong > to implement such a html specific mechanism again (which for some > formats will raise the opposite issue). > > That should not say there is no solution but actually reading the issue > subject again: "Head part is included as many times a contract is used" > it is not a bug but should be the default (intended) behavior as longer > I think about it. > > Now a quick clean solution is to split the head script call apart from > the specific contract to a helper contract. I added such a contract a > while ago: helper-prototype-ajax.ft > > The ajax-example.ft is stating in its description: > <div class="warning"> > <div class="label">Warning</div> > <div class="content">You need to include <![CDATA[<forrest:contract > name="helper-prototype-ajax"/>]]> in your view!!! If you are not, it > will not work.</div> > </div> > > That leads us to the question whether we want to allow such dependencies > between contracts. The re-usability of contracts would be widely > enhanced but it adds complexity for structurer designer. > >> > Example : >> > In the search contract - which is used twice in the pelt theme (as >> locations examples), the getBlank.js file is, also, included twice. >> > <forrest:content> >> > <forrest:part xpath="/html/head"> >> > <script type="text/javascript" language="javascript" >> src="{$root}themes/getBlank.js"> </script> >> > </forrest:part> >> > ... >> > </forrest:content> >> > gives : >> > <script language="javascript" src="../themes/getBlank.js" >> type="text/javascript"> </script> >> > <script language="javascript" src="../themes/getBlank.js" >> type="text/javascript"> </script> >> > in the head part. > > The getBlank.js can be used in any given form. It states in getBlank.js: > " * getBlank script - when included in a html file and called from a > form text field, will set the value of this field to "" if the text > value is still the standard value. > * getPrompt script - when included in a html file and called from a > form text field, will set the value of this field to the prompt if the > text value is empty." > To extract it to its own contract makes perfect sense since you would > control in the structurer that it is included just once.
Ok, sounds good. If no one beats me to it, I'd like to try that. > > Like I never get tiered to say: > "Contracts used in the dispatcher are standalone, self explaining, > configurable pieces of xsl templates, created out of pure maintenance > reasons." > > We have heaps undocumented code in our code base, the dispatcher tries > to encapsulate this code in functional code bits and allows us to > document within the same file. We focus on devs right now and IMO devs > are looking into the code for documentation (especially in open > source). > > The getBlank.js is providing the documentation in the code but not where > it finally used. That forces a contract author to open the jscript and > reading the head. IMO it makes more sense to document it in a contract > where I can then lookup via ls.contracts what it is doing and how I can > I use it. > > WDYT? +1 Gav... > > salu2 > -- > thorsten > > "Together we stand, divided we fall!" > Hey you (Pink Floyd) > > > -- Gav...
