forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject [discuss] dispatcher (was Re: [jira] Commented: (FOR-790) Head part is included as many times a contract is used)
Date Mon, 16 Jan 2006 23:52:22 GMT
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">&#160;</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. 

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
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message