Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

getRootPath function in global.js causes problems (Mark?)

TomTesterTomTester New
edited May 2008 in Vanilla 1.0 Help
As noted in various topics (e.g. this or this) the getRootPath function defined in /js/global.js
is causing some headaches for applications that 'pack' CSS and/or JS files and in the process
remove the related <SCRIPT and <STYLE tags. e.g.

JQMedia uses this: jqmediaPath.webRoot = jqmediaPath.getRootPath('script', 'src', 'js/global.js');
JQThickBox uses: Vanilla.webRoot = Vanilla.getRootPath('script', 'src', 'js/global.js');
(plus there are others...)

In these examples getRootPath code determines the path by parsing the 'src' field of the <script tag.
Unfortunately, packers like vzippy & vanilla packer remove the <script reference and as a
result the getRootPath function returns 'false', resulting in broken links to media etc.

I'd love to see an alternative solution to fix this once and for all and to create a best practice code snippet
for developers, to use in their add-ons.

I'd love Mark's input in this as well.

TT.

Edit @ 8:12pm - removed PathFinder code, you can look it up yourself in js/global.js

Comments

  • Options
    getRootPath doesn't cause any problem, and that's not really the problem of mark but our problem Tom.

    Mark just added the function but doesn't use in the core. And the problem is with Vzippy and Vanilla-Packer. we have to find a solution. I found one for Vpacker. For V-zippy the solution is quite easy.
  • Options
    TomTesterTomTester New
    edited April 2007
    Dino,

    Sure, getRootPath is not really to blame, and neither is Mark. This was more of a 'pull-in quote'.

    The problem really lies with the ingenious but unreliably implementation of determining the path
    with getRootPath used in in JQMedia, JQThickBox, iBox etc.

    That particular implementation uses getRootPath to obtain info about vanilla paths, yet as we've
    found out, deriving these on-the-fly, predicated on the presence of <script...> and <style...>
    isn't a *reliable* solution going forward.

    Now we can ask everyone to change their use of getRootPath, but why force everyone to add a
    complex piece of code when a simpler, secure & fool-proof way to provision the vanilla paths
    may exist.

    Your solution (is that the one you reference?), requires developers to change their add-ons
    to check for the presence of another add-on, a slippery slope indeed, or the alternative is to
    require users to change core files/add-ons themselves (aka, 'hack' the vanilla core or add-ons).
    IMHO neither is preferable.

    Since I consider this root/core functionality, I asked Mark for his $0.02 (or CAN$0.025) I hope he reads this ;-)

    TT
  • Options
    Dinoboff code checks for packer and makes changes to getroot path
    jqmediaPath.getRootPath('script', 'src', /js\/packer\.php.*$/)
  • Options
    TBH, provided there's a (preferably documented) way for extension authors to code a single extension that works with or without the packer, I don't see the problem.
  • Options
    Schiz, it required Stash and yourself to change the code to add a specific exception for a specific add-on.

    It solves the path problem ONCE for ONE add-on, instead of solving it ONCE for ALL add-ons. The code
    still assumes (and requires) the presence of a script tag referencing global.js (or now also packer.php*)
    to function properly.

    I feel that:

    #1 path info is best provided to add-on JS-files by the core so when core method changes, all add-ons
    are automatically up-to-date and do not require manual updates, saving us all a big headache.

    #2 path info should not depend on the presence of something that isn't guaranteed to be there (either
    global.js or packer.php).

    I really can't see why anyone would disagree with this.

    Better to change it now rather than later, when other add-ons have similar requirements (e.g. advanced
    page caching add-ons or my practical VZippy, see my next post in vzippy thread)

    TT
  • Options
    what came of this issue.
    Do we have a solution to this.

    i'll prefer to change it cause its creating problems fror JQmedia users.
  • Options
    Nothing came of it (AFAIK) other than that I abandoned my first attempt at a Vanilla add-on (VZippy) ;-)
  • Options
    Hate to bring up old threads, but i'm currently running into this. I have over 800+ errors from JQThickBox b/c it can't find the base URI. Anyone have any ideas or an idea on how to fix this?
This discussion has been closed.