Loading ...
Sorry, an error occurred while loading the content.

YUILoader and having to set the base path globally

Expand Messages
  • eelco_hillenius
    Hi, I m working on the datepicker in the Wicket framework (http://wicket.apache.org/), which is based on the YUI calendar widget. We migrated it to use the YUI
    Message 1 of 3 , Aug 3, 2007
    • 0 Attachment
      Hi,

      I'm working on the datepicker in the Wicket framework
      (http://wicket.apache.org/), which is based on the YUI calendar
      widget. We migrated it to use the YUI loader today.

      We often want to load the dependencies relative to the Wicket widget,
      so that it always works (whether you are connected to the internet or
      not) and so that we have some control over when to upgrade our YUI
      dependencies.

      A problem we are having with the YUI loader now is that in order to
      load all our YUI dependencies relative to the Wicket widget, we have
      to construct YAHOO_config and set the basedir ourselves before we load
      the yuiloader dependency. If we don't do that, even though we
      construct the YUI loader like this: new YAHOO.util.YUILoader({base:
      "${basePath}"}), it will still try to load yahoo-min.js from the
      public Yahoo server.

      Do you have suggestions how to get around this? Ideally, it would be
      great if just constructing the instance of YUILoader with our path
      would work and we never had to create the YAHOO_config object ourselves.

      Cheers,

      Eelco
    • Adam Moore
      ... Eelco, You can get around the need to create a YAHOO_config in this situation by including yahoo-min.js script yourself before yuiloader.
      Message 2 of 3 , Aug 3, 2007
      • 0 Attachment
        On Fri, Aug 03, 2007 at 11:19:06PM -0000, eelco_hillenius wrote:
        > Hi,
        >
        > I'm working on the datepicker in the Wicket framework
        > (http://wicket.apache.org/), which is based on the YUI calendar
        > widget. We migrated it to use the YUI loader today.
        >
        > We often want to load the dependencies relative to the Wicket widget,
        > so that it always works (whether you are connected to the internet or
        > not) and so that we have some control over when to upgrade our YUI
        > dependencies.
        >
        > A problem we are having with the YUI loader now is that in order to
        > load all our YUI dependencies relative to the Wicket widget, we have
        > to construct YAHOO_config and set the basedir ourselves before we load
        > the yuiloader dependency. If we don't do that, even though we
        > construct the YUI loader like this: new YAHOO.util.YUILoader({base:
        > "${basePath}"}), it will still try to load yahoo-min.js from the
        > public Yahoo server.
        >
        > Do you have suggestions how to get around this? Ideally, it would be
        > great if just constructing the instance of YUILoader with our path
        > would work and we never had to create the YAHOO_config object ourselves.

        Eelco,

        You can get around the need to create a YAHOO_config in this situation
        by including yahoo-min.js script yourself before yuiloader.

        <script type="text/javascript" src="../build/yahoo/yahoo-min.js"></script>
        <script type="text/javascript" src="../build/yuiloader/yuiloader-beta-min.js"></script>

        I realize this isn't that much better. The next release will include
        the ability to define additional modules using YAHOO_config (instead of
        requiring you to create a YUILoader instance), which will be the
        preferred approach because it makes it possible to take advantage of the
        rollup files (yahoo-dom-event.js and utilities.js).


        -Adam
      • eelco_hillenius
        ... src= ../build/yahoo/yahoo-min.js ... src= ../build/yuiloader/yuiloader-beta-min.js ... Thanks for your quick answer. I m not clear
        Message 3 of 3 , Aug 3, 2007
        • 0 Attachment
          > You can get around the need to create a YAHOO_config in this situation
          > by including yahoo-min.js script yourself before yuiloader.
          >
          > <script type="text/javascript"
          src="../build/yahoo/yahoo-min.js"></script>
          > <script type="text/javascript"
          src="../build/yuiloader/yuiloader-beta-min.js"></script>
          >
          > I realize this isn't that much better. The next release will include
          > the ability to define additional modules using YAHOO_config (instead of
          > requiring you to create a YUILoader instance), which will be the
          > preferred approach because it makes it possible to take advantage of the
          > rollup files (yahoo-dom-event.js and utilities.js).

          Thanks for your quick answer.

          I'm not clear how the ability to define additional modules using the
          global YAHOO_config object would solve my problem though. My problem
          is basically that I'd like to specify a loading location for local use
          rather than globally - exactly what new YAHOO.util.YUILoader does. The
          reason for wanting to use a local base dir is that people could mix
          YUI based Wicket widgets with their own. Currently we only package the
          javascript files that are immediately needed for YUI calendar, so if
          we globally set the base dir for the loader and a user wants to use
          the YUI loader to add other dependencies, we'd have a problem.

          Adding yahoo-min.js before the loader is a good enough solution for us
          now, though if possible it would be nice if either the loader wouldn't
          try to load yahoo-min in the first place, or if the loader was just
          part of the main yahoo file.

          Anyway, I'd also like to express that I'm really enjoying working with
          YUI. Thanks to Calendar's flexibility, we've been able to create a
          Wicket component that is nicely localized (just using what is packaged
          with the JVM, so no extra maintenance on our side) and that we're
          adding new features to almost daily.

          Eelco
        Your message has been successfully submitted and would be delivered to recipients shortly.