Re: [discuss] dispatcher (was Re: [jira] Commented: (FOR-790) Head part is included as many times a contract is used)

[Cyriaque Dupoirieux <Cy...@pcotech.fr>]

Thorsten your are definitely right, I think the creation of a specific 
documentated contract which will load the getBlank.js scripts is a 
pretty solution.

I am going - with your help ;-)  - to search a contract name which will 
group scripts driving components forms behaviour (getBlank and getPrompt 
functions are only examples and can be later completed with new 
functions...)

I am going to close this issue.

Salutations,
Cyriaque,

Thorsten Scherler a écrit :

>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" DEFANGED_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">
>>>         <DEFANGED_script type="text/javascript" language="javascript" src="{$root}themes/getBlank.js">&#160;</script>
>>>      </forrest:part>
>>>...
>>></forrest:content>
>>>gives :
>>>  <DEFANGED_script language="javascript" src="../themes/getBlank.js" type="text/javascript"> </script>
>>>  <DEFANGED_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. 
>
>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?
>
>salu2
>  
>