I followed Martins way in this case
by using the resource loader he defined for the lib
if (javascriptLocation == null)
{
AddResource.addJavaScriptToHeader(PrototypeResourceLoader.class,
"prototype.js", context);
AddResource.addJavaScriptToHeader(PrototypeResourceLoader.class,
"effects.js", context);
AddResource.addJavaScriptToHeader(EffectRenderer.class, "fat.js",
context);
}
the code is basically how Martin does it, and I am doing it
the scripts are located under the respective resource dirs
of the loader components.
By moving the proto lib into a separate resource loader
entity Martin was able to avoid double includes
of the prototype libs.
what happens on the html side if things is that once this is
done an include to the page is added at the appropriate place.
The namespace problem is not a real problem here, because
once the scripts are on top of the prototpe lib you have
normally no function definitions just once included reusable
class definitions with inheritance.
The trick is that you have to use the scripts as I understand it
once they are shared into their own resource loader components
to avoid double includes and namespace problems.
Werner
Travis Reeder wrote:
> How are you including the javascript now? In the page or linking to
> prototype.js?
>
> Travis
>
> On 10/7/05, *Werner Punz* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> wrote:
>
> Martin Cooper wrote:
> > Can I suggest a high-level discussion of how you're going to structure
> > all of the JavaScript code in MyFaces? I'm concerned that you'll
> end up
> > with a fragmented JavaScript code base, with each widget using its
> own
> > style and way of doing things, which would be, um, less than optimal.
> >
> > I'm also very concerned right now that, unless I'm mistaken, all
> of the
> > code seems to be going into the global JavaScript namespace. This
> is OK,
> > I guess, if you're building an application, but it's definitely not OK
> > for a toolkit, since you're quickly going to end up with conflicts as
> > people use your toolkit to build applications. (Unfortunately, it
> seems
> > that the Prototype toolkit itself has this problem.)
> >
> > My 2 cents...
> >
> Very good idea, I am interested in that too, because the more
> we move towards ajax the more javascript dependencies we get...
> Also we need some consensous which javascript libs for now we use.
>
> Currently Martin and I settled for the proto lib (he for the accordeon
> panel and the ajax stuff, I for the effects tag) in the sandbox
> depending
> on it, DWR is out of the scope for both of us afair because it
> introduces yet another set of xml config files.
> (Cannot speak for Martin directly, of course, but I remember such a
> discussion I had with him)
> Martin in the sandbox already has moved the proto lib stuff into its own
> and slowly is introducing stuff which is based upon it (the accordeon
> panel for instance), we should follow something like that approach.
>
> proto loader
> ... scriptaculo.us <http://scriptaculo.us> separate loader but
> having a dep into proto and
> shared over components
> ... other libraries also shared
> ... local component stuff still local but it should be recommended to
> dock to one of the existing libs to keep the code as tight as possible
> (prototype based code has the tendency to be very tight due to the oo
> structures prototype introduces to javascript)
>
> As for the introduction of DWR... I would stay away from it until they
> have resolved the xml config file issues
> There isnt too much in DWR which cannot be solved in proto or one
> of the libs.
>
> To my knowledge most of the interesting stuff on the javascript side
> itself currently is driven by Rails and proto based stuff, so it would
> be wise to follow that approach for the time being.
>
>
