James,
I think it would be nice to make the registration of local/remote libs
more explicit in code, instead of xml (jslibraries.xml ).
I would consider adding them in global.asax.cs, what do u think?
The reason is, taking your example of 3rd party VC, if the VC uses an
external lib that is not in jslibraries.xml file then we would have to
add it there, right? So it is not just drop it in :(
Regarding "combine", in your scenarios, combine is tricky, because if
page1 needs jsQuery.js + myscript.js(dynamiclly added via VC1) and
then page2 needs jsQuery.js + myotherscript.js(dynamiclly added via
VC2), we would get jQuery.js repeated and cached twice on the client.
Another feature I am considering, is to include if present a js file
for each action or even controller and/or area, and VCs, all via
convention eg:
If we have an action lets say Home\Index, we would see is there is a
js file (in the same location as the view file, and named the same as
the view) and automatically include it.
And the same for Area and Controller, see files tree:
Views\Home\
index.vm
index.js <- auto included for Index action
home.js <- auto included for all action in
HomeController
Views\MyArea\Products\
index.vm
index.js <- auto included
for Index action
view.vm
view.js <- auto included for
View action
Views\MyArea\myarea.js <- auto included for all actions in MyArea
Views\ViewComponents\MyComponent\
index.vm
index.js <- auto included for mycomponent
Cheers
John
On Oct 30, 1:11 am, James Curran <[email protected]> wrote:
> On Oct 29, 3:46 am, John Simons <[email protected]> wrote:
>
> > Now a days, with libs like jQuery, we rarely(web developers) need to
> > write browser specific javascript,
>
> This part is true. I've, in fact, never actually used that feature in
> my own code. (And, You'llnote that I didn't use it in the sample I
> posted above). I was in fact considering removing or at least de-
> emphasisizing it in the latest changes. (I was planning on making an
> unnamed section the same as the #all section, except nVelocity has
> trouble parsing things like $("#id") in unnamed section).
>
> > Another point is that, my intent is to standardise only on JQuery. so
> > no need to support prototype or scriptaculous.
>
> Actually, this is where it's use shows the MOST benefit.
>
> In what I'd originally considered to be a minor feature, but now
> consider to be it's most important, is that it handles negotiating
> the use of Javascript on multiple levels (Layout, View, and
> ViewComponent). This is particularly important when dealing with
> Framework or third-party ViewComponents.
>
> Take for example the components in CastleContrib that use Javascript:
> Collapsible Panel, and MoreLessText. Both were originally written to
> use Prototype, because that was the standard js library of Monorail.
> After I rewrote them to use the JavascriptComponent, the developer
> could now choose to use either Prototype or Jquery (You would just
> need a jslibraries.xml file with the single line <libraries
> preferredLibrary="jquery" /> ) (you can also specify your choice as a
> VC parameter))
>
> Further, both of those are VCs that you are likely to have multiple
> times on a page. And originally, common JS code was repeated multiple
> times. With the JavascriptComponent, the common code is included only
> once with only the instance specifc code repeated)
>
> FInally, to use of either components, the website developer must know
> that it uses a particular JS framework, and remember to include that
> library manually. With the JavascriptComponent, the VC can indicate
> what libraries it needs, and they (along with their dependencies are
> automatically included).
>
> This become particularly important when you start using jQuery UI
> where each module has a list of dependencies which have to be included
> in the right order, and where every jQuery plugin comes with it own
> CSS file which you must remember to include.
--
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
