[OpenAjaxIDE] Inline, macro-expanded content within <requires> element

Mon Aug 11 14:40:07 PDT 2008

After thinking some more about the multi-widget problem that Rich pointed
out (where multiple widgets might be placed into the same frame and have
overlapping <require> elements), I suggest that we keep the <preload> and
<postload> elements so that the tool can know where how to place the
JavaScript within <preload> and <postload> relative to the content
generated by the parent <require> element. Therefore, it would be:

// THE FOLLOWING MATCHES WHAT WE HAVE TODAY
<requires>
__<require type= src= ...>
____<preload>...</preload>
____<postload>...</postload>
__</require>
</requires>>

If people agree to keep <preload> and <postload>, we will still not yet
have a solution to the problem of how to allow macro substitution on
JavaScript content placed in the head. One solution would be to allow the
<javascript> element to be used wherever <require> is used. The difference
between:

<requires>
__<require type="javascript" src=>

and

<requires>
__<javascript>   // THIS WOULD BE NEW

is that the former would not be subject to macro substitution whereas the
latter would. Also, preload and postload would be subject to macro
substitution.

Jon

             Jon                                                           
             Ferraiolo/Menlo                                               
             Park/IBM at IBMUS                                             To 
             Sent by:                  Rich Thompson/Watson/IBM at IBMUS      
             ide-bounces at opena                                          cc 
             jax.org                   ide at openajax.org                    
                                                                   Subject 
                                       Re: [OpenAjaxIDE] Inline,           
             08/07/2008 11:31          macro-expanded content within       
             AM                        <requires> element                  

Oh, yeah, if you have a mashup where the widgets are placed inline (i.e.,
not in IFRAMES), then widget A and widget B might reference the same Ajax
library.

However, if the widget gets put into its own IFRAME, then the requested
order can be achieved.

Jon

Inactive hide details for Rich Thompson/Watson/IBM at IBMUSRich
Thompson/Watson/IBM at IBMUS

                         Rich                                              
                         Thompson/                                         
                         Watson/IB                                         
                         M at IBMUS                                           
                         Sent by:                                       To 
                         ide-bounc                                         
                         es at openaj            ide at openajax.org             
                         ax.org                                            
                                                                        cc 

                         08/07/200                                         
                         8 10:39                                   Subject 
                         AM                                                
                                              Re: [OpenAjaxIDE] Inline,    
                                              macro-expanded content       
                                              within <requires> element    

At most the order of elements in the requires can suggest an ordering
within the head. The possibility of multiple references to the same files
in different orders is too high to think the spec/widget can mandate a
particular ordering.

Rich

 From:   Jon Ferraiolo/Menlo Park/IBM at IBMUS                                

 To:     ide at openajax.org                                                  

 Date:   08/07/2008 12:35 PM                                               

 Subject [OpenAjaxIDE] Inline, macro-expanded content within <requires>    
 :       element                                                           

Hi Kin & everyone,

Wayne Vicknair completed his analysis of whether it is OK within dynamic
mashup scenarios for macro-expansion transformations (properties,
localization, etc.) to be applied to inline content that is placed into the
HEAD. His answer, fortunately, is that there is no apparent problem with
doing this. Therefore, it looks like there should be no problem addressing
the requirement that Kin mentioned earlier this week.

Some of the open source contributors batted some ideas around. Here is my
proposal (with slight differences from what was last discussed with the
open source guys) for how the metadata markup should look.

[1] <requires>
[2]   <require type=... src=.../>   <!-- For referenced files and folders
-->
[3]   <javascript>...</javascript>  <!-- For inline JS that is placed in
the head -->
[4]   <style>...</style>            <!-- For inline CSS that is placed in
the head -->
[5] </requires>

Notes:

[1]
* The <requires> element now has 3 possible children: <require>,
<javascript>, and <style>.
* The order of the sub-elements to <requires> determines the order in which
things are placed into the HEAD.
* You must have a <requires> element around any <require> elements.
(Currently, <requires> is optional, but after introducing a <javascript>
sub-element, it is cleaner and simpler to force peopel to have a <requires>
element.)

[2]
* <require> would now have two required attributes, 'type' and 'src'.
Previously, only 'type' was required, but by introducing <javascript> and a
new <style> element, then we will have removed the inline cases for
<require>.

[3]
* The <javascript> element within <require> would be the same element as
the <javascript> element outside of <require>. In all cases (i.e., inside
of <requires> or not), the <javascript> element would be subject to
macro-expansion transformations. However, there would be a couple of
differences for <javascript> when used inside of <require>
==> The "this" object would not be set to the widget wrapper object because
that's not what happens with inline JS in the head
==> The 'src' attribute would be disallowed - only inline JS would be
allowed inside of <require>

NOTE: By allowing the <javascript> element within <require>, we can get rid
of the <preload> and <postload> elements.

[4]
* The <style> element allows for inline CSS that is inserted into the HEAD.
It would be subject to macro-expansion processing, although people probably
won't use variables very often with their CSS style declarations.

Jon

_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide

_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide
_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080811/0bc91354/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080811/0bc91354/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic15584.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080811/0bc91354/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080811/0bc91354/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 09189945.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080811/0bc91354/attachment-0007.gif 