Hi,
I’m currently developing some new (and porting some old) client side widgets to Vaadin 7[1]
; I’m incorporating some external javascript files, through the use of the handy @Javascript annotation. Several components share the same file - currently, it’s just JQuery, but I imagine that the there will be more components sharing the same files - and there may be more files as we develope further.
When those files are registered, the AbstractCommunicationManager logs a warning:
29-Apr-2013 16:25:05 com.vaadin.server.AbstractCommunicationManager registerPublishedFile
WARNING: js/jquery-1.8.3.min.js published by both class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.AutoNumericExtension and class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.FocusTrackerExtension. File from class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.FocusTrackerExtension will be used.
29-Apr-2013 16:25:05 com.vaadin.server.AbstractCommunicationManager registerPublishedFile
WARNING: js/jquery-1.8.3.min.js published by both class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.NMF and class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.FocusTrackerExtension. File from class com.hpdsoftware.aquarius.aura.framework.vaadin.ui.component.FocusTrackerExtension will be used.I understand the warning is helpful if the file is a different file with the same name, but I feel that this may be a little dangerous if it’s the same file; I am already starting to ignore the warning, which means that I may miss a genuine warning when - say - a plugin registers an fuke with the same name. A possible case of “The Boy Who Cried Wolf”.
So, I have two questions:
- Is it possible to include these javascript files once (and only), avoiding the warning
- Would it be possible to modify he AbstractCommunicationManager to only log a warning if the published resource with the same URI is a different resource (I imagine this would be case of suppressing the warning if the annotation with the same uri belongs to a class in the same package and jar/directory as the already registered one. Simpler, store the URL for the resource including the jar:// or file:// and suppress the wanrning if the new registration URL is the same as the already registered one).
Cheers,
Charles.
Edited to add: AbstractCommunicationManager#writeUidlResponse is a monster of a method; I looked into trying to modify it to implement my suggestion but a) it’s huge and b) alot of stuff is “private” making it very difficult to override. Could I suggest this is reviewed/broken down at some point in the future, with an eye on allowing advanced users to modify the behavious in their own subclasses.
Also - I’d forgotten I’d already asked this in
another post
. Apologies for the duplication
[1]
The new client stuff in v7 is great, BTW, once you get your head around it. Well Done!