The component itself knows it's the variable's value at compile time. The
problem is that there are many components each has a different value. Or none
at all. Basically the first one that gets instantiated has to put it's value
into the variable and has to be on the page before the components injected JS
library.
I I go with the MarkupRenderFilter approach, it's not a problem to put the
value of the variable in there but will it be able to put the variable in front
of the imported JS library? _after_ the component has been instantiated?
On Aug 19, 2011, at 12:26 AM, Robert Zeigler <robert.zeig...@roxanemy.com>
wrote:
> Hm... when does this component render with respect to the rest of the page?
> Must be early on... the dom document will contain everything in the page that
> has rendered to this point. Thinking about this a bit more... the script
> elements from the library imports are added by the document linker, and they
> are added as part of a MarkupRenderFilter, after the page render. You could
> still add the script element to the head, but then all of the imported
> scripts will be placed before it. You could fix that with a
> MarkupRenderFilter... as long as it comes after "DocumentLinker". Basically,
> then you would add the script in afterRender, as before (assuming you have an
> html > head element to add the element to) and then use your markup renderer
> to re-order the elements after documentLinker adds the <script src="...">
> elements.
>
> At what point in the rendering process do you know the variable value? Put
> another way, how is your component calculating the directory? If that logic
> can be separate from the component rendering, then you could move /all/ of
> the logic to the MarkupRendererFilter. If the logic for calculating the
> value needs to be inside the component, then you'll need some way to stash
> the value. You could stick it in the Request service as a request attribute.
> Or you could push it onto the environment (but if you do that, make sure
> that you're not pushing a "raw" type... you'll want a custom class, such as
> "GWTRenderInfo" or some such. That way, you know what you're pushing onto
> and popping off the environment, since it works entirely by type). The
> environment idea is kind of fun... you could then check to see if
> GWTRenderInfo is in the environment (environment.peek(GWTRenderInfo.class))
> and only add the necessary script value if it is.
>
> HTH
>
> Robert
>
> On Aug 18, 2011, at 8/1811:41 PM , lpri...@hope.nyc.ny.us wrote:
>
>> I tried Option #2, but it didn't work. †The DOM document only contained the
>> DOM of the current component,
>> not the whole page, there were no <script> entries in the DOM. †Is it worth
>> trying MarkupRenderFilter?
>> Or do you have any other ideas?
>>
>> On Aug 18, 2011, at 4:22 PM, Robert Zeigler wrote:
>>
>>> If GWT is generating the scripts directory, why doesn't it know the
>>> directory? Or are you telling it the directory to use?
>>>
>>> In any event, I can think of a couple of possibilities. †Basically, the
>>> problem is that you don't know the value of the directory until render
>>> time, but Tapestry puts all libraries to be imported into the document
>>> head, and all code to be executed (such as a variable declaration) occurs
>>> after page load (which is after loading the gwtSupport.js script).
>>>
>>> Option #1 (gross, btw, but it would get the job done):
>>> †* Remove the @Import
>>> †* @Inject JavaScriptSupport jsSupport;
>>> †* In one of the render phase methods, generate the required value and
>>> write it to a file (eg: in the context).
>>> †* jsSupport.includeJavaScriptLibrary("your generated file");
>>> †* jsSupport.includeJavaScriptLibrary("context:js/gwtSupport.js");
>>>
>>> Option #2 (not as gross; still smells, but should work):
>>> †* Leave the import in place
>>> †* After render:
>>> ††††void afterRender(MarkupWriter writer) {
>>> ††††††††//find the gwt script:
>>> ††††††††Element gwtScript;
>>> ††††††††for(Node n : writer.getDocument().find("html/head").getChildren()) {
>>> ††††††††††††if (!(n instanceof Element)) continue;
>>> ††††††††††††Element el = (Element) n;
>>> ††††††††††††if ("script".equals(el.getName()) && el.getAttribute("src") !=
>>> null && el.getAttribute("src").contains("gwtSupport.js")) {
>>> ††††††††††††††††gwtScript = el;
>>> ††††††††††††††††break;
>>> ††††††††††††}
>>> ††††††††}
>>> ††††††††if (gwtScript == null)
>>> ††††††††††††throw new RuntimeException("Couldn't find gwtSupport script!");
>>>
>>> ††††††††Element myScript =
>>> getDocument().find("html/head").element("script","type","text/javascript");
>>> ††††††††myScript.text("var myvar=" + myGeneratedValue);
>>> ††††††††myScript.moveBefore(gwtScript);
>>> ††††}
>>>
>>> In option 2, you're leveraging the fact that Tapestry renders a DOM tree on
>>> the server to find the gwtScript element in the document head and insert
>>> your custom script (with variable declaration) before it.
>>>
>>> Neither option is very pretty, but both should work.
>>>
>>>
>>> Robert
>>>
>>> On Aug 18, 2011, at 8/183:37 PM , Lenny Primak wrote:
>>>
>>>> Its a path to the GWT-generated scripts directory. †Basically, there can
>>>> be many GWT modules, but supporting scripts are the same,
>>>> even though they are duplicated in different paths, so any path will do,
>>>> but there has to be one, just dynamically generated from
>>>> any of the available components.
>>>>
>>>> Thanks for your help!
>>>>
>>>> On Aug 18, 2011, at 3:34 PM, Robert Zeigler wrote:
>>>>
>>>>> Hm. Can you speak more to what the generated value is supposed to be/do?
>>>>> †It appears that it doesn't matter /too/ much what it is since it doesn't
>>>>> matter if multiple component instances overwrite the value?
>>>>>
>>>>> Robert
>>>>>
>>>>> On Aug 18, 2011, at 8/183:24 PM , Lenny Primak wrote:
>>>>>
>>>>>> The variable's value is dynamically generated by the component that is
>>>>>> importing the library.
>>>>>> If there are multiple component, any component instance should win, and
>>>>>> that's ok.
>>>>>>
>>>>>>
>>>>>> On Aug 18, 2011, at 3:22 PM, Robert Zeigler wrote:
>>>>>>
>>>>>>> What if you include a bit of custom js in a separate file that defines
>>>>>>> the variable?
>>>>>>>
>>>>>>> component.js:
>>>>>>> var somevar="someval";
>>>>>>>
>>>>>>> Then:
>>>>>>>
>>>>>>> @Import(library={"component.js","context:js/gwtSupport.js"})
>>>>>>> public class GwtSupport{...}
>>>>>>>
>>>>>>> Pretty sure that the order of the libraries in your @Import will be
>>>>>>> honored in the import declarations on the page (but I don't remember
>>>>>>> offhand).
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>> On Aug 18, 2011, at 8/183:14 PM , Lenny Primak wrote:
>>>>>>>
>>>>>>>> I have a component like this:
>>>>>>>>
>>>>>>>> @Import(library="context:js/gwtSupport.js")
>>>>>>>> public class GwtSupport
>>>>>>>> {
>>>>>>>> // intentionally left blank
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> gwtSupport.js (actually the GWT component itself which I have no
>>>>>>>> control over)
>>>>>>>> is trying to read a variable.
>>>>>>>>
>>>>>>>> I wasn't able to figure out a way to set it before gwtSupport.js gets
>>>>>>>> included.
>>>>>>>>
>>>>>>>> I tried addInitializerCall, addScript, etc. but they all come after
>>>>>>>> gwtSupport.js is included.
>>>>>>>>
>>>>>>>> What am I missing?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
