if the question is how to modify internal JavascriptResourceReference packaged 
with component

I will just override
        @Override
        public void renderHead(IHeaderResponse response)
        {
                // initialize the javascript library
                response.render(JavaScriptHeaderItem.forReference(JS));
                response.render(OnDomReadyHeaderItem.forScript("new 
MultiSelector('" + getInputName() +
                        "', document.getElementById('" + 
container.getMarkupId() + "'), " + max + ",'" +
                        getString("org.apache.wicket.mfu.delete") + 
"').addElement(document.getElementById('" +
                        upload.getMarkupId() + "'));"));
        }

Max is the max number of files a user can upload.
container.getMarkupId() is container
upload.getMarkupId() is upload

Hope this helps


François Meillet
Formation Wicket - Développement Wicket





Le 15 févr. 2013 à 20:11, evan <e...@novelution.com> a écrit :

> Okay, so you are saying I need to create my own versions of each of those
> private variables referenced in renderHead, and override any methods that
> use any of them, to reference my own, is that right?  Unfortunately, it
> still has maintenance implications, but I guess that might just be
> inevitable given what I want to do.
> 
> Thanks for the help!
> 
> 
> Francois Meillet wrote
>> Le 15 févr. 2013 à 16:48, evan &lt;
> 
>> evan@
> 
>> &gt; a écrit :
>> 
>>> Hi Francois,
>>> 
>>> Thanks, but actually this still has issues.  At first I thought it was
>>> clearly the simple thing I was missing, but then I remembered there's
>>> still
>>> a problem - the line in renderHead copied from the original
>>> MultiFileUploadField uses private members container, max, and upload, so
>>> the
>>> extending class won't be able to do this.  I realize I could create my
>>> own
>>> versions of each of these (like you suggested with YOURJS), and then
>>> override every method that uses any of them, replacing the reference with
>>> the new versions.  But that might propagate to usage of other fields, and
>>> at
>>> that point
>> 
>>> it might be simpler to just copy the entire contents of the
>>> original class's code into a new version of the class of my own,
>> I would not do that, as you say after, there will be maintenances issues
>> 
>>> with the
>>> only modification being the location of the .js resource.  Neither of
>>> these
>>> two things would be hard to do, and maybe they are simply the only
>>> solutions, but it feels like that's not great, because it loses the
>>> ability
>>> to leverage the fact that future versions of the api class might improve
>>> in
>>> other ways and there'd be maintenance issues keeping my version
>>> up-to-date
>>> with the rest of the api.  Is that just what needs to be done, or is
>>> there
>>> possibly some other way to use the existing class directly and just swap
>>> some alternate resource file in place of the default one? 
>>> 
>> As you say, you 'd like to make a minor modification to the actual
>> javascript in , MultiFileUploadField.js,
>> so in this case I will choose the renderHead override method.
>> 
>> 
>> François Meillet
>> Formation Wicket - Développement Wicket
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/how-to-modify-internal-JavascriptResourceReference-packaged-with-component-tp4656344p4656422.html
> Sent from the Users forum mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

Reply via email to