You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Gavin (JIRA)" <ji...@apache.org> on 2006/01/16 17:05:21 UTC
[jira] Commented: (FOR-790) Head part is included as many times a
contract is used
[ 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.
Let me know which way is preferred and I'll create a patch.
Gav...
> Head part is included as many times a contract is used
> ------------------------------------------------------
>
> Key: FOR-790
> URL: http://issues.apache.org/jira/browse/FOR-790
> Project: Forrest
> Type: Improvement
> Components: Dispatcher (aka views)
> Versions: 0.8-dev
> Reporter: Cyriaque Dupoirieux
> Priority: Minor
> Fix For: 0.8-dev
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [discuss] dispatcher (was Re: [jira] Commented: (FOR-790)
Headpart is included as many times a contract is used)
Posted by "Gav..." <br...@brightontown.com.au>.
> 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...
Re: [discuss] dispatcher (was Re: [jira] Commented: (FOR-790) Head
part is included as many times a contract is used)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El lun, 16-01-2006 a las 17:05 +0100, Gavin (JIRA) escribió:
...
>>>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.
>
> 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?
I'm +1 for this, but...
The documentation generated by ls.contracts is not sufficient. As the
number of contracts grow it is going to get increasingly confusing.
Don't get me wrong, I totally agree that ls.contracts is a massive
improvement over what we currently have, I just want to flag up that we
can improve much more.
I think that (at some stage, not now lets finish what we started first).
We need to consider "types" or "groups" of contract. This will allow us
to separate those contracts into logical collections, both for
distribution and for documentation.
So, for example, the above getBlank.js is, most likely belongs to a
"forms" group. How these groups are identified, grouped and distributed
needs careful consideration (at some point in the future).
Ross
Re: [discuss] dispatcher (was Re: [jira] Commented: (FOR-790) Head
part is included as many times a contract is used)
Posted by 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"> </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
>
>
[discuss] dispatcher (was Re: [jira] Commented: (FOR-790) Head
part is included as many times a contract is used)
Posted by Thorsten Scherler <th...@apache.org>.
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.
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)